[noahgift]

What

Every ratchet in guard-tree and guard-cargo compares the PR's tree with origin/main. The setup step fetched main's tip at depth 1. The tip moves while the merge commit does not. So a run that starts after main shrank a baseline, or fixed a function, goes red on lines the PR never touched.

• feat(release): nightly assets rehearsal — build every release asset on a schedule, unable to upload (#4806) #4813: the pipe-into-grep-q ledger read 62 on the PR against 60 on a tip that had moved on.
• guard-cargo m17 (complexity shrink-only) and sibling ratchets: false red on rerun after main moves #4983: fix(gpu): a test filling the device let neighbours' allocations OOM in-process (#4956) #4970's complexity step, run 37945794011 attempt 2, checked out the unchanged merge commit 60a5903 and judged it against main's moved tip acd599e. Two attempts on the same commit disagreed.
• fix(gpu): a shared cubin temp file let a reader load a partial cubin (#4956) #4964: a fresh run after a close/reopen (37978589934) is still red, on m17/m0 only. The reopened event carried GitHub's cached merge 24eb969, built on main 9259972, while the tip had moved on. A close/reopen therefore clears this red only when the merge ref's first parent already equals main's tip. With the pin, that run is judged against 9259972, the main it was built on.

Fix

scripts/ci/pin_build_base.sh replaces the fetch step in both jobs. It points refs/remotes/origin/main at the commit the run was built on:

event	origin/main is pinned to
pull_request	the merge commit's first parent. HEAD must be a two-parent merge whose second parent is pull_request.head.sha, else it refuses
merge_group	merge_group.base_sha
any other event	the tip (deepened by one on push)

On any doubt it prints ::error::pin_build_base and exits 1, so the guards skip red, never green. Its --self-test (22 rows) runs in guard-tree before the pin.

The ratchet library's own first-parent comparand (FIRSTPARENT, from the #4983 commits on this branch) stays as a second line of defence. With the pin in place, the tip path and FIRSTPARENT name the same commit. The pin also covers readers of origin/main that do not use the library, and the merge queue.

Falsifier

scripts/tests/ratchet_semantics_test.sh --class complexity: 22 checks, 0 failed.

row	case	expected
C10 / C14	stale-merge re-run (main moved after the build), via the library / via the pin	GREEN
C13 / C15	a real complexity rise, via the library / via the pin	RED (NEW newbie)
C12 / C16	planted mutant of the library / of the pin	the re-run turns RED again

Measured mutants, both caught:

• MA: the library's first parent forced to HEAD. C9, C10, C12 and C13 fail.
• MB: the pin takes the second parent. C14 and C15 fail; under MB the real rise went green.

Also green on this head:

• ratchet_semantics_test.sh: readme class 12/0, satd class 10/0;
• check_baseline_ratchets.sh --selftest and check_no_fabricated_baselines.sh;
• fat_driver.py self-test 60/60;
• check_sourced_libs_option_neutral.sh;
• the 13 guards that read ci/sections.yml.

Not in this PR

• A second pin. The refinement gate in workspace-test pins origin/main with its own event map (batch/ont-10: every remaining ONT-10 row for 0.70.0 (one PR, one quorum, one CI) #4502, ci/sections.yml:430-440): pull_request.base.sha, merge_group.base_sha, push before. This PR leaves it alone. On the two real runs read, it names the same commit as this pin:

  run	merge commit	its first parent	refinement base
  fix(gpu): a test filling the device let neighbours' allocations OOM in-process (#4956) #4970, 37945794011 attempt 2	60a5903	845004a	845004a
  fix(gpu): a shared cubin temp file let a reader load a partial cubin (#4956) #4964, 37978589934 (reopened)	24eb969	9259972	9259972

  On merge_group both read base_sha. Two maps with no row comparing them can still drift apart without anyone noticing. Follow-up: one guard row that asserts both give the same commit per event, or the refinement step calling pin_build_base.sh. Changing a second gate here would widen this gate change.

• Self-test gaps. The second review's mutation run tried 27 mutants and killed 21. The six survivors are missing rows, not wrong results on the plants:

  • the pin without its read-back of origin/main;
  • the pin with a failed tip fetch swallowed by || true;
  • the library's FIRSTPARENT arm without its origin/main condition, and without its empty-merge-base condition (two mutants);
  • check_no_fabricated_baselines.sh without its origin/main condition;
  • check_census_derived.sh without FIRSTPARENT in its accepted modes.

  They go in the same follow-up as the comparing row.

Gate change

This changes what a gate accepts on PR runs. Before merge it needs:

• a sign-off round from a non-author session, bound to the final commit;
• 2 non-author reviews;
• green CI.

keep-open: #4861 and #4983 stay open for the follow-up named under "Not in this PR" (the row comparing the two pins, and the six self-test rows). #3997 is the parent epic.

Refs #4861
Refs #4983
Refs #3997

🤖 Generated with Claude Code

[github-actions]

§13.11 rung 1 — quorum shadow verdict

S13-SHADOW pr=4996 head=0527930f15a2eb0e43d7dbcf3b85e297845fd811 verdict=REFUSE class=Q1 arm_rc=1

Shadow mode: this records a verdict and merges nothing. A refusal
to arm is not a block (§13 adds zero rows to §7) — the pull request is
exactly as green as it was.