source-control(babysit-prs): autopilot direct-gate route is inert under enabled tier — no actor runs the approver pass on zero-blocker PRs

[kyle-sexton]

Summary

Found by Codex on PR #706 (thread 2026-07-20T18:14Z, SKILL.md:259). The #706 fix correctly wired tier flags into the zero-blocker direct-gate path — but that path never runs the second-account review/approve step, so under an ENABLED tier every clean PR lacks the distinct-bot approval and defers to the human list. The direct-gate route is inert; only PRs that pass through a worker fix round (which runs the review pass) can autopilot-merge.

Direction: fails CLOSED (over-defers, never wrongly merges) — deferrable per the DEFER-FORBIDDEN direction test, NOT a carve-out class.

Decision needed

Who runs the second-account review pass on a no-worker PR? Options: (a) orchestrator triggers the approver-bot review as part of the direct-gate flow (needs an idempotent trigger + live-head pin); (b) a lightweight per-cycle approver sweep over zero-blocker PRs; (c) accept worker-path-only autonomy for v1 (status quo, documented).

Trigger

Tied to the gate-off flip milestone: harmless while the tier is disabled or while worker-path volume dominates; becomes the main autonomy gap once the flip lands and clean PRs are the common case.

Related

• docs(source-control): wire babysit autopilot §3 to the tier flags, specify the approve mechanic and review-context precondition (#675) #706 (where found), source-control(babysit-prs): wire autopilot §3 merge command to the tier flags + specify the second-account approve mechanic — GATE-OFF FLIP PRECONDITION #675, feat(source-control): babysit autopilot merge tier — bot-account review + criteria-gated merge #476 (tier), feat(source-control): babysit autopilot merge tier, gate-enforced and disabled by default #665 (implementation)

[kyle-sexton]

This was generated by AI (decide lane — decision-brief pass; surfaced via coverage sweep — this decision was unlabeled).

Problem

Under an enabled autopilot merge tier, a clean PR that reaches the gate with zero blockers and no untriaged feedback never spawns a worker — it takes the direct merge-gate check only, and nothing in that path runs the second-account review or submits the distinct-bot approval the gate requires. So the direct-gate route is inert: every zero-blocker PR fails the distinct-bot criterion and defers to the human list, leaving worker-path PRs (which pass through a fix round that does run the approve pass) as the only ones that can autopilot-merge.

Today (verified against main)

The approve pass lives only in the worker path; the direct-gate path has no actor for it.

• Direct-gate route — a non-draft PR with zero blockers and no untriaged material feedback "gets no worker, only a direct mode-appropriate source-control-babysit-merge gate check … an enabled autopilot merge tier adds the tier flags, never the flagless base command." SKILL.md:252-262. No review/approve step appears in this branch.
• Worker path runs the approve pass — autopilot's per-PR worker fixes, resolves, then "after the worker's final push … merges … through the pinned gate." SKILL.md:141-160. The enabled-path merge command and approve mechanic are both documented as "After the worker's final push" — reference/safety.md:171-174, :185-203.
• The gate only verifies, never creates, the approval — "the gate only verifies one exists on the live head, it never creates it … submitted out-of-band by the agent." reference/safety.md:185-186. With no actor on the direct-gate path, the distinct-bot criterion (--approver-bot-logins, author ≠ approver) can never be satisfied there → fail-closed fallback to the human merge-ready list.
• Disabled by default — babysit_autopilot_merge_tier defaults false; "PRs go to the human merge-ready list." SKILL.md:296. Harmless while disabled or while worker-path volume dominates; becomes the dominant gap once the flip lands and clean PRs are the common case.

Direction: fails CLOSED (over-defers, never wrongly merges) — deferrable, not a carve-out class. All three options below are highly reversible: the tier ships disabled, and each is a prose/wiring change gated behind the separate, announced flip.

Options

(a) Orchestrator triggers the approver-bot review inside the direct-gate flow — RECOMMENDED.
When a zero-blocker PR takes the direct-gate branch, run the same genuine review pass + distinct-bot gh pr review --approve the worker path already specifies (safety.md:185-203), pinned to the live head, before the gate check in the same cycle.

• Why: root-cause fix at the exact site the gap manifests; reuses the already-specified, live-head-pinned approve mechanic; makes the tier coherent — every clean PR gets the same genuine bot review whether or not it needed a fix round. Single-cycle, no new phase.
• Requires: an idempotent trigger (don't double-approve an existing live-head approval) and the live-head pin (approve the head --expected-head will check). Design note: to preserve producer ≠ reviewer, run the pass in a fresh minimal approver context rather than the orchestrator inline, matching the skill's fresh-worker review posture.
• Reversibility: HIGH — prose/wiring behind the disabled flag.

(b) A lightweight per-cycle approver sweep over zero-blocker PRs.
A separate orchestrator phase reviews + approves eligible zero-blocker PRs; the unchanged merge step picks up the approval.

• Trade-off: decouples approve from merge (merge command untouched) but adds a second orchestrator phase and up to a cycle of latency if the sweep and merge land in different cycles; more moving parts than (a) for the same outcome.
• Reversibility: HIGH.

(c) Accept worker-path-only autonomy for v1 (status quo, documented).
Ship the tier as-is; document that only PRs passing through a fix round autopilot-merge, and clean zero-blocker PRs defer to the human list.

• Trade-off: simplest and fully fail-closed, but leaves the tier's throughput win unrealized for the clean-PR majority — precisely the case that dominates after the gate-off flip. Acceptable only if the flip is deferred until (a)/(b) lands.
• Reversibility: HIGH (it is the current behavior).

Recommendation: (a). It closes the gap at its root, reuses machinery that already exists and is live-head-safe, and is the natural flip-precondition so the tier is coherent the moment gate-off lands. (c) is a reasonable v1-ship-now posture only if the flip is explicitly held until (a) or (b) is in place — otherwise the flip re-opens this exact gap as the common case.

Cross-links

• control-tower: closure-audit batch 2026-07-20 — operator decisions (fold-member consolidation, re-baseline additions, label normalization, title convention) #607 — the gate-off-flip comment ("GATE-OFF FLIP: ALL PRECONDITIONS MET", 2026-07-20) sets v1 scope: "worker-path PRs autopilot-merge; zero-blocker direct-gate PRs still defer to the human list — source-control(babysit-prs): autopilot direct-gate route is inert under enabled tier — no actor runs the approver pass on zero-blocker PRs #738 (priority: high, flip-milestone) tracks the design decision to close that gap."
• feat(source-control): babysit autopilot merge tier — bot-account review + criteria-gated merge #476 — autopilot merge tier proposal (throughput bottleneck; bot-account review + criteria-gated merge).
• docs(source-control): wire babysit autopilot §3 to the tier flags, specify the approve mechanic and review-context precondition (#675) #706 — §3 wiring + second-account approve mechanic + review-context requiredness precondition (where this gap was found).
• feat(source-control): babysit autopilot merge tier, gate-enforced and disabled by default #665 — tier implementation, gate-enforced, disabled by default.

Routing recommendation (triage lane): apply status: needs-decision — this priority:high flip-milestone decision is currently unlabeled for the decision queue.

[kyle-sexton]

This was generated by AI during triage. Gate-audit pass complete for this item; claim released. Panel verdict and decision-ready summary posted below. Left human-gated — the gate is legitimate.

[kyle-sexton]

This was generated by AI during triage (gate-audit pass, instance KYLE-DESKTOP-triage-20260729).

Gate-audit result: gate is legitimate — stays human-gated. 3-of-3 panel consensus

Challenged the needs-human gate with a three-vote panel: two independent fresh-context reviewers given
only the issue artifact, prior rationale withheld, plus this lane's own read. All three returned
STAYS-GATED at high confidence.

Why — both legs converged on the same factor, independently

This decision assigns who exercises approval authority in an unattended merge path. That is
merge-authority and trust-topology design — a security surface by construction, not an implementation
detail. The three options differ in trust shape, not effort:

• (a) orchestrator triggers the approver-bot review inside the direct-gate flow — needs an idempotent
  trigger and a live-head pin, and puts approval-triggering authority in the orchestrator.
• (b) a per-cycle approver sweep over zero-blocker PRs — a separate actor on its own cadence.
• (c) accept worker-path-only autonomy for v1, documented — no new authority at all.

Both panel legs independently verified the gap against repo state: the merge gate verifies a
live-head approval but never creates one, and zero-blocker non-draft PRs receive no worker and go
straight to the merge gate. So the direct-gate route genuinely cannot satisfy an enabled tier's approval
criterion without some other actor. The report's characterization is accurate.

Crucially, the defect fails CLOSED — it over-defers, never wrongly merges. There is therefore no
safety pressure forcing a fast answer, which is exactly what makes (c) a live candidate rather than a
placeholder, and makes this a genuine product/priority choice rather than a bug with one correct patch.

---

Decision-ready summary

The question: who runs the second-account review pass on a zero-blocker PR?

✅ RECOMMENDED — Option C now, Option A at the flip: document worker-path-only autonomy as the v1 answer, with (a) as the ratified successor bound to the existing trigger

Write (c) down as a deliberate v1 boundary rather than an accident, and record (a) as the chosen design
for when the gate-off flip lands.

Why: the item already carries a well-defined trigger — this is harmless while the tier is disabled or
while worker-path volume dominates, and becomes the main autonomy gap only once the flip lands and clean
PRs are the common case. Since the failure direction is fail-closed, deferring costs throughput, never
safety. Choosing (a) now would stand up new approval-triggering authority to solve a problem that is not
yet live — the expensive half of the decision, taken early, in the area where mistakes are least
reversible.

What to write down now, so this is a decision and not a silence: that the direct-gate route is
intentionally inert under an enabled tier in v1, that clean PRs deferring to the human merge-ready list
is expected behavior rather than a defect, and that the trigger for revisiting is the gate-off flip.

Option A (adopt now): orchestrator triggers the approver-bot review in the direct-gate flow

Trade-off: the complete fix and the eventual destination. Requires an idempotent trigger plus a
live-head pin, or it re-opens the same TOCTOU shape the merge gate exists to close. Choose this now
instead of later if the gate-off flip is imminent — the sequencing above is the only reason to wait.

Option B: lightweight per-cycle approver sweep over zero-blocker PRs

Trade-off: decouples approval from the merge cycle and is simpler to reason about per-PR, but adds a
second actor on its own cadence and a second place where approval authority lives. Weakest fit unless
there is an independent reason to want a standalone sweep.

---

Labels unchanged: needs-human, status: needs-decision, priority: high. Adding
work-class: structural to record the panel's classification.

Whichever option is chosen, the wiring afterwards is briefed C3 work and can go to agent-ready
without re-triage. Note that option C's deliverable is documentation only.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned for this drain wave (frontier consensus).

Dual-panel drain ruling: advisory, superseded, folded into a program umbrella, or blocked on a host/design carrier without an actionable in-repo slice this session. Re-open with a concrete acceptance brief if a consumer needs the work.

KEEP set for this wave: standing telemetry; host-physical Class C (#631 family); program umbrellas #530/#531/#532/#535; live design carriers #1500/#1553/#1668/#1695/#1716/#1681/#1718; #1360.