source-control:babysit-prs: docs don't clearly distinguish babysit-readiness-gate.sh (classification count) from babysit_merge.py (actual merge readiness) — caused a false MERGE-READY report

[kyle-sexton]

Lane: babysit. Self-caught orchestration error, session 2026-07-20.

The orchestrator (me) reported #567 as MERGE-READY at the end of cycle 1, based on: (a) a dispatched worker's live thread cross-check, and (b) babysit-readiness-gate.sh reporting a (known-#465-inflated) finding count. Neither of those checks the actual GitHub merge gate. On cycle 2, running the real merge-readiness script (skills/babysit-prs/scripts/babysit_merge.py, read-only, no --merge) revealed #567 was never mergeable: the repo's "base" ruleset sets required_review_thread_resolution: true, and #567 had 2 deliberately-open review threads (intentional author-policy deferrals, tracked as #594/#595) — GitHub mechanically blocks merge on ANY unresolved thread regardless of severity or whether a human has already "handled" it via reply.

Root cause: the skill has two separately-named scripts that both produce a "readiness" verdict for a PR, and nothing in SKILL.md or the per-PR checklist explicitly says which one is authoritative for a MERGE-READY human-facing report:

• babysit-readiness-gate.sh — counts/classifies findings (over-counts per source-control:babysit-prs: babysit-readiness-gate.sh over-counts lifetime P-badges as 'findings', false READINESS_BLOCKED reason=under-decomposed on fully-classified PRs #465), says nothing about thread-resolution or branch-ruleset state.
• babysit_merge.py (aka source-control-babysit-merge) — the actual GitHub mergeability check (branch rules, thread resolution, required checks, head match).

Every worker this session was briefed to run babysit-readiness-gate.sh for its readiness=OK/BLOCKED field; none were told to run babysit_merge.py. That's partly an orchestrator briefing gap, but the skill's own docs use "readiness gate" for both without disambiguating, which invites exactly this mistake.

Expected: SKILL.md (or reference/orchestration.md / reference/cadence.md) should explicitly state that any MERGE-READY determination — human-facing or autonomous — must come from babysit_merge.py's ready field, never from babysit-readiness-gate.sh alone.

Category: bug (process/doc gap) — no code defect, no incorrect merge occurred (gate was ON, nothing was actually merged off the bad report), but it produced an inaccurate human-facing deliverable.

Work-class: C2 (mechanical) — attended triage 2026-07-23, operator-ratified. 🤖

[kyle-sexton]

This was generated by AI during triage.

T1 — routing status: ready. Which script is authoritative for MERGE-READY is already established fact (babysit_merge.py's ready field — the real GitHub mergeability check); this just needs stating explicitly in SKILL.md/reference docs so it isn't rediscovered per session. No design decision. Related to #534 (the babysit-readiness-gate.sh over-count this issue's report leaned on) but the defect here is doc disambiguation, not classifier accuracy — not folded, related-link only.

[kyle-sexton]

This was generated by AI on operator direction.

Superseded — this item was already ratified and should not have been queued.

The earlier first-drain ratification request on this issue was raised in error. The admission gate dispatches a C3 bug-fix-shaped item when it carries either its own recorded ratification or a completed first drain — and this issue already carried recorded ratification in its body from attended triage on 2026-07-23. The drain cycle applied the blanket first-drain rule without first reading bodies for an existing ratification, so it queued an item that was already admitted.

Restored to the autonomous frontier: agent-ready re-applied, needs-human removed. No human action is required, and this issue no longer appears in the attended queue's ratify view.