bug(unic-archon-dlc): no Box advances an issue past ready-for-agent, so resolved and closed have no writer

What is wrong

ADR-0013 makes
the issue tracker the single source of truth for "where are we". No Box advances an issue's state, so
the tracker cannot answer that question for anything the DLC builds.

An issue enters at ready-for-agent and stays there. /build implements it and opens a PR. /qa
merges the PR. The issue still reads ready-for-agent.

Evidence

Counted every backticked Canonical role across commands/*.md, .archon/workflows/*.yaml and
.archon/commands/*.md on 2026-08-11:

• resolved — zero occurrences. No surface mentions it.
• closed — four occurrences, all in commands/triage.md, and all about a request that was
  already implemented. None is about work the main line finished.

Per Box:

Box	Writes issue state?
/build open-pr	No. It composes tracker.access to open the PR and writes no label.
/pr-review	No. unic-dlc-pr-review.yaml contains no classification.labels reference at all.
/qa	Only when filing a new issue from a UAT rejection (unic-dlc-qa.yaml:277 — type bug + state ready-for-agent). The merge node marks nothing.
/triage, /tickets	Write ready-for-agent. That is the last state anything writes.

Meanwhile the Plugin ships both roles. lib/labels-config.mjs:4-13 lists resolved and closed
in STATE_LABELS, so /setup seeds them into every Consumer's classification.labels and every
Consumer's tracker is expected to carry them.

Corroboration from this repo's own hand-owned docs — repo convention, not the Plugin's contract, since
this monorepo is not a Consumer (root ADR-0033):
docs/agents/triage-labels.md:39-42 defines resolved as "Implemented; ready for a PR" and closed
as "PR has been merged", in that order. docs/agents/feature-runner.md:9 has the by-hand path mark an
issue resolved before opening a PR — a human doing what no Box does.

Why it matters

Two shipped Canonical roles have no writer. Either the Boxes should write them, or the Plugin should
not ship them. Today it ships them and asks each Consumer's tracker to carry labels nothing will ever
apply, while ADR-0013's claim about the tracker holds only for issues a human maintains by hand.

This is the inverse of the wontfix defect in #309: there, a prompt resolves a role that does not
exist; here, a role exists that no prompt resolves.

Provisional acceptance criteria

Not final — this issue is needs-specs.

• An issue's state advances as the main line runs, or the roles that no Box writes stop shipping.
  Decide which, and record the decision.
• Whichever Box owns the write composes TRACKER.access and resolves the role through LABELS —
  no host CLI, no provider name (#309's barrier).
• A Box that cannot write state says so and continues, rather than failing the run. State is a
  report, not a gate.
• The lifecycle a Consumer can expect is written down once, in the Plugin, not inferred from this
  repo's docs/agents/.
• STATE_LABELS and the set of roles some Box actually writes agree, and a test holds them together.

Open questions for specs

1. Which Box writes resolved — /build at open-pr, or /pr-review after a clean review? open-pr
   matches the documented meaning ("implemented; ready for a PR") most closely.
2. Which Box writes closed — /qa's merge node, or nothing at all?
3. On some hosts a PR-linking keyword closes the issue automatically on merge; on others it does not.
   That makes closed a capability question in the sense #309 settles for TRIAGE.external_prs —
   ask what the tracker does, do not branch on which tracker it is.
4. Does the DLC own state advancement at all, or is it the human's job? If it is the human's, then
   resolved and closed are not Canonical roles and should leave STATE_LABELS — the same question
   #329 raises about what the shipped seed is for.

Context

Found on 2026-08-11 while grilling #309. First recorded as an adjacent finding inside #329 and split
out here, because the fix touches the main-line Boxes and not /setup.

Correction added 2026-08-11 — nothing reads a state either

The evidence above establishes that no Box writes resolved or closed. Grilling #329 the same
day established the wider fact: no Box reads any state Label string at all.

Checked across every commands/*.md, .archon/workflows/*.yaml and .archon/commands/*.md:

• grep 'classification|ready-for-agent' over .archon/workflows/unic-dlc-build.yaml → nothing. The
  file exists, so this is an empty result and not a missing-path error.
• grep 'needs-specs' over commands/specs.md → nothing.
• No file carries a label-filter, label-query or select-by-label instruction. The only two hits for
  that phrasing (.archon/commands/unic-dlc-qa.md:43,81) describe the labels a newly filed issue
  carries.
• Every other apparent hit is the English word "resolved" or "rejected" — Method resolution, a
  rejected gate, a resolved review thread — not a Canonical role. Counting backticked roles, as the
  evidence above does, is the reliable method; a bare word count is not.

So the state writers are /triage (its five outcomes), /tickets (commands/tickets.md:308) and
/qa on a UAT rejection (unic-dlc-qa.yaml:277). /specs is explicitly forbidden to file:
commands/specs.md:205-208 overrides the to-spec Method's own publish step, because filing is
/tickets' job. /explore's spike ticket writes a type and a priority, not a state.

The handoff between Boxes is the Slug a human passes on the command line, never a tracker query.

What this changes here

Open question 4 — "Does the DLC own state advancement at all?" — is the load-bearing one, and this
fact moves it. If nothing reads a state, every state is a report to a human, so the choice is not
"wire the Boxes together" but "does the Plugin promise a human-readable lifecycle it does not
maintain". ADR-0013's claim that the tracker answers "where are we" is a claim about human readers,
and that is precisely the claim failing today.

It also widens the scope. Dropping resolved and closed would leave six states that are still only
ever written at intake. Deciding for two roles means deciding for all eight.

Related corrections already landed

• CONTEXT.md's Canonical role entry claimed "/triage writes needs-specs and /specs reads
  it; /tickets writes ready-for-agent and /build reads it". Both reads were false. The entry is
  corrected and now records that a state signals to a human rather than routing work.
• #329's decisions (recorded in ADR-0024's 2026-08-11 amendment) close the key set of
  classification.labels downward: a missing Canonical role is a fault, an extra key is ignored.
  If this issue drops a role, that is a deliberate edit to a frozen list — which is the intent — and a
  Consumer's now-extra key is ignored, so no migration is needed.

This correction adds evidence only. Which Box writes what, and whether the DLC owns advancement at
all, still needs grilling.