source-control:babysit-prs: babysit-readiness-gate.sh exits 4 without FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO env vars, undocumented in worker contract

[kyle-sexton]

Lane

babysit (safe tier, /loop 15m /source-control:babysit-prs)

Triggering example

#452, quiet-recheck pass: worker ran babysit-readiness-gate.sh 452 (no other args, per the SKILL.md-documented invocation) and got exit 4, not READINESS_OK/READINESS_BLOCKED. Re-running with FETCH_COMMENTS_OWNER and FETCH_COMMENTS_REPO exported into the environment first returned the expected READINESS_OK findings=1 classified=5, exit 0.

Observed vs expected

Observed: the gate script internally shells out to fetch-all-pr-comments.sh, which apparently requires FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO as environment variables rather than deriving them from the PR argument, the current repo context, or a --repo-style flag. Neither SKILL.md's documented invocation (babysit-readiness-gate.sh <N>, no env-var prerequisite mentioned) nor the worker contract in reference/orchestration.md mentions this requirement, so a fresh worker following the documented interface hits an undifferentiated exit 4 with no indication of what's missing, and has to discover the fix by trial and error.
Expected: either (a) the gate script derives owner/repo itself the same way pr_queue_snapshot.py and the other bare-wrapper scripts do (from the PR argument or gh repo view), removing the env-var dependency entirely, or (b) if the env vars are genuinely required, SKILL.md's per-PR checklist and the worker contract document them as prerequisites so a worker doesn't have to rediscover the requirement per PR.

Category

bug

Note

This is a different issue from #465 (finding-count over-counting) — that's about the gate's counting logic being wrong when it does run successfully; this is about the gate failing to run at all absent an undocumented environment setup step.

[kyle-sexton]

This was generated by AI during triage. · Category: bug · Priority: priority: high (week directive — pipeline correctness). Routed status: ready.

Problem / root cause. The issue's stated premise is inaccurate and is corrected here: fetch-all-pr-comments does not require FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO. Those are overrides; its default already derives owner/repo from gh repo view, which reads the current working directory. The real defect is that repo resolution has only two sources — ambient cwd and those env vars — and no argument-based path. Run from a cwd that is not the target repo (a worker on a neutral/home directory, or a fleet worker whose cwd is a different repo), gh repo view yields empty owner/repo, fetch exits non-zero, and babysit-readiness-gate collapses every fetch failure into a single undifferentiated exit 4. Because the gate forwards only the bare <N>, it cannot supply repo context even when the caller knows it. The bare <N> invocation carries no repo information, so nothing in the current interface makes the documented call succeed outside the checked-out worktree.

Recommended fix (behavioral contract). Mirror the pattern pr_queue_snapshot already uses — it derives repo from its PR argument, not from cwd or env:

• fetch-all-pr-comments gains a --repo owner/repo option. Repo-resolution precedence becomes: --repo → FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO env override → gh repo view cwd fallback. Behavior with none of these supplied is unchanged from today.
• babysit-readiness-gate accepts --repo owner/repo and forwards it verbatim to fetch-all-pr-comments. Its bare-<N> contract is untouched (additive flag).
• When owner/repo cannot be resolved from any source, both scripts fail with a distinct, actionable diagnostic that names the remedy (pass --repo owner/repo, or run from inside the target repo), instead of the gate's current catch-all exit 4. Exit 4 today conflates "jq missing" with "fetch failed for any reason"; the fetch-resolution failure gets its own message and a non-overloaded code.

Acceptance criteria.

• From a cwd that is not the target repo, with no env vars exported: babysit-readiness-gate <N> --repo owner/repo returns READINESS_OK or READINESS_BLOCKED and exits 0/1 — never the opaque exit 4.
• From inside the target repo's checkout, the existing bare babysit-readiness-gate <N> (no --repo, no env) continues to return READINESS_OK/READINESS_BLOCKED via the gh repo view fallback.
• When repo context is unresolvable from every source, the failure message names --repo as the fix rather than exiting an undifferentiated 4.

Backward compatibility. No shipped loop step, orchestration caller, or sibling script currently exports FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO; they are honored only inside fetch-all-pr-comments itself. The env override is retained at its existing precedence, so any operator or external caller that exports them keeps working unchanged. --repo is purely additive — every current bare-<N> invocation behaves exactly as before.

One-line test. From a non-repo directory with the env vars unset, babysit-readiness-gate <N> --repo <owner>/<repo> emits a READINESS_OK/READINESS_BLOCKED line and exits 0/1 (asserting it never exits 4), while the same command without --repo still succeeds when run from within the repo checkout.

Decision defaulted: (a) derive owner/repo from explicit input rather than documenting the env-var requirement — add a --repo owner/repo option to fetch-all-pr-comments, have babysit-readiness-gate accept and forward it, keep the gh repo view cwd fallback and the FETCH_COMMENTS_OWNER/FETCH_COMMENTS_REPO env override, and replace the opaque exit 4 with a diagnostic naming the fix. — veto before merge

Distinct from #465 (finding-count over-counting when the gate does run) — this is the gate failing to run at all outside the target worktree.