work-items(triage): retire the T1/T2/T3 classification vocabulary superseded by the work-class axis

[kyle-sexton]

This was generated by AI during a triage session in github-iac.

Observation

Two vocabularies currently describe one dimension — how work is classified for autonomous routing:

• C1–C5 work classes — the normative risk taxonomy in the autonomy plugin's guardrail
  contract (blast radius / reversibility / input provenance / verifiability), consumed by the
  admission gate, the merge-authority ladder, and the dispatch/isolation floor.
• T1/T2/T3 (simple / medium / complex) — a triage-routing shorthand originating in the
  leave-week loop-prompt scaffolding, still surfacing in shipped contract text: the triage skill's
  outcome table carries a "Briefed, T1 multi-surface stub" row, and the loop prompts emit
  simple/medium/complex counts in their cycle status lines.

The T-tiers were scaffolding that predates the work classes reaching the shipped gates. Leaving both
live is a silent second way of saying the same thing.

Decision already taken downstream (context, not a question)

github-iac ratified a work-class: label axis on 2026-07-24 whose five members are
human-readable aliases of C1–C5 (read-only, mechanical, scoped, structural,
untrusted-provenance) — see melodic-software/github-iac#176 and its ADR 0009. In the same decision,
a separate complexity/effort axis was declined: the upstream source material treats complexity as
a runtime model-routing signal, not durable metadata, and no shipped consumer reads a planning-depth
stamp. That deferral carries a named trigger (a consumer that genuinely needs planning depth — the
frontier-tier complexity-dispatcher work is the candidate), at which point native Issue Fields
(Effort) is the likelier home than a label.

So the disposition question here is not which vocabulary wins — it is applying that outcome to the
shipped plugin text.

Direction (no open decision)

Retire T1/T2/T3 as a classification vocabulary in shipped contract surfaces:

• The triage outcome currently labelled "T1 multi-surface stub" describes a real and useful case —
  a trivial fix spanning several surfaces where a one-line sites + fix pattern comment replaces a
  full brief. Keep the outcome; re-express its trigger in work-class terms (mechanical-class work)
  or describe the case directly, without the tier token.
• Loop-prompt status lines reporting simple/medium/complex counts are operational telemetry rather
  than contract text; either re-express them in work-class terms for consistency or record explicitly
  that they are a lane-local reporting convenience, so the coexistence is documented rather than
  accidental.
• Nothing here changes the C1–C5 machine tokens, their schema enums, or the gates that read them.

Acceptance

• No shipped skill or contract surface uses T1/T2/T3 as a work-classification vocabulary
• The multi-surface trivial-fix outcome still exists, with its trigger expressed without a tier token
• Any remaining simple/medium/complex usage is explicitly scoped as lane-local telemetry, not
  classification
• The relationship between the work classes and triage routing is stated once, where triage
  routing is defined, rather than implied by two parallel vocabularies

[kyle-sexton]

Superseded — see the following comment. This comment reported that the work-class: labels were
declared on main but not yet deployed. That is no longer true: the deploy has since run and the
labels are live on every label-managed repository. Nothing in this issue is blocked on them.

[kyle-sexton]

This was generated by AI during a triage session in github-iac.

Unblocked — the labels are now live

Superseding the comment above: the production deploy has been dispatched and applied
(run 30125840537,
success). All five work-class: labels now exist on every label-managed repository in the org —
verified after the apply, not assumed:

dotfiles              work-class=5
github-iac            work-class=5
standards             work-class=5
claude-code-plugins   work-class=5     <- this repository
provisioning          work-class=5
ci-runner             work-class=5
medley                work-class=5
ci-workflows          work-class=5
.github               work-class=5
songwriting           work-class=5

Members, exact strings: work-class: read-only, work-class: mechanical, work-class: scoped,
work-class: structural, work-class: untrusted-provenance — colon-space separator, per the org
naming grammar.

This issue's stated dependency is satisfied. Nothing here blocks.

[kyle-sexton]

This was generated by AI during work-loop execution.

Escalated — C4 structural, hard-gated

Carries work-class: structural (C4). Per the admission gate's hard-gate table, C4
structural/contract work is human-gated regardless of any other signal — "Refactors,
migrations, contract changes; cross-cutting and hard to reverse... human review and human
merge are mandatory, always." This item had agent-ready from an earlier triage pass but no
needs-human had ever been formally applied, so it kept surfacing on the autonomous frontier
without ever being dispatchable. Applying needs-human now to correct the label state to match
the gate's actual (and unchanged) disposition — this item was never going to be autonomously
worked, this just makes that visible on the tracker instead of silently skipped every cycle.

[kyle-sexton]

This was generated by AI during work-loop execution.

Not dispatched — C4 hard gate stands; contradictory role label cleared

Cycle 6 admitted this item and dispatched an execute lane for it. That admission was wrong, and
the cause was a label contradiction on the item rather than a gate misread. No implementation was
attempted: no claim, no lease, no branch, no worktree, no PR.

Why it is not dispatchable

work-class: structural is C4. The work-loop admission gate's disposition table puts
C4 structural/contract work at human-gated / per-contract floors, unconditionally. The
first-drain earn-trust ratification mechanic that can return an item to the autonomous frontier is
scoped to C3 scoped, bug-fix-shaped items only — it has no reach into C4. There is therefore no
kind=ratify-c3 path to open here, and none has been opened: advertising one would create a false
affordance, since no operator reply could make a C4 autonomously dispatchable. This item's route to
execution is an operator decision through the attended lane, exactly as the previous escalation
comment concluded. That conclusion is unchanged.

Root cause of the re-admission

The item carried both canonical role labels — the autonomous-eligible role (agent-ready, from
an earlier triage pass) and the human-gated role (needs-human, applied by the escalation above).
The two are mutually exclusive by contract: the attended lane's flip rule states that applying one
role and removing the other is a single edit, precisely because an item holding both is excluded
from the autonomous frontier filter while still reading as agent-ready to anything that inspects
labels directly. That is what happened — the dispatching snapshot read agent-ready and did not
observe needs-human.

The stale autonomous-eligible label has been removed. needs-human is the truth: it is the later,
deliberate disposition, and it matches the gate. The item should now stop resurfacing on the
autonomous frontier each cycle.

Contract gap worth noting

The escalate step of the worker lane specifies applying the human-gated role label plus a
machine-marked escalation comment, but does not state the clearing half of the invariant — that
escalating must also remove the autonomous-eligible role — whereas the attended lane does state
it explicitly for the opposite (unblocking) direction. The invariant is one-role-per-item in both
directions; only one direction is written down. That asymmetry is what allowed the previous
escalation to leave the item in a contradictory state, and it will recur for any future escalation
of an item that was previously briefed as delegable. Flagging for the operator rather than fixing
inline: the fix edits shipped contract text in the same plugin this issue targets, which is itself
C4 work.

Verdict

BLOCKED — human-gated, awaiting operator disposition in the attended lane.

[kyle-sexton]

Drain: tracked by open PR #2464 docs(work-items): retire T1/T2/T3 triage classification vocabulary (no duplicate opened).