fix(source-control): require per-thread pins for autonomous bulk babysit thread resolves

[kyle-sexton]

Problem

babysit_resolve_thread.py's bulk resolve path (--resolve with no --thread-id) does not
require the per-thread TOCTOU pins that the single-thread path does, so an unattended
worker (--autonomous) can resolve review threads it never vetted.

The pin guard (--expected-comment-count + --expected-last-updated) only fires when
--thread-id is supplied (babysit_resolve_thread.py:319). The documented worker/autopilot flow
resolves in bulk — source-control-babysit-resolve-thread owner/repo#N --allowed-owners <watched-owners> --resolve --include-human (SKILL.md §Autopilot step 2), no --thread-id. In
autonomous mode the tool resolves every isOutdated bot thread; because a worker's own push is
what marks a thread isOutdated, a finding can flip to outdated between the vet snapshot and the
resolve, and the bulk call clears it with no proof it was addressed.

The address-then-resolve discipline is enforced by prose ("address the finding first, then
resolve"), not by the tool: the bulk path trusts the orchestrator instead of pinning each thread.
Reported by Codex on #322 (P2, inline on babysit_resolve_thread.py).

The decision to make

Two shapes, both defensible — needs a call:

• Reject bulk autonomous resolves: in --autonomous mode, require a pinned --thread-id per
  thread (with --expected-comment-count + --expected-last-updated), forcing the orchestrator
  to resolve one vetted thread at a time. Safest; changes the worker flow from one bulk call to a
  per-thread loop.
• Pin the bulk set: allow bulk autonomous resolve but require a snapshot pin (e.g. the head
  SHA the vet was taken against) so a thread that changed since the vet is skipped, not cleared.

Acceptance

• Autonomous bulk resolve can no longer clear a thread that changed since it was vetted.
• The worker/autopilot flow in SKILL.md and reference/* is updated to the chosen shape.
• Regression test in test_guards.py (autonomous bulk resolve without pins is refused / skips
  changed threads).

Related

• feat(source-control): converge babysit-prs tiers + engine (0.8.0) #322 — PR-B (capability convergence); Codex flagged this inline.
• fix(source-control): reconcile review-trigger 'pending or failing' gate contract with pending-only code #324 — sibling review-trigger contract reconciliation from the same review pass.

[kyle-sexton]

Decision needed before implementation (autonomous work lane)

This issue carries an explicit "## The decision to make" fork that changes the autonomous worker contract (the documented bulk-resolve flow) — hard to reverse once workers depend on it — so the work lane is parking it for a human call rather than guessing.

RECOMMENDED — Option 1: Reject bulk autonomous resolves (require per-thread pins)

In --autonomous mode, require a pinned --thread-id per thread (--expected-comment-count + --expected-last-updated), turning the bulk call into a per-thread vetted loop.

Why this one:

• Reuses the existing, tested pin guard (babysit_resolve_thread.py:319) instead of inventing a second pinning model — one enforcement mechanism, less surface to drift.
• Fails closed by construction (no pin → refuse), matching the repo's deny-by-default posture (CLAUDE.md plugin-acceptance review).
• Per-thread loop cost is small and bounded by threads-per-PR; the safety guarantee is the strongest of the two.

Cost: the worker/autopilot flow in SKILL.md §Autopilot step 2 changes from one bulk call to a per-thread loop.

Option 2: Pin the bulk set

Allow bulk autonomous resolve but require a snapshot pin (e.g. the head SHA the vet was taken against); the bulk path skips any thread that changed since the vet instead of clearing it.

• Pro: preserves the single bulk-call throughput; less churn to SKILL.md/reference/*.
• Con: introduces a new pin semantic alongside the existing per-thread pins (two models to maintain), and the "skip changed" detection in the bulk path is new logic to get right.

Option 3 (hybrid): bulk pin as the default, per-thread pins available

Ship Option 2's bulk snapshot pin as the ergonomic default and keep per-thread pins for callers that want the stricter guarantee. More code than either single option; only worth it if both flows have real demand.

Either Option 1 or 2 satisfies the acceptance criterion (a changed-since-vet thread can no longer be cleared). The tradeoff is fail-closed uniformity (1) vs throughput preservation (2).

Category: behavioral. Lane: work (auto-select). Trigger: #326 picked from the ready queue; contract-shaped fork per the issue's own "decision to make" section.

[kyle-sexton]

Maintainer decision (2026-07-19): Option 1 — reject bulk autonomous resolves; require per-thread pins (--thread-id + --expected-comment-count + --expected-last-updated per thread, reusing the existing pin guard at babysit_resolve_thread.py). Fail-closed by construction, one enforcement mechanism, no second pin semantic. Autopilot step 2 changes from one bulk call to a per-thread vetted loop — accepted cost. Ready for implementation.

[kyle-sexton]

Adoption-ladder alignment check (maintainer-requested): Option 1 is confirmed consistent with the WP5 guardrail contract (docs/topics/ai-ladder-wp5-guardrails/PLAN.md): the fail-closed-everywhere constraint ("block and name the compliant path, never degrade silently"), D3's discipline (capability expansion human-ratified, restriction automatic), and the standing Boris-alignment acceptance criterion (trust before scale, no step-skipping). Option 2's skip-changed bulk path is a graceful-degrade shape with a second pin semantic — weaker fit on both counts. Decision stands.