bug(unic-archon-dlc): /setup authors a Ref: tag definition it cannot observe, and triage-labels.md does not say which parts a run rewrites

Found while grilling WI 42991 on 2026-08-28.
Related to #427, which is the same family — generated content against hand-written content — but a
different file and a different mechanism, so it is filed separately.

The mechanism

commands/setup.md:316 writes docs/agents/triage-labels.md wholesale from TRACKER_VOCABULARY.
There are no markers and no managed block, unlike Step 7's targets. Its own rule is:

The role names in the left column are this Plugin's, and the team owns every other column.

That rule covers columns. It says nothing about a section. So a tenant fact a human adds to that
file as its own section has no protection, and the next /setup run in that Consumer loses it.

The instance that exposed it

DXP-DesignSystem's triage-labels.md carries an H2 section, § The Ref: tags are not one of these
tiers, which defines the Ref: family as recording "discipline — who does the work".

That definition is wrong. The maintainer, who owns the board, states that Ref: means
refinement: Ref: FE is a ticket to be refined with Frontend roles. He also states the tags exist
only in DXP-DesignSystem, DXP-ProfileServices and DXP-Website, and that he expects the family to
fade — once setup and skills land in every project, developers write specs themselves and traditional
human refinement stops.

Measured alongside it, across all 39 work items under dxp\DXP - ZRH\DS - Design System: zero carry a
Ref: tag, every one carries an undocumented project tag P: DesignSystem, and Specs is live on
42964, 42966 and 42968 where the file says retire it on sight. Proof: wit_work_item action=get_batch
over the 39 ids with System.Tags, and a project-wide wiql on [System.Tags] CONTAINS 'Ref: FE'
(alive elsewhere: 28328, 29003, 41333-41335).

The decision

Do not correct the definition. Delete the section from what /setup authors.

A corrected tenant fact in a generated file is still a tenant fact in a generated file. The Plugin cannot
observe a tag family that exists in three of a client's repositories, and it got the meaning wrong
precisely because it cannot. The meaning belongs in the Consumer's own glossary, which is the team's file
and which no command writes — that half is tracked on the Consumer's board, not here.

Then fix the mechanism, because deleting one section does not stop the next one being lost.

Acceptance criteria

1. /setup no longer authors a definition of a tag family it cannot observe. The Ref: section is gone
   from what the command writes.
2. triage-labels.md states which parts of itself a re-run rewrites and which it preserves. A human
   reading the file knows where it is safe to add a tenant fact.
3. A second /setup run over a Consumer whose triage-labels.md carries a hand-added section preserves
   that section, or refuses and says what it would have overwritten. Silent loss is the defect.
4. The bar issue-tracker.md already carries — a section earns its place only if it states a fact about
   this tenant — is stated for triage-labels.md too, or the issue records why the two files differ.
5. Verified by running /setup twice in a real Consumer through a marketplace install, not by a test in
   this repository.

Note on sizing

The tag family is expected to die. Do not build machinery for Ref: specifically. The finding worth
fixing is the wholesale overwrite; Ref: is the instance that revealed it.

---

AMENDED 2026-08-28 — this issue's central premise is FALSE. Read this before the text above.

/setup does not write triage-labels.md wholesale, and a tenant fact added by hand is NOT lost.
The mechanism half of this issue is void. It was written from commands/setup.md:316 — "Write
triage-labels.md from TRACKER_VOCABULARY" — read as unconditional. It is not. That line is the
instruction for when the file is absent.

The treatments table 280 lines above it says what actually happens (commands/setup.md:29):

report — a file the tenant owns — written when absent; when present, read it and report what
differs, changing nothing

Repeated at commands/setup.md:249: "Each one is written when it is absent. When it is present, read
it, report what differs from what this run would write, and change nothing — unless MODE = 'reconfigure', which offers the change per file." And again in README.md:197, and the run output at
commands/setup.md:402 prints "written, or reported unchanged".

So both tracker-contract files are tenant-owned with report treatment. A hand-written correction in
either survives every later /setup run. Only reconfigure offers a change, and an operator must accept
it.

Found by the worker on WI 42995, verified
independently. Worth naming how it survived: three documents said "wholesale" — this issue, and two
Azure DevOps work-item bodies — while the one document that had actually measured it, the Consumer's
docs/agents/unic-archon-dlc.md treatments table, said "report". The claim propagated because nobody
re-read the source; each restatement cited the previous one.

What survives, and it is smaller

One thing, and it is worth keeping: /setup should not author a definition of a tag family it cannot
observe. The Ref: section it writes into triage-labels.md defines the family as recording
"discipline — who does the work". It means refinement — Ref: FE is a ticket to be refined with
Frontend roles — and the family exists only in three of the client's repositories. The Plugin cannot see
that and got it wrong.

So the remaining criteria are:

1. /setup no longer authors a definition of a tag family it cannot observe. The Ref: passage is gone
   from what the command writes.
2. triage-labels.md states which parts of itself a run would rewrite and which it reports on, so a human
   reading the file knows a hand-added tenant fact is safe. The behaviour is already correct; the file
   does not say so.
3. Verified by running /setup twice in a real Consumer through a marketplace install.

Criteria withdrawn

The former criterion 3 — "a second /setup run over a Consumer whose triage-labels.md carries a
hand-added section preserves that section, or refuses" — is withdrawn as already satisfied. Report
treatment does exactly that. A criterion satisfied by changing nothing reads as coverage and buys none.

Consequence beyond this issue

Anything that routed a fact away from docs/agents/ on durability grounds was routed on a false
premise. Those files are not volatile. The placement ladder itself is unaffected — it decides by reader,
not by durability — but the durability argument must not propagate.

Start by rereading the treatments table and the triage-labels.md generation instructions in commands/setup.md, then compare the corresponding wording in README.md. Remove the unobservable Ref: definition from the content /setup would write, document the existing report treatment and preserved tenant-owned content, and run /setup twice in a real Consumer through a marketplace install to verify the result.