autonomy vs source-control: contracts disagree on whether a repo-local stamp may supply the merge-admission work class

[kyle-sexton]

This was generated by AI during a loop-lane launch-prompt design session.

Context

Two shipped contracts disagree about where the work class used for merge admission may come from.

autonomy/reference/guardrails/admission-policy.md states: "No repo-local (agent-writable)
surface may supply any admission input — rules, caps, or the work class used for admission."
autonomy/reference/trigger-dispatch.md reinforces it: the adapter "stamps, never defines," and
"no repo-local (agent-writable) surface may supply the class used for admission."

source-control/skills/babysit-loop/SKILL.md's rung partition does exactly that: it reads the
class from "the triage stamp in the item body or labels" — both repo-local and agent-writable —
and uses it as the merge-admission input.

Under the autonomy contract, a GitHub label or issue-body trailer is precisely the surface that
must not supply the class. Under babysit-loop, it is the only surface that does. Any autonomous
lane that classifies an item and then has a sibling lane merge on that classification is a
producer certifying its own work, which is the shape the autonomy rule exists to prevent.

ADR 0009 ratifying the label vocabulary does not resolve this: ratifying what a label means is
not the same as ratifying who may pin it to a specific item without review.

Proposed work

Resolve the contradiction in one direction and record it:

• Either narrow babysit-loop's admission read to a surface the autonomy contract permits (the
  security-governance classification rules), or
• Amend the autonomy contract to permit an operator-ratified repo-local stamp, with the
  ratification requirement stated explicitly, or
• Define a provenance requirement on the stamp — who applied it, and whether an agent-applied
  stamp is admissible — so the distinction is machine-checkable rather than conventional.

Acceptance criteria

• One contract owns where the admission work class comes from; the other cites it
• The rule states whether an agent-applied stamp is admissible for merge admission
• babysit-loop's partition text matches whichever rule wins
• A lane cannot satisfy its own merge gate by stamping the item it is working

References

• plugins/autonomy/reference/guardrails/admission-policy.md
• plugins/autonomy/reference/trigger-dispatch.md
• plugins/source-control/skills/babysit-loop/SKILL.md (rung partition)
• melodic-software/github-iac ADR 0009

Metadata

Surfaced by two independent reviews of a loop-lane launch prompt that had the worker lane stamp
its own work class. The prompt was corrected to forbid it; the underlying contract conflict
remains.

[kyle-sexton]

This was generated by AI during triage.

Verified

Both sides of the contradiction confirmed against the repo source at this commit:

• plugins/autonomy/reference/guardrails/admission-policy.md:88 — "No repo-local (agent-writable) surface may supply any admission input — rules, caps, or the work class used for admission."
• plugins/autonomy/reference/trigger-dispatch.md:82 — "the adapter stamps, never defines, and no repo-local …"
• plugins/source-control/skills/babysit-loop/SKILL.md:156 — the rung partition reads "that item's recorded work-class classification (the triage stamp in the item body or labels)."

The claim holds exactly as filed. A GitHub label and an issue-body trailer are both repo-local and agent-writable, so babysit-loop's admission read is the surface admission-policy forbids.

Classification

• Work class: C4 structural — a contract change spanning two shipped plugins plus a ratified cross-repo ADR.
• Disposition: human-gated. This is genuinely open design space and cross-repo policy: the three candidate resolutions in the body are not reversible implementation details, and picking one rewrites a governance contract. Per the admission gate, C4 is human-gated and human-merge regardless.

Decision carrier

Designated the decision carrier for the work-class-stamp-provenance cluster. One human decision here resolves both items:

• autonomy vs source-control: contracts disagree on whether a repo-local stamp may supply the merge-admission work class #1289 (this item) — may a repo-local, agent-applied stamp supply the merge-admission work class, and under what provenance requirement?
• work-items: label taxonomy and triage do not know the ratified work-class: axis #1288 — blocked by this decision. Its proposed work includes "give triage a stamping step," which is precisely the mechanism this item may forbid. work-items: label taxonomy and triage do not know the ratified work-class: axis #1288 cannot be implemented correctly until this resolves; it carries a blocked-by edge to this item and no separate human-gated label.

Live evidence from this triage pass

This sweep is itself an instance of the problem. An autonomous triage lane applied work-class: labels to the items below; under admission-policy.md:88 those agent-applied stamps are not admissible as merge-admission input. They are recorded here as triage classification only. Until this item resolves, the merge lane should not treat an agent-applied work-class: label as the ratified class — which is the provenance requirement resolution option 3 proposes making machine-checkable.

[kyle-sexton]

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

The #1657 design audit independently reached this same contradiction and handed over a follow-up for it.
Rather than open a second issue, the delta is recorded here — this issue already owns the question and
its third proposed option ("define a provenance requirement on the stamp — who applied it, and whether an
agent-applied stamp is admissible") is the same remedy.

What the audit adds that is not yet stated here:

• The class source is not label-or-nothing. The merge partition treats a body-recorded class as
  sufficient on its own, so an item with no label at all can still be merge-eligible; an item is reported
  unstamped only when both sources are empty. That makes this a live path today, not only a future one.
• The exposure is specifically an externally-authored item body. The lane is forbidden from writing
  the trailer, but nothing tells a consumer not to trust a trailer it did not write, and nothing checks
  who did.
• It is correctly bounded: the PR's own C4/C5 floor is a test on the PR and is stamp-independent, so a
  fork PR stays excluded regardless. The live path is an internally-authored PR close-linking an
  externally-filed, self-stamped issue.

Evidence and citations:
the #1657 determination comment
(gap G6, follow-up 2 — the audit's strongest finding, and one of the two it flags as carrying live risk
today). Not restated here.

Cluster siblings, for whoever picks this up: #1288 (the suggested fix this taxonomy gap blocks) and
#1669 (work-class has no defined taxonomy artifact) are the other two members of the same cluster;
resolving any one of the three in isolation leaves the other two inconsistent.

Suggested addition to this issue's acceptance criteria, if the maintainer agrees:

• Whichever rule wins states it for both class sources the partition reads (body trailer and
  label), so a body-recorded class cannot bypass the answer.