work-items/work-loop: the frontier-tier signal is read from the issue body with no refusal attached

[kyle-sexton]

This was generated by AI while filing the follow-ups handed over by the #1657 design audit.

Context

plugins/work-items/skills/work-loop/SKILL.md selects an item's capability tier and its concurrency
ceiling from a signal the skill explicitly states comes from the issue body rather than a label. That is
the same shape as the body field the same skill refuses as dispatch authority a few dozen lines earlier,
with no refusal attached — an author-editable field selecting execution capability and concurrency.

Citation is in the #1657 design audit — see
the determination comment
(gap G7, follow-up 5). Not restated here.

Proposed work

• Either move the frontier-tier signal off item-body prose onto a source the lane controls (a label, or
  a value written by the tracker seam's configured write identity), or route a body-claimed frontier tier
  through the same refusal the skill already applies to the ratification phrase.

Acceptance criteria

• work-loop/SKILL.md's frontier-tier quota guard names a signal source that is not author-editable
  free-form body prose, or states an explicit refusal for a body-claimed tier that mirrors the
  skill's existing body-prose refusal.
• The skill states why the tier signal resolves the way it does, so the answer reads as an
  application of the skill's body-prose rule rather than an unexplained exception to it.
• Whichever answer lands, the escalation path for an item that genuinely needs the frontier tier is
  still documented, so the fix does not silently make that tier unreachable.

References

• #1657 determination comment — the audit that produced this item (gap G7, follow-up 5)
• Verify untrusted item-body handling in admission and triage #1657 — the parent verification item; its comment thread lists every follow-up filed from this audit

Metadata

Field	Value
Category	work-items / work-loop
Area	security
Ecosystem	markdown

[kyle-sexton]

This was generated by AI during triage. Raw-intake triage complete for this item; claim released. Verdict and routing labels posted below; raw-intake marker cleared.

[kyle-sexton]

This was generated by AI during triage.

Verdict: claim verified verbatim against main — stays human-gated as an interface decision

Work class: structural. The signal in question selects execution capability tier and concurrency ceiling; moving it changes the interface between triage and the work loop.

Verification — the claim is exactly right

Confirmed against origin/main, plugins/work-items/skills/work-loop/SKILL.md L287-290:

Frontier-tier quota guard: items stamped for the frontier capability tier (tier signal from the triage briefing — the issue body, not a label) run at concurrency 1 with adaptive ceiling ${user_config.work_loop_frontier_item_cap_ceiling} (default 2); the general ceiling applies to non-frontier tiers only.

The parenthetical says it outright. So an author-editable free-form field selects execution capability tier and concurrency ceiling, in the same skill that, a few dozen lines earlier (L167-168, L189-192), refuses a different body field as dispatch authority precisely because body prose is untrusted. Same shape, opposite treatment, no stated reason for the difference. The item's characterization is accurate and this is a genuine inconsistency, not a stylistic complaint.

Why it is gated rather than agent-ready

The proposed work is an explicit fork — "Either move the frontier-tier signal off item-body prose onto a source the lane controls, or route a body-claimed frontier tier through the same refusal" — and the two branches have materially different consequences:

• Moving it to a label or seam-written value changes the interface every triage surface writes and every loop reads, and requires a migration path for items already stamped in-body.
• Attaching a refusal leaves the signal where it is and makes the frontier tier reachable only through some other escalation path.

The third acceptance box makes the stakes explicit: whichever answer lands, the escalation path for an item that genuinely needs the frontier tier must still be documented, so the fix does not silently make that tier unreachable. Getting that wrong disables a capability tier fleet-wide. That is not a call for an autonomous lane.

---

Decision-ready summary

The question: where does the frontier-tier signal come from?

RECOMMENDED — Option A: move the signal onto a label

Carry the frontier tier as a label (or a value written by the tracker seam's configured write identity), not body prose.

Why: it resolves the inconsistency at the root rather than papering it with a refusal, and it puts the signal on a surface whose write path is already access-controlled — which is the same reason the role labels live where they do. It also makes the tier readable by the deterministic partition without parsing prose. The escalation path stays obvious and documented: to request the frontier tier, ask triage to apply the label.

Cost: needs a label added to the IaC-owned label set (this lane cannot create it), plus a migration note for any item currently stamped in-body.

Option B: attach the existing refusal to the body-claimed tier

Leave the signal in the body and route a body-claimed frontier tier through the same refusal the skill already applies to the ratification phrase.

Trade-off: no label-set change and a much smaller diff, and it composes naturally with #1715, which is already generalizing that refusal from one field to body prose as a class — under #1715's general rule this case arguably falls out for free. But it makes the frontier tier unreachable through the ordinary path, so the compensating escalation route has to be designed and documented, which is where the third acceptance box bites.

Interaction to weigh

If #1715 lands first, its generalized body-prose refusal may already cover this signal implicitly — which would make Option B partly automatic and, if unnoticed, could disable the frontier tier as a side effect rather than a decision. Worth deciding this one before or alongside #1715 landing. Flagging it on both items.

---

Labels: needs-human, status: needs-decision, work-class: structural, priority: high. Removed priority: needs-triage.

[kyle-sexton]

Flagging a carve-out that touches this issue, from lane instance MELO-LAP-001-worker-202607290838. This decision is unchanged and remains yours — it was explicitly NOT delegated.

Merged PR #1721 pulled the frontier-tier signal parked here INSIDE its autonomous refusal rule in plugins/work-items/reference/item-content-trust.md, as a tightening-only carve-out bounded on the ceiling ordering. This issue is named once in #1721's PR body under "Audit gaps NOT addressed" and appears nowhere in the changed files.

Why that was judged acceptable as interim containment: the carve-out did not decide this issue. It narrowed an already-shipped signal — a body tier claim now buys only a throughput bound, with no admission, no dispatch, and no merge eligibility. It is explicitly conditional and self-voids if the frontier/general ceiling ordering flips. Without it, the general "item text never widens authority" rule would have flatly contradicted shipped behavior.

Both options here remain fully open:

• Move the tier signal to a label — resolving this way DELETES the carve-out instance entirely.
• Keep it in the body with the refusal attached — resolving this way REVISES the carve-out text.

The one real defect: nothing in the merged file records that this instance is under an open human decision. A reader of item-content-trust.md cannot tell the carve-out is provisional. A small mechanical follow-up should add a TODO(#1716) at the carve-out's instance paragraph stating that the tier signal's source is an open human decision and the instance is provisional.

Non-binding, offered only because it was asked for: moving the signal to a label looks more consistent with the G6 fix. That is a suggestion, not a decision — this stays human-gated.

Context: #1715 has been closed as completed by #1721.

[kyle-sexton]

Frontier consensus (binding) — drain bc-f3123271

DECISION: Move frontier/capability-tier signal to a provider-permissioned label (e.g. capability-tier: frontier / tier: frontier). Body claims are context only. Missing label → general tier (fail-closed). Delete tightening-only carve-out once reader flips.

IMPLEMENT_NOW: skill/docs reader flip yes; label provisioning may require standards/IaC (record on issue if blocked).

[kyle-sexton]

Claiming #1716 for implementation on branch cursor/frontier-tier-label-1716-d116.

Label provisioning note: capability-tier: frontier is not yet in this repo's label set (labels are IaC-owned via melodic-software/github-iac). This PR lands the reader flip and documents the provisioning requirement in reference/capability-tier-labels.md; the label must be added upstream before triage can stamp it.

[kyle-sexton]

Claimed by drain session bc-f3123271 — implementing frontier-tier label reader flip.