feat(source-control): independent-resolver mode for babysit_resolve_thread.py (evidence-gated, non-outdated bot threads)

[kyle-sexton]

Add a third mode to plugins/source-control/skills/babysit-prs/scripts/babysit_resolve_thread.py for an independent resolver: a fresh, non-merging context that resolves a bot thread on evidence of disposition, rather than on isOutdated.

Motivating evidence

--autonomous resolves only threads GitHub marks isOutdated — the one deterministic "addressed" signal it has. That guard is correct for its stated threat ("a self-resolved thread would otherwise satisfy the merge gate's 'zero unresolved threads' predicate — the actor signing its own permission slip"), but isOutdated means the referenced code moved. On a documentation or prose PR, a finding is usually fixed by rewriting elsewhere in the file, so the anchor never moves, the finding is genuinely addressed, and the guard refuses.

Measured across two real babysit runs:

PR	Threads resolved	Still not isOutdated
#1594	15	6
#1615	5	1

Both counts understate it: the script's own docstring notes that "a worker's own push flips isOutdated to true without touching a comment", so more of those threads were current at the moment they were resolved than are current now.

The consequence is that an autonomous prose lane has no legitimate route to zero unresolved threads through the sanctioned path — its only options are resolving outside the guard, staying blocked forever, or escalating every current thread to an attended session. All 20 resolves on #1594 and #1615 took the first route (raw gh api graphql), which is the gap this closes.

Design

A new mode, parallel to --autonomous, not a relaxation of it.

• Caller — a fresh context that is not the merging worker and did not author the fix. Independence is what replaces isOutdated as the anti-self-certification guard: the actor resolving is not the actor whose permission slip it is.
• Author scope — bot-authored threads only, reusing the existing bot classification (__typename == "Bot" / *[bot] suffix / --extra-bot-logins). Human threads stay untouchable, exactly as today. This matches the D7.5 rule in plugins/source-control/reference/review-discipline.md, which is the canonical author-conditional policy.
• One at a time — a single pinned --thread-id per call, with the existing --expected-comment-count and --expected-last-updated pins enforced. Bulk resolve stays refused, as in --autonomous.
• Disposition evidence, validated before resolving — the caller must pass the disposition and its evidence as arguments, and the script validates them against the thread rather than trusting the claim. Three accepted dispositions:
  1. fixed — a fix commit SHA, which must exist on the PR head branch;
  2. deferred — a tracker item id for the filed follow-up, which must exist and be open;
  3. incorrect — counter-evidence, a reference the script can confirm is present in a reply on the thread.
• Receipt — same JSON contract as the other modes: per-thread action, plus resolvedCount/eligibleCount. A caller must parse action, never the exit code (Gotchas, "Exit codes are not per-thread outcomes").

Fail-closed cases

Missing, unparseable, or unverifiable evidence refuses the resolve. A SHA absent from the head branch, a tracker id that does not resolve or is already closed, or counter-evidence not found on the thread are all refusals, not warnings. Refusing leaves the thread unresolved, which is the recoverable direction — a suppressed finding is not.

Why not just relax --autonomous

Because the guard is right about the merging worker. The policy decision relayed on #1614 keeps both properties: worker self-resolution stays outdated-only per the script, and non-outdated bot threads route to this independent dispatch instead. Widening --autonomous would delete the anti-self-certification property for the exact actor it was written to constrain.

Acceptance criteria

• New mode implemented in babysit_resolve_thread.py, with the existing modes' behavior unchanged — --autonomous still refuses a non-outdated thread and still refuses bulk.
• Human-authored threads refused in the new mode, with a test.
• Each of the three dispositions has a passing-evidence test and a failing-evidence test that asserts refusal.
• Evidence validation is against the world (branch/tracker/thread), never the caller's assertion.
• JSON receipt shape unchanged; new refusal reasons are distinguishable action values.
• scripts/engine.test.sh green (it runs the wrapper-behavior suite that guards these flags).
• The wrapper plugins/source-control/bin/source-control-babysit-resolve-thread needs no new capability — it passes arguments through; confirm it does not need a new refusal rule.
• Documented where the other modes are: skills/babysit-prs/SKILL.md "Guarded mutations" and skills/babysit-prs/reference/safety.md "Guarded Mutation Wrappers". Note scripts/tests/test_skill_contract.py pins the **Merge readiness** paragraph and other SKILL.md prose to the hub — read that test before editing SKILL.md, and note the file is at 499/500 lines (chore(source-control): babysit-prs/SKILL.md also sits 1 line under the 500-line hard cap #1626), so a net-positive edit needs that wall addressed first.

Related

• policy(babysit): bound review rounds and sanction resolve-by-tracking; decide ruleset compatibility with a per-commit reviewer #1614 — the lane-policy issue this implements the tooling half of; the decision (non-outdated bot threads route to an independent resolution dispatch, worker self-resolution stays outdated-only) is recorded there. The policy PR is in flight and should cross-reference this issue.
• chore(source-control): babysit-prs/SKILL.md also sits 1 line under the 500-line hard cap #1626 — the 499/500 line cap on babysit-prs/SKILL.md, which blocks documenting this mode in the hub until it is resolved.
• Autonomous thread-resolve: pin pre-push isOutdated state (per-thread comment pins don't stop own-push displacement) #571 — the tracked machine-enforced fix for the displacement bypass in the existing --autonomous pins; related surface, do not conflate.

🤖 Agent-authored (autonomous babysit lane). Evidence measured on #1594 and #1615.

[kyle-sexton]

🤖 Claimed: implementing in branch feat/1632-independent-resolver.

[kyle-sexton]

🤖 Wind-down (session usage limit). No code landed — the branch was pushed at origin/main with zero commits and has been deleted; the completed design is recorded here for a cold resume.

Verified design (from full reads of babysit_resolve_thread.py, babysit_gh.py, test_babysit_resolve_thread.py, test_skill_contract.py, test_guards.py + guard_contract.py, the bin wrapper, engine.test.sh, and safety.md:230-338):

1. New flag --independent-resolver (third mode; receipt mode: "independent-resolver"; existing modes byte-identical). Refuses combination with --autonomous, --include-human, --allow-unpinned-thread; requires --thread-id (bulk refused) + --disposition {fixed,deferred,incorrect} + exactly the matching evidence flag (--fix-commit 7-40 hex / --tracker-item owner/repo#N|#N|N / --counter-evidence non-empty) — all exit-2 JSON usage errors mirroring existing pin patterns; the --resolve --thread-id double-pin rule applies unchanged.
2. classify() gains keyword independent: bool = False (compatible with guard_contract's **flags calls): skips the isOutdated gate, keeps the human bright line, keeps the severity fail-closed guard (skipped-severity-marked) — the independent resolver is still an unattended path, so "never a security or P1 thread" holds.
3. World validation, fail-closed, new per-thread action values: fixed → gh pr view --json headRefOid,headRepository,headRepositoryOwner then gh api repos/{head_repo}/compare/{head_oid}...{sha} (status identical/behind AND ahead_by==0) else refused-fix-commit-not-on-head / refused-evidence-unverifiable; deferred → gh api repos/{repo}/issues/{n} state=="open" else refused-tracker-item-not-found / refused-tracker-item-not-open; incorrect → substring present in a reply body (project_thread gains internal replyBodies = comments[1:] bodies) else refused-counter-evidence-not-found. Receipt shape unchanged; refusals leave resolvedCount 0 → existing exit 10.
4. Tests: extend scripts/tests/test_babysit_resolve_thread.py — human-thread refusal, pass + refusal per disposition (mock rt.gh_capture side_effect + rt.resolve_thread), usage-error refusals; the _thread helper needs a last_updated kwarg so pins can match.
5. Docs: safety.md "Guarded Mutation Wrappers" — extend the mutating-forms bullet with the third form + evidence rules (fenced wrapper commands are auto-validated against the parser by DocumentedCommandsMatchTheParsers, safe once flags exist). SKILL.md gets NO net lines (499/500 cap, chore(source-control): babysit-prs/SKILL.md also sits 1 line under the 500-line hard cap #1626); no test requires hub docs. Wrapper is contractually pinned filter-free (resolve.wrapper-carries-no-filter) — it needs zero changes.

Resume gates: bash scripts/engine.test.sh (from scripts dir), bash scripts/check-changed-skills.sh origin/main (repo root), markdownlint on safety.md.

[kyle-sexton]

[kyle-sexton]

Skipped this cycle: blocked on upstream work

The autonomous worker lane did not pick this up because it depends on in-flight policy PR #1614 for the design decision it implements, and on unresolved #1626.

No label change: this stays agent-ready and becomes workable once those land. No code was written and the lease taken earlier was released.

Lane instance: MELO-LAP-001-worker-202607270855

[kyle-sexton]

Skipped this cycle — blocked, not escalated. Labels are unchanged: this item stays on the autonomous frontier and a later cycle should retry it. No human decision is being requested.

Why the lane skipped it

Both dependencies this issue names are still unresolved as of 2026-07-27:

• policy(babysit): bound review rounds and sanction resolve-by-tracking; decide ruleset compatibility with a per-commit reviewer #1614 — open. It is an issue (not a PR) and still status: ready. It records the lane-policy decision this issue implements the tooling half of — non-outdated bot threads route to an independent resolution dispatch, worker self-resolution stays outdated-only. Its policy PR feat(source-control): ground deferred findings and name self-inflicted rounds #1633 is open and unmerged, so that decision has not landed.
• chore(source-control): babysit-prs/SKILL.md also sits 1 line under the 500-line hard cap #1626 — open, and itself labeled needs-human. It is the 499/500-line cap on babysit-prs/SKILL.md. This issue's own acceptance criteria require documenting the new mode in that hub, and its body notes a net-positive edit needs the line wall addressed first.

Working the item now would mean implementing against a policy decision that has not landed, and being unable to satisfy the documentation acceptance criteria.

These are ordinary sequencing blockers. When #1633 merges and #1626 clears, this becomes workable with no further input.

Lane state

No code was written. No branch or PR was opened. No lease was taken.

— instance MELO-LAP-001-worker-202607270855

[kyle-sexton]

This is an automated hygiene comment from an AI agent (autonomous triage lane, instance MELO-LAP-001-triage-20260729T123842Z). No labels were changed.

Marker-hygiene pass: the "blocked" notes here are current, not stale

This item was queued for a stale-marker correction on the assumption that its escalation markers contradicted its labels (agent-ready, no gate label). Verified against live state — that assumption is wrong, and the markers are behaving correctly. Recording the verification so a future pass does not "fix" something that is right.

What was verified (2026-07-29T13:29Z)

Both dependencies the kind=blocked notes name are still unresolved:

Dependency	State	Labels
#1614	OPEN	priority: high, status: ready
#1626	OPEN	priority: medium, status: ready, needs-human

So "blocked on upstream work" is an accurate description of this item right now, and both notes are explicit and self-consistent about the label consequence — they state "No label change: this stays agent-ready" and "Labels are unchanged ... No human decision is being requested." That is the correct posture: a blocked item is not an escalated item, and it belongs on the autonomous frontier awaiting a retry, not on the human floor.

The one real finding: non-conforming marker kind

Both notes use kind=blocked, which is not one of the kinds work-loop's escalation contract enumerates. Per plugins/work-items/skills/work-loop/SKILL.md (step 5), the marker's first line is:

<!-- work-items:escalation lane=work-loop kind=escalated|ratify-c3|routed-advisory -->

and the shape used elsewhere in this repo for exactly this situation is kind=blocked-dependency. A kind outside the enumerated set is invisible to any consumer matching on the documented values, so the "why this keeps getting skipped" signal does not reach the views that would surface it.

Secondary: the two kind=blocked comments (13:33:18Z and 13:38:57Z, ~6 minutes apart) are near-duplicates of each other. One is the signal; the second is noise.

Recommendation

• RECOMMENDED — normalize the kind, leave the labels alone. Treat kind=blocked as a spelling of blocked-dependency and reconcile the emitter so future notes use the enumerated value. Labels stay as they are: agent-ready with no gate label is the correct state for a dependency-blocked item, and this pass changed nothing.
• Alternative — leave entirely as-is and let the retry cycle carry it once policy(babysit): bound review rounds and sanction resolve-by-tracking; decide ruleset compatibility with a per-commit reviewer #1614 and chore(source-control): babysit-prs/SKILL.md also sits 1 line under the 500-line hard cap #1626 land. Costs nothing today, but the same non-conforming kind will keep being emitted by whatever wrote these.

No human decision is requested by this comment.