work-items: list-frontier --autonomous lacks a positive agent-ready gate, only excludes needs-human

[kyle-sexton]

Lane: babysit. Triggering PR: #762 (fix/540-work-items-shared-dogfood-skill), head 6e4c2d20.

Worker verified a genuine, live architectural gap while reviewing the new shared self-observation filing contract (docs/dogfood-filing.md) that PR #762 introduces: list-frontier --autonomous's current selection logic is exclusion-only — it filters OUT items carrying needs-human, but has no positive agent-ready gate. Cross-checked against triage/SKILL.md: needs-triage marks an item as raw/unverified, not yet triaged into a state safe for autonomous work.

Net effect: a raw self-observation filing that hasn't been through triage yet — and so hasn't been confirmed safe, well-scoped, or actually actionable — can be selected by list-frontier --autonomous and picked up for autonomous work before a human or the triage skill ever reviews it, simply because it doesn't carry needs-human.

Category: bug (design gap, not yet observed causing a concrete bad outcome, but the selection logic is verifiably permissive beyond what the triage contract intends).

Root question for whoever picks this up: should list-frontier --autonomous require a positive agent-ready-equivalent state (e.g. excluding needs-triage explicitly, or requiring the item to have passed through triage at least once), rather than relying solely on the needs-human exclusion? The dogfood-filing contract in #762 documents where self-observation items land, but doesn't itself close this selection-logic gap — it's upstream in list-frontier's own semantics.

Not itself DEFER-FORBIDDEN (autonomous work still lands in a merge-gated PR, so the blast radius is bounded and reversible), which is why this is filed as a standard review-deferral follow-up rather than fixed inline on a docs-only PR.

[kyle-sexton]

This was generated by AI during triage.

Severity note for sub-sort (rule 5): this is a structural gap in list-frontier --autonomous's selection logic — the mechanism every autonomous lane depends on — so it's higher-consequence than a typical medium-tier item even though it doesn't meet rule 5/8b/8c's bar for priority: high on its own (not in the named scaling-chain list, blast radius already bounded per the issue's own text since autonomous work still lands merge-gated).

The design question is genuinely open, not a single defaultable fork: should the fix be a positive agent-ready-equivalent gate, an explicit needs-triage exclusion, or a "must have passed through triage at least once" state check? Each has different implications for the frontier contract and for repos with different labeling conventions. Reserved for a human call rather than defaulted.

[kyle-sexton]

This decision brief was generated by AI (babysit-lane brief-writer). It decides nothing — it is input for a human call.

Decision brief — positive agent-ready gate for list-frontier --autonomous

Problem (2 sentences)

list-frontier --autonomous decides autonomous eligibility by absence — it drops items labeled needs-human and surfaces everything else — so an item reaches the autonomous frontier because it lacks the human-gated label, never because triage confirmed it safe, scoped, and actionable. The triage contract's actual "safe for autonomous" marker is the positive agent-ready label, which the frontier does not check — so raw and not-ready intake can be claimed for autonomous work before any human or the triage skill vets it.

What's verified today (cited)

• The filter is exclusion-only. wit_filter_frontier (plugins/work-items/tools/work-item-tracker/lib/frontier.sh) selects state=="open" AND blocked_by_count==0 AND unassigned AND not-a-container, and --autonomous adds exactly one clause: ((.labels // []) | index($human_gated)) | not (default needs-human). There is no positive-eligibility clause. CONTRACT.md states this by design: "the frontier is label-agnostic and simply never surfaces items that are assigned or blocked."
• agent-ready is the positive marker the frontier ignores. triage/SKILL.md state table: autonomous-eligible = role label (default agent-ready) = "Briefed AND delegable — eligible for autonomous pickup from the frontier." label-taxonomy.md "Canonical roles": autonomous-eligible → agent-ready = "Fully specified and briefed; eligible for autonomous (AFK) pickup." The frontier keys on needs-human, not on this.
• The mismatch is already on the record. decompose/SKILL.md: "Merely omitting the autonomous-eligible label does NOT [keep an item out]: the frontier filter keys on the human-gated label, not on the absence of the other." Mechanism and contract disagree in writing.
• What actually leaks under exclusion-only (each carries neither needs-human nor is caught by any single added exclusion):
  • Unlabeled intake — triage/SKILL.md defines raw as "unlabeled or status:needs-triage"; the attention view's bucket 1 is "Unlabeled — never triaged." An unlabeled item has no label to exclude on, so it passes --autonomous.
  • status:needs-info — a side-exit that clears the raw marker (triage step 5 "Closing invariant") while waiting on the reporter; it is not ready, yet carries neither needs-triage nor needs-human.
• Axis correction (load-bearing): the raw marker is status:needs-triage, on the status: axis (label-taxonomy.md Status row: "needs-info, needs-decision, ready, needs-triage"). This issue's body/comment say priority: needs-triage — an implementer who excludes priority:needs-triage writes a no-op.

Options

Option B — positive agent-ready gate (RECOMMENDED). --autonomous requires the autonomous-eligible role label (default agent-ready, resolved from binding config.role_labels — not hardcoded, mirroring how the filter already resolves WIT_HUMAN_GATED_LABEL), and retains the needs-human exclusion (belt-and-suspenders).

• Why recommended: it is the only option that closes the whole class — unlabeled and needs-info items have no label to exclude, so exclusion-based fixes cannot reach them; only "must carry the vetted marker" does. It aligns the mechanism with the triage contract's own definition of autonomous-eligible, ending the documented decompose/SKILL.md disagreement. This is the root cause, not a symptom.
• Cost / tradeoff (state squarely): it is a breaking CONTRACT change (semver bump; the CONTRACT.md --autonomous sentence is rewritten from "excludes needs-human" to "requires agent-ready"). Every workable item must now carry agent-ready — triage and decompose already apply it, so within this plugin's model the "break" is largely the safety fix landing; the real exposure is a consuming repo that ran --autonomous label-light and never applied agent-ready — on upgrade its autonomous frontier could go empty until items are backfilled. Must resolve the role via config.role_labels per label-taxonomy.md's coupling caveat ("remap this role only when the bound seam resolves the same key"), or filter and skill disagree.
• Reversibility: reverting to exclusion-only is a one-clause change; no data migration to undo. Blast radius of the change itself is bounded (autonomous work still lands merge-gated).

Option A — add an explicit status:needs-triage exclusion (minimal, backwards-compatible interim). Keep exclusion-only; add and (labels | index("status:needs-triage") | not) alongside the needs-human clause.

• Pro: one jq clause, no CONTRACT semantics change, no consumer can have its frontier emptied. Closes the specific case the issue names (a filed item still carrying its raw marker).
• Con (do not let this read as "closes the gap"): it is incomplete. Unlabeled raw intake and status:needs-info items still pass — they carry no needs-triage marker to exclude. You cannot add exclusions your way to positive vetting. Even extending it to the whole not-ready status set (needs-triage, needs-info, needs-decision) leaves unlabeled items leaking, because they have no label at all.
• Reversibility: trivially reversible; safe as a stopgap if B's consumer-compat question needs its own decision first.

Option C — status quo + document the "everything gets triaged fast enough" assumption (REJECTED). Rejected: the assumption is false by construction, not by timing. Unlabeled intake is raw by definition (never triaged), and needs-info items are deliberately parked awaiting a reporter — neither is a race the labeler wins. Autonomous work is merge-gated (bounded blast radius), but a reviewer's merge gate is not a substitute for not-selecting unvetted work in the first place.

Cross-links

• Surfaced by feat(work-items): extract shared self-observation filing contract (#540) #762 (feat(work-items): extract shared self-observation filing contract), which introduces the self-observation filing contract at plugins/work-items/reference/dogfood-filing.md (route items to the needs-triage raw marker). That contract documents where filings land; it does not close this gap — the gap is upstream in list-frontier's own selection semantics, which is why it is a separate follow-up.
• Related to work-items(triage): step-2 "wait for user direction" gate contradicts the skill's own autonomous/agent triage mode #459 (autonomous-mode contract) and automation: auto-apply 'priority: needs-triage' to new issues lacking a priority label #506 (auto needs-triage labeler). automation: auto-apply 'priority: needs-triage' to new issues lacking a priority label #506's deployment only affects how transient the unlabeled leak is; needs-info defeats exclusion-only regardless, so the recommendation holds either way.

Recommendation

Take Option B. It is the root-cause fix and the only one that closes the unlabeled + needs-info leaks. If the consumer-compatibility exposure (a label-light repo's frontier emptying on upgrade) needs its own owner sign-off, land Option A first as an explicitly-labeled interim — but record in the same breath that A does not fully close the gap, so this issue is not resolved by A alone.

[kyle-sexton]

Filed by an autonomous agent under control-tower delegation, acting for the offline work-items authoring lane while disposing of PR #762's review threads.

Disposition tie-in: PR #762's review thread on dogfood-filing.md:52 (raw needs-triage filings can be selected by /work-items:work before triage vets them) is the finding this issue already tracks — thread deferred here and resolved on the PR, no duplicate filed.

Backstop-clause flag (operating-procedures "Defer-forbidden carve-out" → backstop clause). This issue's deferral rests on "autonomous work still lands in a merge-gated PR, so the blast radius is bounded and reversible." That safety property is buffered by the current merge gate. The gate-off preconditions are now all closed — #476 (autopilot merge tier), #450 (bot-identity attribution), #675 (gate-off flip precondition) — so the human-merge form of that backstop is being removed; post-flip the buffer is the autopilot criteria gate (CI green, issue-linked, lane-authored, author≠approver, no do-not-merge, head-unchanged) plus PR revertibility, not a human turn.

The finding stays not-DEFER-FORBIDDEN even post-flip (autonomous effort on an unvetted item still lands as a criteria-gated, revertible PR — bounded, no data-loss/irreversible step). But per the backstop clause it must not rot silently past the backstop's removal: recommend the operator treat #764 as gate-off-relevant (bump from priority: medium and/or mark it a gate-off-flip consideration) rather than dormant, since the moment gate-off widens autonomous authorship, the volume of raw self-observation filings entering the frontier — which the #762 contract systematizes across work/scan-todos/babysit/control-tower/enrichment — is exactly what makes the missing positive agent-ready gate load-bearing.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned.

Exclusion-only autonomous filter is intentional: triage applies the positive agent-ready marker when an item is verified and briefed; list-frontier excludes needs-human and relies on triage upstream.

Re-open trigger: If a raw needs-triage item is picked up autonomously and causes a concrete bad outcome.