work-items(triage): "Apply outcome" step never removes the raw-intake marker — literal execution stacks status:ready onto needs-triage and re-triages forever

[kyle-sexton]

Lane: triage · Category: bug (behavioral — silent-loop-kill class)

Triggering example

2026-07-19 triage loop cycle. Applying an outcome to each item (step 5), the natural literal action is "apply labels + the autonomous-eligible/human-gated role label" per the "Apply outcome" table. Nothing in step 5 — or anywhere in the workflow — says to remove the raw-intake marker (status: needs-triage, or this repo's priority: needs-triage). A pre-flight review caught that stacking status: ready + role label on top of needs-triage leaves the item in the attention-view raw bucket, so the very next cycle re-fetches and re-triages it — forever.

Observed vs expected

• Observed: the triage state machine describes transitions (raw → verified → briefed → autonomous-eligible / human-gated) and the "Triage states" table marks raw as "unlabeled or status: needs-triage", but the mechanical label edit that clears the raw marker is never stated. The "Apply outcome" table lists what to add for each outcome; it never says to remove needs-triage. The attention view (bucket 1 "unlabeled", bucket 2 "status: needs-triage") re-selects any item whose marker was not cleared. Result: an operator following step 5 literally produces items that are simultaneously status: ready and needs-triage, re-entering the queue indefinitely.
• Expected: step 5 (and/or the "Apply outcome" table) states explicitly that every terminal outcome removes the raw-intake marker — normalization is a replacement, not an addition. Leaving a raw-intake label alongside a briefed/ready/needs-human label is a contradiction the skill should forbid. Ideally a closing invariant: "after applying any outcome, the item carries no needs-triage/raw marker."

Category

bug (behavioral). Highest-consequence failure mode: silent infinite re-triage of the same items, wasting every subsequent cycle — the same class of silent-loop failure #480 cites (a mis-worded rule quietly killing a lane). Priority weighted high per the week directive (pipeline correctness).

Note

Distinct from #459 (wait-gate), #478 (routing-rule absorption), #486 (authorship-based scope boundary). This is specifically the missing "clear the raw marker on outcome" mechanic. A concurrent process labeled ~13 more items priority: needs-triage during this cycle, so a re-triage loop here would compound fast.

[kyle-sexton]

This was generated by AI during triage.

Additional facet (2026-07-19 triage cycle 2) — normalization must collapse the WHOLE priority axis, not just the raw marker.

This issue frames the missing mechanic as "remove the raw-intake marker." A concrete cycle-2 incident shows the same root gap has a second face: issue #464 carried both priority: needs-triage and a stale priority: medium. Normalizing it, the literal step-5 action added priority: high and removed needs-triage — leaving priority: medium + priority: high stacked (a priority-axis conflict the repo's own unlabeled/priority-conflict projection flags). It took a manual sweep to strip medium.

So the fix the skill needs is slightly broader than "remove needs-triage": on any outcome, the priority axis must resolve to exactly one label — remove every prior priority:* (including a stale non-triage priority), not just the raw marker. Same "normalize = replace, per axis" principle; two faces (raw-status marker and multi-priority). Worth stating the invariant once as "after applying an outcome, each single-value axis (status-raw, priority) carries at most one label."

[kyle-sexton]

This was generated by AI during triage. · Category: bug (behavioral) · Priority: priority: high (pipeline correctness — silent-loop-kill class). Routed status: ready.

Plan

Make the "Apply outcome" step state the normalization mechanic explicitly: every terminal outcome resolves each single-value axis to exactly one label — remove the raw-intake marker (status/priority needs-triage) AND collapse any stale prior priority:* so exactly one priority remains. Normalization is a replacement, not an addition. Add a closing invariant: "after applying an outcome, each single-value axis (raw-status, priority) carries at most one label; no raw-intake marker remains."

Acceptance

• Applying any outcome leaves the item with no raw-intake marker and exactly one priority:* label.
• An item that entered with a stale non-triage priority plus the raw marker ends with a single normalized priority (regression: the medium+high stack observed in triage cycle 2).

See the comment above for the two concrete faces (raw-marker retention; multi-priority stack).