Skip to content

work-items(triage): status side-exit routing does not reliably clear priority: needs-triage, letting already-decided items re-enter the queue #562

Description

@kyle-sexton

This was generated by AI during triage.

Lane: triage
Category: behavioral

Triggering example

Issue #505 was previously routed to status: needs-decision (a fully-formed decision comment already lives in its body) but still carried priority: needs-triage, so it resurfaced in this cycle's queue query as if it were raw/unrouted intake. It wasn't — the triage pass had to spend a read-and-confirm step to establish nothing further was needed, then strip the stale label.

Observed vs expected

  • Observed: routing an item to a status side-exit (status: needs-decision, and plausibly status: needs-info) does not reliably clear priority: needs-triage in the same action, so already-decided items can re-enter the needs-triage queue query indefinitely.
  • Expected: every side-exit routing (needs-decision, needs-info, needs-human, status:ready) is defined to always remove priority: needs-triage in the same step, so the queue query is a true measure of unrouted intake.

Suggested fix

Add this as an explicit invariant to the triage skill/lane rules (candidate line for #478's absorption list: "every routing outcome — status:ready, needs-human, status:needs-decision, status:needs-info — removes priority: needs-triage in the same edit; never leave both labels present").

Related

478 (v4 loop-prompt routing rules absorption — natural home for this invariant)

Metadata

Metadata

Assignees

Labels

priority: mediumReal value, no hard deadline; normal backlog flow.status: readyTriaged, unblocked, and fully specified; eligible to pick up.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions