bug(source-control/babysit-prs): readiness gate resolves repo from CWD, silently scores wrong PR cross-repo

[kyle-sexton]

Lane: babysit (cycle 36, amendment-round 16).

Triggering example: worker-59, babysitting kyle-sexton/autonomy-demo-scratch#59 (a personal repo, different owner than the main session's own checkout). Root-caused after this PR failed to reach READINESS_OK across 16 prior rounds despite being genuinely clean (state OPEN, mergeStateStatus:CLEAN/mergeable:MERGEABLE, CI green, 0 bot/human findings, 0 review threads, not behind base).

Observed: babysit-readiness-gate.sh's default --pr-only invocation path (loop.md §5.1.3-E) resolves owner/repo via gh repo view on the current working directory, not the actual target repo, and ignores FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO. When the invoking session's CWD is a checkout of a different repository than the PR being gated (here: CWD was a melodic-software/claude-code-plugins checkout, target PR was kyle-sexton/autonomy-demo-scratch#59), the gate silently scores whatever PR number matches in the CWD's own repo instead — claude-code-plugins#59 has real claude[bot] findings, so the gate returned READINESS_BLOCKED (findings=1) against the wrong PR entirely, while the actual target PR (autonomy-demo-scratch#59) has zero findings.

Expected: the gate must resolve the target repo from an explicit --repo argument (or FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO, consistent with the rest of the toolchain), never infer it from CWD when that CWD doesn't match the PR being gated.

Category: bug (behavioral — silent wrong-data scoring, not a crash; also a functional defect blocking this lane's own convergence on any PR in a repo other than the invoking session's CWD checkout).

Blast radius: this lane routinely dispatches workers across many repos (ci-workflows, claude-code-plugins, medley, standards, github-iac, dotfiles, ci-runner, and now a personal-owner repo) from a single orchestrator whose own CWD is one specific checkout. Any worker whose own worktree CWD doesn't end up as a true checkout of its own target repo (or that inherited a stale/wrong CWD) would hit this same silent misscoring — worth an audit of how many prior READINESS_BLOCKED verdicts this session may have been reporting against the wrong repo's PR-number collision, not the actual target.

Not a self-observation paper-cut: clears the "priority:high functional defect blocking this lane's own next cycle" carve-out in the intake throttle (rule 8b) — filed standalone rather than appended to the rolling sweep issue (#657).

Related, not duplicate: #475 (closed) covered a different failure mode of the same script — a hard exit 4 when FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO are unset. This is a silent wrong-repo scoring bug on the CWD-inference path itself, which #475's fix did not address.

[kyle-sexton]

This was generated by AI during triage.

Verified in the actual code

Reproduction confirmed by reading the scripts. Citing by symbol per this repo's brief-durability convention, not line numbers.

The gate has no --repo flag and never reads the env vars itself. babysit-readiness-gate.sh's argument parser accepts only a positional <pr>, --comments-json, --checklist, --self, --extra-self (unknown flags exit 3). It never references FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO. It calls fetch-all-pr-comments.sh "$PR_NUMBER" with the PR number only, and relies entirely on those two children to resolve owner/repo.

There are two resolution paths, and they disagree — this is the core defect.

1. Bash degrade path — fetch-all-pr-comments.sh does honor FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO (its --- Repo resolution --- block), falling back to gh repo view on CWD only when they are unset. So on the bash-only path, exporting the env vars steers it correctly. This is the source-control:babysit-prs: babysit-readiness-gate.sh exits 4 without FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO env vars, undocumented in worker contract #475 remedy documented in loop.md §5.1.3-E and SKILL.md.

2. Python path (the live default whenever Python 3.11+ is present) — the gate then re-counts via babysit_findings.py --pr "$PR_NUMBER" --self ... and overwrites the bash findings/classified from BASH_REMATCH. But babysit_findings.py's resolve_repo() consults only its own --repo flag (which the gate does not pass) and then gh repo view on CWD. It never reads FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO at all.

Consequence (worse than the issue summary states): when Python is present, exporting the env vars produces correct bash counts that the Python re-count then clobbers with CWD-resolved wrong-repo counts. The documented #475 fix — "export the env vars" — is itself silently defeated on the default path. So the reporter's "ignores the env vars" is precise for the Python path and mint-a-wrong-verdict there even when the operator did everything the docs say.

Note: babysit_findings.py already exposes a --repo owner/repo flag — it is simply never passed by the gate. The plumbing to fix the Python leg already exists.

Recommended fix

Resolve the target repo once, in the gate, up front, then pass the same identity to both children so they can never diverge:

• Add --repo owner/name to babysit-readiness-gate.sh.
• Precedence: --repo > FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO > CWD gh repo view.
• Thread the resolved identity into both legs: export FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO for fetch-all-pr-comments.sh, and pass --repo "$OWNER/$REPO" to babysit_findings.py. This closes the Python bypass regardless of how resolution happened. No Python change needed — the flag already exists.
• Echo the resolved repo=owner/name into the READINESS_OK/READINESS_BLOCKED stdout line so a score is never unlabeled as to which repo it came from.

This is not gate-only. The plan must also touch:

• loop.md §5.1.3-E + SKILL.md per-PR checklist — the caller contract must pass the target explicitly on every dispatch (--repo). Correct the current guidance, which tells workers to export the env vars: that is insufficient because the Python override re-breaks it.
• babysit-readiness-gate.test.sh — asserts --help documents the env-var override; the interface change ripples here (and should add a wrong-CWD regression fixture).

Rationale, weighted to the stated safety property (loud failure over silent wrong-repo score): the current design lets CWD inference always "succeed" at resolving some repo, so a wrong repo never looks ambiguous — that is exactly how a same-numbered PR gets silently scored. Threading one resolved identity into both legs + echoing it removes the silent-divergence class entirely.

Open question → needs-human

One genuine values-call remains, and it is one of the exact triggers this triage lane routes to a human: when no explicit repo is passed (no --repo, no env vars), what should the gate do?

• (a) Hard-fail demanding --repo. Maximally safe — never scores without an explicit target — but breaks every existing bare babysit-readiness-gate.sh <N> caller and the single-repo "run from the target checkout" interactive ergonomic.
• (b) CWD fallback, but echo repo= and require the orchestrator to assert resolved == dispatched-target. Preserves ergonomics and makes wrong-repo visible, but a labeled READINESS_BLOCKED is still a score, not a failure — anything downstream acting on exit code alone stays unprotected unless the orchestrator does the equality check.

RECOMMENDED: (b) plus an orchestrator-side resolved==target assertion — it keeps the interactive path working while making a wrong-repo score impossible to pass silently, provided the orchestrator validation is actually added. The coupled sub-decision (whether to add that automatic CWD-matches-declared-target validation, and where it lives — gate vs orchestrator) is the second named human trigger. Because the safe-vs-ergonomic tradeoff and the validation-placement are real design calls, not mechanical, this wants a maintainer decision before implementation, not a defaulted merge.

Prior-verdicts audit: not retroactively actionable

Stated flatly: there is no systematic way to audit which prior READINESS_BLOCKED verdicts scored the wrong repo. The gate's stdout has never emitted the resolved repo (only findings/classified/checklist), and there is no evidence of persisted per-invocation verdict+CWD telemetry. Even GitHub-persisted readiness reports would not record which repo was scored. Reconstruction is per-case manual forensics — exactly what the reporter did for worker-59 — not a queryable audit, and not worth a blanket audit plan. The forward remedy is the echo repo= change above: once the resolved repo is in the output line, future verdicts become auditable.

Relationship to #475

#475 (closed) fixed a hard exit 4 — the gate crashed when FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO were unset and CWD could not resolve any repo. That is a fail-loud case. This issue is the opposite failure mode on the same script: CWD inference succeeds at resolving a wrong repo and silently scores it. #475's fix (document the env-var export) not only did not address this path — as shown above, on the Python default path that documented workaround is itself silently defeated.