decision: raise babysit_loop_merge to c3-autonomous, or leave it — the guardrail matrix has no C3 auto-merge cell

[kyle-sexton]

This was generated by AI during triage.

Decision requested

Raise babysit_loop_merge in this repo's tracked .claude/source-control.md from c2-mechanical to c3-autonomous, or leave it.

This was carried forward as a ready-to-execute config edit. It is not: making it would put the tracked seam in conflict with the governance contract it is supposed to operate within. Filing the conflict rather than resolving it unilaterally, because a merge-authority raise is explicitly an operator-ratified act.

The conflict

plugins/autonomy/reference/guardrails.md's matrix sets the C3 merge policy to human merge — flatly, with no promotion clause. Compare the neighbouring cells, which the same table words deliberately differently:

Class	Merge policy (verbatim)
C2	auto-merge ELIGIBLE after per-class promotion trigger; ships human-gated
C3	human merge
C4	human merge always
C5	human merge always

C2 names a promotion path. C4/C5 say "always" and work-classes.md confirms they never promote. C3 sits between: not "always", but no promotion trigger either.

work-classes.md's promotable-cell table lists exactly three rows — C2 auto-merge, C3 AI review advisory→blocking, and C4/C5 merge (never promotes). There is no C3 auto-merge cell, so there is no evidence predicate a C3 merge raise could satisfy. The one C3 row promotes AI review from advisory to blocking — a verification knob, not a merge-authority knob.

Meanwhile babysit-loop's SKILL.md does implement c3-autonomous (step 3: "at c3-autonomous, C2 and C3"), and the loop-lane convention describes higher rungs as "further tracked-seam flips — recorded, human-ratified". So the lane mechanism offers a rung the guardrail matrix does not authorize.

Second, independent problem: the current rung's own evidence

Even c2-mechanical — already live — has an unmet predicate. work-classes.md suggests ≥20 autonomous C2 completions over ≥14 days with 100% deterministic-gate pass and 0 human-reverted merges before the C2 auto-merge cell is eligible.

Live check of this repository: all 651 merged PRs were merged by kyle-sexton. Zero autonomous merges, ever. No autonomy binding file exists here to record a promotion either. So the C2 cell is enabled by adoption but has not earned its evidence, and there is no telemetry from which C3 confidence could be built.

Options

1. Leave at c2-mechanical; let the C2 rung earn its evidence first. Recommended. Costs throughput now, but it is the only option that does not require resolving a contract conflict first, and the evidence it generates is the input any later C3 decision needs.
2. Amend the guardrail contract, then raise. If C3 auto-merge is genuinely wanted, the honest sequence is: add a C3 auto-merge cell with an evidence predicate to work-classes.md, update the matrix row, then flip the seam. Larger than a one-line edit, and it is a change to the governance surface itself.
3. Raise the seam anyway. Rejected as an option to take silently — it makes the tracked config assert an authority the contract withholds, and the whole point of a seam-only, human-ratified raise is that it is reviewable against the contract.

Impact if raised (live counts, 2026-07-25)

40 open agent-ready items, all label-stamped: 3 mechanical, 34 scoped, 3 structural. At c2-mechanical 3 are merge-eligible; at c3-autonomous, 37.

Note these numbers move fast — the same count read 50, then 44, then 40 within one day as the backlog drained. Re-run before deciding.

full-autonomy is not recommended under any branch: over c3-autonomous it adds only C4 structural and C5 untrusted-provenance — refactors, migrations, contract changes, and fork PRs — which are the worst candidates for unattended landing, for near-zero throughput gain.

Related

Context: #1288–#1295 (loop-lane issues), and the prompts document landing in #1320, whose profile section records the rung and these counts.

[kyle-sexton]

This was generated by AI during triage.

Triage — raw marker retired; designated decision carrier for the merge-rung cluster

Cluster detected. This item and #1309 share one underlying decision — whether babysit_loop_merge in .claude/source-control.md rises from c2-mechanical to c3-autonomous. They reach it from opposite premises:

• chore(source-control): raise babysit_loop_merge rung to c3-autonomous #1309 treats the raise as already operator-ratified and files it as a ready-to-execute config edit.
• decision: raise babysit_loop_merge to c3-autonomous, or leave it — the guardrail matrix has no C3 auto-merge cell #1388 (this item) argues the edit cannot be made safely yet, because the guardrail matrix has no C3 auto-merge cell to authorize it.

Both cannot be right, and an executor picking up #1309 in isolation would land a config change that asserts an authority the governance contract withholds. Per the triage cluster rule, this item is the decision carrier — it frames the fork, states the contract conflict, and carries a RECOMMENDED option. #1309 is now linked blocked-by this item and will not surface on the autonomous frontier until this resolves. One human decision here settles both.

Cluster members: #1309.

Verified, not taken on trust. The contract conflict this item reports holds against the actual files:

• plugins/autonomy/reference/guardrails/work-classes.md's promotable-cell table lists exactly three rows — C2 auto-merge, C3 AI review advisory→blocking, and C4/C5 merge ("never promotes — human merge always; no evidence predicate exists for these cells"). There is indeed no C3 auto-merge cell, so no evidence predicate exists that a C3 merge raise could satisfy. The one C3 row promotes a verification knob, not a merge-authority knob.
• docs/conventions/loop-lane/README.md §1 confirms merge-rung raises are seam-only and floored at the seam-config rung, and §2 confirms needs-human is the escalation marker — consistent with this item's framing that the raise is an operator-ratified act, not an executable default.

Priority: high — reserved here for items that block other work; this one blocks #1309.

Routing: stays needs-human, and is not decision-defaulted. The recommended option (leave at c2-mechanical) is well-grounded, but the alternative is not maintainer-vetoable in the reversible sense the decision-default exit requires: option 2 amends the governance surface itself, and option 3 puts tracked config in conflict with its own contract. A merge-authority raise is the one class of change this repo's convention makes explicitly human-ratified. Fails closed.

No work-class: label applied, deliberately. The executable shape is not determined until the fork resolves — option 1 is a literal no-op, option 2 is a structural contract change. Stamping a class now would assert a scope that does not exist yet. It gets one if and when the decision selects an option with work attached.

Note for the decider: this item's own live counts move fast (it records 50 → 44 → 40 agent-ready items within one day). Re-run them before deciding rather than reading the recorded figures.

[kyle-sexton]

This was generated by AI during triage.

Status of the surrounding work — this issue is now the last open item

The effort this decision came out of is closed:

Item	State
claude-code-plugins#1320 — loop-lane prompts source-controlled	merged (8e00f71b1d)
standards#270 — markdownlint-home component	merged (5a1024d24c)
dotfiles#328 — sync carrying dot_markdownlint-cli2.jsonc	merged
#1412 — security-review gate	closed, retracted as a misdiagnosis
this issue	open — the only remaining decision

The merged prompts document at prompts/loops/loop-lane-prompts.md now records this decision as pending rather than presenting the rung raise as a ready edit, and its ready-to-paste merge lane carries --merge human-only so it cannot auto-merge C2 while the promotion evidence is unrecorded. Whichever way this lands, that document is the surface to update.

The recommendation, restated

Leave babysit_loop_merge at c2-mechanical. Two independent reasons, both verified against the plugin sources rather than inferred:

1. No C3 auto-merge cell exists to promote. The guardrail matrix sets C3 merge policy to a flat human merge, and work-classes.md's promotable-cell table lists exactly three rows — C2 auto-merge, C3 AI review advisory→blocking, and C4/C5 (never promotes). There is no evidence predicate a C3 merge raise could satisfy, because the cell is not modeled as promotable. babysit-loop implements a c3-autonomous rung the guardrail contract does not authorize.
2. The rung already in force has not earned itself. The C2 predicate is ≥20 autonomous C2 completions over ≥14 days with 100% deterministic-gate pass and 0 human-reverted merges. Live count: all merged PRs in this repository were merged by the operator — zero autonomous merges, ever. No autonomy binding file exists here to record a promotion either.

Raising to C3 would make the tracked seam assert authority the governing contract withholds, on a repository that has generated no evidence for the tier below it. If C3 auto-merge is genuinely wanted, the honest sequence is to amend the guardrail contract first — add a C3 auto-merge cell with an evidence predicate — and only then flip the seam.

Note on the impact numbers

Any absolute count of eligible items is stale on arrival. Over one day this backlog's open agent-ready count read 50, 44, 40, 38, 28, then 25 — it fell by three between two commands in a single session, because the worker lane drains continuously. Run the union command in the merged prompts document for live figures rather than quoting a number from an earlier comment.

[kyle-sexton]

Decided: stay at c2-mechanical

Operator decision, 2026-07-25. babysit_loop_merge is not raised to c3-autonomous; the tracked .claude/source-control.md is unchanged.

Why

Throughput was never the binding constraint — authorization was.

• The guardrail matrix sets C3 merge policy to a flat human merge, with no promotion clause. Compare the neighbouring cells, worded deliberately differently: C2 reads auto-merge ELIGIBLE after per-class promotion trigger, C4/C5 read human merge always. C3 sits between: not "always", but with no trigger either.
• work-classes.md's promotable-cell table lists exactly three rows — C2 auto-merge, C3 AI review advisory→blocking, and C4/C5 (never promotes). There is no C3 auto-merge cell, so no evidence predicate exists that a raise could satisfy. The one C3 row promotes a verification knob, not merge authority.
• The rung already in force has not earned itself either: the C2 predicate is ≥20 autonomous C2 completions over ≥14 days with 100% deterministic-gate pass and 0 human-reverted merges, and this repository has recorded zero autonomous merges, ever.

Raising the seam would have made the tracked config assert authority the governing contract withholds, on a repository that has generated no evidence for the tier below it.

Recorded, not just decided

#1441 (merged, 48abe94621) updates prompts/loops/loop-lane-prompts.md, which described the raise as "filed as an operator decision rather than a ready edit" — accurate when it landed, stale once this was settled. The document now carries the outcome, the reasoning, and the only legitimate path to reopening it: amend the guardrail contract to define a C3 promotion cell first, then flip the seam — never the reverse.

That last part is the point of writing it down. The eligible-count arithmetic in that document is an argument for raising (a handful of mechanical items versus nearly the whole backlog); without the record, a future reader finds the argument and no trace of why it was declined.

Not recommended under any future branch

full-autonomy adds only C4 structural and C5 untrusted-provenance over c3-autonomous — refactors, migrations, contract changes, and fork PRs. Least suited to landing unattended, for near-zero throughput gain over c3.

Closing as decided.