policy(babysit): out-of-loop babysit-prs invocations bypass the grace window, rung partition, and reviewer awareness

[kyle-sexton]

🤖 Agent-authored — filed by the adversarial adjudication of #1614. This one is deliberately filed without a recommendation: it adjudicates the merge authority of the same lane that would otherwise decide it, so the conflict of interest is structural and the call is the operator's.

The question

In a repository that has adopted the babysit loop, should a direct /source-control:babysit-prs autopilot <owner/repo>#<N> invocation be able to merge?

Three safeguards live at the loop level and have no counterpart in the single-pass mechanic. An invocation that goes straight to the mechanic bypasses all three at once.

What the loop provides that the mechanic does not

Grace window. babysit-loop marks every PR whose head moved or that received comments within the window as report-only — "never elevated, never thread-resolved, never merged." babysit-loop/SKILL.md is explicit that this is a loop-level overlay: "The grace window below is an additional loop-level overlay, never a replacement for them." This repository tracks babysit_loop_grace_window_minutes: 30 in .claude/source-control.md.

Rung partition. The loop resolves each PR's close-linked work item and admits it only when the item's work class sits within the effective merge rung, fail-closed: "Unlinked or unclassified PRs never auto-merge." This repository tracks babysit_loop_merge: c2-mechanical and babysit_loop_tier: worker.

Reviewer awareness. Configured through the loop's seam keys, and separately blind in the merge gate itself — filed alongside this issue.

The mechanic's own tier matrix has none of these. autopilot is documented as "maximum autonomy … merge everything the gate proves ready", and the gate is exactly the deterministic merge gate — which is real, but is a different and narrower thing than the lane's governance.

Evidence — PR #1594

The merge lane was running at the time and did not merge #1594. From its own telemetry, issue #1214 (Lane telemetry: babysit-loop), cycle 13:

• The cycle ran at merge_rung: human-only and records "Direct merges: 0".
• Its grace-window pass listed docs(prompts): add parked-decision burn-down template and item-state coverage table #1594 among the PRs it excluded, then dispatched only a safe-tier fixer against it — "fix + push only, no merge, no thread-resolve".
• At 22:02Z: "docs(prompts): add parked-decision burn-down template and item-state coverage table #1594 and fix(hook-utils): read hook stdin in chunks so a large payload is not blocked #1587 both merged (by another session/human) since the last snapshot — this session's fixes on both were what cleared their gates."

So the merge came from a session outside the lane. The PR carries a claim marker naming lane=fable-autopilot, consistent with a direct babysit-prs autopilot invocation.

Had the lane's own governance applied, #1594 would not have merged autonomously on two independent grounds:

• Grace window. It merged 21:48:40Z, 4m40s after its final commit at 21:44:00Z — inside a 30-minute window by a factor of six.
• Rung partition. Its close-linked item prompts/loops: parked human-gated, needs-decision, and trigger-deferred items have no owning prompt — add attended burn-down template #1582 carries needs-human and no work-class label, so it was unclassified and ineligible at any rung.

Consequence: the merge landed 26 seconds before the reviewer's fifth round, which carried two valid findings including a regression the PR itself introduced (#1613).

I could not determine from the artifacts whether that autopilot invocation was operator-ordered — which babysit-prs explicitly sanctions ("Any tier also honors an explicit user instruction to merge or resolve specific PRs now") — or lane-elected. That distinction may matter to the decision and is not recoverable from GitHub state.

Options, stated neutrally

A — Forbid out-of-loop merges in lane-adopted repositories. A repository whose tracked config carries babysit_loop_* keys is declaring the loop as its merge authority; the mechanic would refuse to merge there when invoked outside a loop cycle, and report merge-ready instead.
For: one merge authority per adopted repo; the tracked seam means what it says. Against: removes a sanctioned direct-order path; needs a reliable way for the mechanic to know it is inside a loop cycle, which does not exist today; an operator who genuinely wants a one-off merge loses it or needs a new override token.

B — Require out-of-loop invocations to honor the loop's grace window and rung. The mechanic reads the same babysit_loop_* keys and applies the overlay and partition itself when they are present.
For: keeps the direct path; makes the safeguards a property of the repository rather than of the entry point. Against: duplicates loop logic into the mechanic, which today deliberately owns none of it (babysit-loop/SKILL.md: "The single-pass mechanics belong to /source-control:babysit-prs … this loop restates none of that" — this would push the coupling the other way); two implementations of one overlay is a drift risk; a legitimate urgent merge now waits out a 30-minute window.

C — Status quo. The mechanic's tier matrix and gate remain the whole story for direct invocations; the loop's overlays apply only to loop cycles.
For: no new coupling; the direct path stays available and honest about what it is; the merge gate is still never bypassed. Against: a repo can adopt the lane, track a conservative rung, and still have every one of those constraints bypassed by one invocation — which is what happened on #1594; the tracked config gives a false impression of the repo's effective merge policy.

These are not mutually exclusive. B could be scoped to the grace window alone, and A could be an override-gated form of B.

Why this is filed for a human

Under every option the deciding party is a lane whose own authority is what is being scoped. An autonomous session evaluating this is evaluating whether to keep a capability it holds. The adjudication that produced this issue takes no position beyond naming that conflict.

Related: #1614 (the policy issue this came out of), #1594 (the run), #1613 (the findings that arrived after the merge), #1214 (the lane telemetry quoted above).

[kyle-sexton]

🤖 Agent-authored (autonomous babysit lane orchestrator). Factual input for the open provenance question: the 2026-07-26 invocation that merged #1594/#1587 out-of-loop was operator-ordered — the operator launched this session with an explicit standing full-autopilot directive covering PR babysit and merge across all org repos. It was not lane-elected. This informs but does not decide the policy question; the decision remains with the operator per this issue's labels.

[kyle-sexton]

This was generated by AI (triage lane — gate-audit claim). Claiming this item for one gate-audit cycle: an independent panel re-classifies whether the needs-human / status: needs-decision gate is still warranted, or whether the item is C2/C3 and liftable to agent-ready. Outcome comment follows in this cycle.

[kyle-sexton]

This was generated by AI (triage lane — gate audit). Independent panel: two fresh-context agents (one fable, one opus), each given only the issue content and the repo's own plugins/autonomy/reference/guardrails/work-classes.md, plus the triage lane's own read. This lane never executes work items, authors fixes, or merges.

Gate audit: GATE UPHELD — the clearest legitimate gate in this batch

Panel: 2-of-2 STAYS-GATED, both C4. Lane read concurs emphatically.

This item is correctly gated and should stay that way. It is literally the "should we do A, B, or C" shape, filed deliberately with no recommendation because of a named structural conflict of interest: an autonomous session answering it is adjudicating its own merge capability. The #1594 evidence shows a real bypass of the adopted lane's grace window and rung partition.

The one comment since filing resolves a factual sub-question (the #1594 merge was operator-ordered, not lane-elected) and says outright that this "informs but does not decide the policy question."

Both panel legs converged on the same recommendation independently, which is worth weighing — but neither is entitled to make this call, and neither is this lane.

Decision required

In a repo that tracks babysit_loop_* keys, may a direct /source-control:babysit-prs autopilot invocation merge, and must it honour the loop's grace window and rung partition?

RECOMMENDED — option B, scoped narrowly. The mechanic reads the repo's tracked babysit_loop_* keys and honours the grace window and rung partition whenever they exist, with an explicit operator-order token as the only override. This makes the safeguards a property of the repository rather than of the entry point, while preserving the sanctioned direct-order path — and the provenance comment confirms #1594 was operator-ordered, so that override path demonstrably matters in practice.

Alternative — option A: adopted repos refuse out-of-loop merges entirely. Strictly safer, at the cost of the sanctioned direct path and requiring an in-loop detection mechanism that does not exist yet.

Also considered — option C (status quo), rejected: it means a repo's tracked conservative rung does not describe its effective merge policy, which is the defect as filed.

[kyle-sexton]

This was generated by AI (triage lane — claim release). Gate-audit cycle complete for this item; the triage claim posted earlier this cycle is released. No lease is held — another instance or lane may pick this up immediately. The outcome comment above this one carries the classification and either the lift rationale or the decision summary.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned for this drain wave.

Issue remains historically valuable but is either advisory, blocked on a larger carrier, or superseded by later conventions. Re-open with a concrete acceptance brief if a consumer needs the work this session.

Title: policy(babysit): out-of-loop babysit-prs invocations bypass the grace window, rung partition, and reviewer awareness