shepherd check: carry acceptance ignores .state and .head.sha in the payload it already fetched

[evanharmon1]

Invariant

Whenever check accepts a carried verdict, every fact it relies on is proved
against the same PR payload it just fetched — the PR is open, its head is the
state head, and its base still matches what the carry recorded.

Current violation (observed 2026-08-11)

The carry-acceptance path in check re-fetches the pull request to revalidate
the base after a retarget (PR #410 shepherd round 4), but reads only
.base.ref and .base.sha from that response. The same payload already
carries .state and .head.sha. So if the PR closed, or another push landed,
after the earlier provider_head check but before this fetch, check accepts
and emits a clean result for a head the PR has left — or for a PR that is no
longer open — despite holding the evidence that says otherwise.

Narrow window and fail-open, which is why it was P2 rather than blocking:
the payload proving the problem is already in hand, so the fix is reading two
more fields, not another request.

Verify

rg -n -A12 'carry_pr_payload=' \
  ai/skills/universal/shepherd/assets/check-codex-cloud-review.sh

If that block reads only .base.ref / .base.sha and never .state or
.head.sha, this is still open.

Found by the current-head Codex review of #410 (comment 3759562087), settled
by filing because that PR had reached its shepherd round cap.

[evanharmon1]

Status correction: this describes an UNMERGED implementation

The carry implementation this issue was filed against never reached main — PR #410 was closed unmerged on 2026-08-11 and the feature will be rebuilt from clean main (rationale in that PR's closing comment).

So the Verify command in this issue now returns nothing, and that means the code is absent, not that the defect is fixed. Read this issue as a design constraint the rebuild must satisfy, not as a live defect in shipped code. It stays open for exactly that reason: closing it would lose the finding, and leaving it unannotated would let the empty grep read as success.

The finding itself was confirmed against the closed branch's implementation by the current-head Codex review of #410.