PR #2262 (merged as 9daeecb3) replaced D6's branch-tip read with a genuine reachability check — the right fix for #2244 — but hardcoded origin while doing it. That is a new regression on main, not inherited debt, and it lands in the gate the PR exists to harden.
The sites, on current main
plugins/source-control/reference/review-discipline.md:233
git fetch origin <branch> && git merge-base --is-ancestor <fix-sha> origin/<branch>
plugins/source-control/skills/pull-request/SKILL.md:181
git fetch origin <branch> && git merge-base --is-ancestor <fix-sha> origin/<branch>
origin appears twice per line — once as the fetch target, once in the comparison ref.
Why it is a regression rather than pre-existing
git grep -c "git fetch origin" over those two files at the PR's base 78dbb10e returns 0. The hardcoding did not exist before #2262.
Meanwhile the remote-resolution seam is already there and already used elsewhere in the same skill: plugins/source-control/skills/pull-request/scripts/resolve-remote.sh (3671 bytes on main, with resolve-remote.test.sh beside it). reference/create.md pushes through push-branch.sh / resolve-remote.sh --push. The new gate does not route through it.
The failure
The skill supports non-origin and triangular/fork configurations. On those:
- False negative. A push succeeds through
resolve-remote.sh --push to a vendor or fork remote; D6 then fetches origin — a different remote, or one that does not exist — and reports the fix as missing. D7 and thread resolution are blocked on a gate that is wrong, on work that actually landed.
- Wrong-ref verification. When an
origin base repository carries a branch of the same name, the ancestor check runs against that branch and can pass or fail on a ref unrelated to the PR.
This is the same family #2244 exists to close: a check that answers confidently while operating on the wrong object. #2244's original defect was .[0].sha answering "what is the tip"; my own suggested replacement in that issue answered "does this object exist in the repo"; this one answers "is it on origin's branch". Each fix moved the question closer without pinning it to the PR's actual head repository and remote.
Suggested fix
Resolve the PR's actual push/head remote rather than assuming origin — reuse resolve-remote.sh instead of reimplementing resolution. An alternative that avoids the local-remote question entirely is comparing against the PR's head repository and head OID via the compare API, which is what babysit_resolve_thread.py:603 already does:
gh api repos/{head_owner}/{head_name}/compare/{sha}...{head_oid}
# reachable when status in ("identical","ahead") and behind_by == 0
That path is already implemented, already tested, and already the reachability predicate this repo uses elsewhere — the prose gate and the script gate would then agree on transport as well as semantics.
Re-verify any fix against the case that motivated #2244: on fix/babysit-merge-ruleset-context-union, fix commit 1c17be55 is not the tip (af771ff0 is), and the check must still find it.
How this reached main
Recorded because the process gap matters more than the defect. #2262 merged at 2026-08-12T02:07:19Z before any verifier verdict was posted to it. Codex had flagged this as a P1 on the PR at 02:10:54Z — roughly three minutes after the merge. The independent verifier's verdict, recovered and posted afterward, explicitly scoped its APPROVE to five assigned items and stated that remote resolution "was outside my item set and I did not assess it", while confirming the three factual premises above.
So the finding was neither missed nor overruled — it simply arrived after the merge, and nothing held the merge until verification existed. See also #2265, which is the same shape one layer down: a rule computed and then not enforced.
PR #2262 (merged as
9daeecb3) replaced D6's branch-tip read with a genuine reachability check — the right fix for #2244 — but hardcodedoriginwhile doing it. That is a new regression onmain, not inherited debt, and it lands in the gate the PR exists to harden.The sites, on current
mainoriginappears twice per line — once as the fetch target, once in the comparison ref.Why it is a regression rather than pre-existing
git grep -c "git fetch origin"over those two files at the PR's base78dbb10ereturns 0. The hardcoding did not exist before #2262.Meanwhile the remote-resolution seam is already there and already used elsewhere in the same skill:
plugins/source-control/skills/pull-request/scripts/resolve-remote.sh(3671 bytes onmain, withresolve-remote.test.shbeside it).reference/create.mdpushes throughpush-branch.sh/resolve-remote.sh --push. The new gate does not route through it.The failure
The skill supports non-
originand triangular/fork configurations. On those:resolve-remote.sh --pushto avendoror fork remote; D6 then fetchesorigin— a different remote, or one that does not exist — and reports the fix as missing. D7 and thread resolution are blocked on a gate that is wrong, on work that actually landed.originbase repository carries a branch of the same name, the ancestor check runs against that branch and can pass or fail on a ref unrelated to the PR.This is the same family #2244 exists to close: a check that answers confidently while operating on the wrong object. #2244's original defect was
.[0].shaanswering "what is the tip"; my own suggested replacement in that issue answered "does this object exist in the repo"; this one answers "is it on origin's branch". Each fix moved the question closer without pinning it to the PR's actual head repository and remote.Suggested fix
Resolve the PR's actual push/head remote rather than assuming
origin— reuseresolve-remote.shinstead of reimplementing resolution. An alternative that avoids the local-remote question entirely is comparing against the PR's head repository and head OID via the compare API, which is whatbabysit_resolve_thread.py:603already does:That path is already implemented, already tested, and already the reachability predicate this repo uses elsewhere — the prose gate and the script gate would then agree on transport as well as semantics.
Re-verify any fix against the case that motivated #2244: on
fix/babysit-merge-ruleset-context-union, fix commit1c17be55is not the tip (af771ff0is), and the check must still find it.How this reached
mainRecorded because the process gap matters more than the defect. #2262 merged at
2026-08-12T02:07:19Zbefore any verifier verdict was posted to it. Codex had flagged this as a P1 on the PR at02:10:54Z— roughly three minutes after the merge. The independent verifier's verdict, recovered and posted afterward, explicitly scoped its APPROVE to five assigned items and stated that remote resolution "was outside my item set and I did not assess it", while confirming the three factual premises above.So the finding was neither missed nor overruled — it simply arrived after the merge, and nothing held the merge until verification existed. See also #2265, which is the same shape one layer down: a rule computed and then not enforced.