Skip to content

Add designation prefixes for 56 categories under 20_manufacturers_articles - #73

Open
ispyisail wants to merge 1 commit into
qelectrotech:mainfrom
ispyisail:feature-qet-labels-coverage-batch2
Open

Add designation prefixes for 56 categories under 20_manufacturers_articles#73
ispyisail wants to merge 1 commit into
qelectrotech:mainfrom
ispyisail:feature-qet-labels-coverage-batch2

Conversation

@ispyisail

Copy link
Copy Markdown

Where this comes from

This is a follow-up to #70 (first batch, 10_allpole/11_singlepole), which
was the data half of qelectrotech-source-mirror discussion
#666
(IEC 81346 designation letter) and PR
#668
(the mechanism that reads this file — autonum::elementPrefixForLocation(),
exposed as the %prefix label-formula variable).

More recently this became item 2 of REFACTOR-BACKLOG.md Tier 2 in
qelectrotech-docker,
which was itself written from a review of scorpio810's own refactor roadmap
(refonte_du_code_de_qelectrotech on the QET wiki) — that doc separately
proposes "a standards file mapping element types to letter codes", which
qet_labels.xml already is, just under-filled-in. This PR is coverage
work against that same file, not a new mechanism.

What this does

Second batch from tools/iec81346 (in qelectrotech-docker), same tooling
and safety rules as #70. Covers manufacturer-specific PLC controllers,
safety switches, frequency drives, softstarters, sensors, power supplies,
relays, and a few allpole/graphics categories #70 didn't touch.

Every insertion is a one-line addition to a category the file already
lists — no new <category> nodes, no reformatting elsewhere.

Verification

  • Scored against the file's own gate: 0 contradictions with the 82
    hand-curated entries.

  • The tool proposed 60 candidates; I sampled every one by hand against its
    actual element contents rather than trusting the tool's own confidence.
    4 were dropped as false positives the existing safety rules can't see (a
    flat folder with no sub-categories has nothing to disagree with
    internally, so the "subtree wants a different prefix" check never fires
    even when the folder mixes device types):

    • 20_manufacturers_articles/guitar/pickups → matched the bare "coil"
      keyword, but a guitar pickup isn't a relay coil.
    • 20_manufacturers_articles/knx/actionneur → mostly generic
      binary/analog I/O modules, not motors; also contains a valve and a
      heater.
    • 20_manufacturers_articles/knx/capteurs → mixes real sensors with
      switches, a timer, and an alarm.
    • 20_manufacturers_articles/siemens/01_PLC_controllers/et200s/power_supply
      → its one actual element is a terminal module, not a power supply.

    (A small --exclude flag was added to propose_labels.py for this —
    companion commit in qelectrotech-docker.)

🤖 Generated with Claude Code

…icles

Second batch from tools/iec81346 (qelectrotech-docker), same tooling and
safety rules as qelectrotech#70's first batch (10_allpole/11_singlepole). This one
covers manufacturer-specific PLC controllers, safety switches, frequency
drives, softstarters, sensors, power supplies, relays, and a few
allpole/graphics categories that hadn't been touched yet.

Every insertion is a one-line addition to a category the file already
lists -- no new <category> nodes, no reformatting elsewhere. Verified
against the file's own scoring gate (0 contradictions with the 82
hand-curated entries) and by sampling every one of the 60 candidates the
tool proposed by hand: 4 were dropped as false positives the tool's
existing safety rules can't see (a flat folder with no sub-categories to
disagree with each other, so nothing trips the "subtree wants a
different prefix" check even though the folder mixes device types) --
20_manufacturers_articles/guitar/pickups (matched "coil" but isn't a
relay), 20_manufacturers_articles/knx/actionneur and .../capteurs (both
heterogeneous KNX I/O catch-alls), and
.../siemens/01_PLC_controllers/et200s/power_supply (its one element is
actually a terminal module, not a power supply).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant