source-control(babysit-prs): absorb v4 loop-prompt operating rules into the skill

[kyle-sexton]

Category: behavioral/operational · Source: 2026-07-19 deep-dive audit (external + lane self-audit). Session-scoped loop-prompt rules that are really skill gaps — each should live in the skill so bare invocations get them without a hand-authored prompt.

Absorb into the skill

• Review-response ownership: pipeline/lane-authored open PRs — fetch threads, fix branch-owned findings, classification-table reply, then RESOLVE each addressed thread (or explicit defer + follow-up issue #). Audit found 12/12 findings addressed but 0/~10 threads resolved.
• Never re-trigger a review for an unchanged head SHA (audit: fix(repo-hygiene): gate git-tree-reset clean on reset success #460 double-review on one head).
• Fix-round cap per head (3) then decide-and-defer + tracked follow-up (composes with babysit-prs: codify the decide-and-defer non-convergence resolution playbook (own-once, no duplication of safety.md) #375; audit: fix(toolchain): resolve default branch by detection, not assumption #467 ran 4 rounds/22 review jobs).
• Merge-gate mode as a first-class skill mode with hard STOP + explicit MERGE-READY: [list] terminal output per cycle (PR feat(source-control): babysit-prs merge-step STOP, bare-wrapper pipe rule, snapshot exit-code taxonomy, cross-PR dependency channel #456 starts this; make gate-mode a documented tier, not a prompt convention).
• Parallel fan-out self-observation timing: "file after any ONE worker returns" (rule-9 ambiguity found in self-audit).
• Loop-pacing guidance keyed to worker concurrency cap (fixed 15m structurally mismatches 30-50 min fan-out cycles; overlaps — source-control:babysit-prs + loop: /loop 15m fires overlap in-flight fan-out cycles when batch-cap-10 dispatch runs long #472).

Related (already filed, referenced not duplicated)

#472 pacing/overlap · #465 #473 #475 gate-script bugs · #450 bot identity · #375 non-convergence · #476 merge tier

Stays prompt-level (contextual, do NOT absorb)

Week priority directive; current gate ON/OFF state; env-var workarounds that die when #475 merges.

[kyle-sexton]

This was generated by AI during triage. · Category: behavioral/operational · Priority: priority: high (week directive — pipeline improving itself). Routed needs-human + wayfind: design.

Plan: absorb v4 loop-prompt operating rules into babysit-prs

Triage of the six rules against the current skill. Two are clean (one already fully enforced, one a mechanical addition); one shared "defer → follow-up issue" mechanism is planned once and reused; two defer to existing issues; two (bullets 1 and 3) are genuinely open design and gate this plan on a maintainer decision.

A cross-cutting mechanism used by bullets 1 and 3 — on any decide-and-defer, file a tracked follow-up issue and post its number in the classification-table reply — is specified once here and referenced by both; do not plan it twice.

Per-bullet disposition

• 1 — Review-response ownership (fetch → fix → classification reply → RESOLVE addressed threads, or defer + follow-up issue #) — needs human. Not a simple gap: the skill contradicts itself. The authoritative tier policy states four times that the safe/default tier never resolves threads (description, purpose, per-action autonomy table, cross-tier invariants), yet the safe-tier loop's own NEVER-do list mandates "never skip resolving a BOT-authored thread" (author-conditional, after fix+reply). The classification-table reply itself is already fully specified; thread resolution via source-control-babysit-resolve-thread exists but is gated to worker (pre-push-outdated bot threads) and autopilot (--include-human). The rule wants addressed bot/AI-review threads on your own pipeline/lane-authored PRs closed by the default invocation. Whichever direction the maintainer picks, one of the two contradicting statements must change — this is a product-intent call about the default tier's safety posture, not a mechanical absorption.

  • Acceptance: SKILL.md and the safe-tier loop agree on exactly which threads the default tier resolves on your own PRs; each addressed thread ends resolved (verified via the wrapper's per-thread JSON action, not exit code) or carries an explicit defer + follow-up issue #; human threads still never auto-resolved outside autopilot.

• 2 — Never re-trigger a review for an unchanged head SHA — already covered. The review-trigger interface (request_review.py) enforces one-shot-per-head: it refuses a post when a durable request/attempt record exists for the current head SHA, and a new observation window opens only on a genuinely new SHA. Dormant (and thus vacuously safe) until the review-trigger config slots are set. No change beyond optionally surfacing the invariant in the cross-tier list for visibility.

  • Acceptance: no behavioral change required; invariant holds whenever the module is active.

• 3 — Fix-round cap per head (3) → decide-and-defer + tracked follow-up issue — needs human. Three cap concepts must be reconciled: (a) the existing "max 3 CI fix iterations per pass", (b) the advisory backstop (~high default, ledger-enforced via manage_feedback_ledger.py record-advisory-round, deliberately not a normal limit), and (c) the proposed 3-per-head cap. The decision that makes this open: does the 3-per-head cap apply to blocking defects — reversing the deliberate, repeated invariant that blocking defects (failing CI, P0/P1, regressions) are never capped — or advisory only? No safe default exists; the two readings encode opposite convergence philosophies. Overlaps babysit-prs: codify the decide-and-defer non-convergence resolution playbook (own-once, no duplication of safety.md) #375 (non-convergence) — reconcile there, do not double-plan. The defer outcome reuses the shared follow-up-issue mechanism above.

  • Acceptance: one documented cap keyed to head SHA with an explicit blocking-vs-advisory scope; on cap, a decide-and-defer that files a follow-up issue and reports the number; no silent contradiction with the "blocking never capped" invariant.

• 4 — Merge-gate mode as a documented tier (hard STOP + MERGE-READY: [list] terminal output) — defer to feat(source-control): babysit autopilot merge tier — bot-account review + criteria-gated merge #476. New tier surface; the MERGE-READY: [list] per-cycle terminal-output convention and hard STOP do not exist today (only the source-control-babysit-merge wrapper and the worker/autopilot tiers). Planned under the merge-tier issue; not re-planned here.

• 5 — Parallel fan-out self-observation timing ("file after any ONE worker returns") — absorb (mechanical). Add an incremental reporting-cadence rule to the orchestration contract: the main agent surfaces each material observation as soon as any single worker returns, rather than withholding the report until the whole batch integrates. Scoped strictly to reporting timing — it must not alter batch dispatch/concurrency ordering (batch → integrate → next batch stays intact).

  • Acceptance: orchestration states that per-worker material outcomes are reported on first return within a cycle; concurrency-cap batching semantics unchanged.

• 6 — Loop-pacing keyed to worker-concurrency cap (fixed 15m mismatches 30–50 min fan-out cycles) — defer to source-control:babysit-prs + loop: /loop 15m fires overlap in-flight fan-out cycles when batch-cap-10 dispatch runs long #472 (pacing/overlap). The overlap/pacing concern is squarely source-control:babysit-prs + loop: /loop 15m fires overlap in-flight fan-out cycles when batch-cap-10 dispatch runs long #472's. At most, when source-control:babysit-prs + loop: /loop 15m fires overlap in-flight fan-out cycles when batch-cap-10 dispatch runs long #472 lands, its guidance's skill-home is the cadence contract (where recommended_cadence is derived) keyed to the concurrency cap; no separate absorption planned here.

Needs human because: bullets 1 and 3 are open design with no safe default. Bullet 1 forces a resolution of an existing SKILL.md-vs-safe-loop contradiction and decides whether the default tier resolves threads (a headline safety-posture change). Bullet 3 requires deciding whether a 3-per-head cap overrides the deliberate "blocking defects are never capped" invariant. Both are product-intent calls a maintainer must make before implementation; bullets 2/5 (already-covered / mechanical) and 4/6 (defer to #476 / #472) can proceed independently once 1 and 3 are decided.

[kyle-sexton]

Elevation (2026-07-19 merge pass): thread resolution is not just hygiene — the branch ruleset has required_review_thread_resolution, so unresolved (even fully-addressed) threads are MERGE-BLOCKING. Six digest-cleared PRs refused to merge until 9 addressed threads were manually resolved. The resolve-after-addressing checklist item in this umbrella is pipeline-critical; until it lands in the skill, the v5 lane rules carry it.