[Deep-Sixed]

Work package: release integrity, step 2 of 2. Branched from main at c86bf47, the merge of #6. This completes the P1 finding from the repository review: the scripted install now delivers the verifier that main describes.

The defect

install-ladder.sh and check-install.sh pinned 760977f. That build predates execution binding (#3), the bound CI chain (#4) and the committed adoption line (#5), and still reports evidence-v3.1. A scripted install delivered none of that hardening, and the installed verifier could not read a consumer's evidence = "…/3" policy line.

The change

	before	after
PIN (both scripts, and the installer tests)	760977f	c86bf47, the #6 merge that released 0.3.0 / evidence-v3.2
CHECKER_SHA	09f65bcc…	d7b92251…. The checker changed, and the suite already holds this equal to its digest.
INV_SHA	282f2117…	unchanged, re-validated: the INSTALL.md invariant block hashes identically at both pins

c86bf47 is the earliest commit the pin could name. The installer refuses a pin that isn't already an ancestor of origin/main, which is why this couldn't share a PR with #6.

"The pin predates scripts/" is no longer true. Detaching to c86bf47 doesn't remove the scripts from the checkout any more. It replaces them with that revision's own pair, which is older and was reviewed with the older pin. The installer's comments, its missing-checker refusal, its closing message and INSTALL.md now say this, and say to run the bootstrap copies. I checked that the older checker fails safe rather than passing: run from inside the checkout it reports INSTALL DOES NOT CONFORM, expecting 760977f.

The CHANGELOG.md 0.3.0 entry now records the pin move instead of saying it hasn't happened. VERSION stays 0.3.0 because nothing about evidence semantics changes.

Regression

test_the_pin_installs_the_hardened_release reads verify.py at the pin. It requires evidence-v3.2, 0.3.0 and the adoption-line reader, and requires both scripts to name the same runtime. In an isolated copy of main with the old pin, it fails on its first assertion. Its values are hardcoded rather than compared with the working tree, because a future contract bump has to land one PR before the pin can follow it.

End to end

A scripted install into a clean HOME, against the real GitHub origin, using this branch's pair:

invariant extracted and checksum-verified (282f2117…)
ok    clone detached / tracked tree identical to pin / no untracked files
ok    claude resolves into the pinned clone / invariant complete and verbatim
ok    verify.py executes via link
INSTALL CONFORMS

installed runtime: c86bf47  COMPATIBILITY = "evidence-v3.2"  VERSION = "0.3.0"

A stale-bytecode finding during verification

The first full gate run after committing showed 10 installer failures, all asserting the old pin. The committed file was correct. My negative-control step had rewritten the test file within the same second, at the same size (both SHAs are 40 characters), so pytest's .pyc passed its mtime-and-size staleness check while still holding the old pin. I confirmed this by reading the .pyc header, cleared the untracked caches, re-ran from rung 2, and redid the negative control in an isolated copy with bytecode writing off. Earlier CI results for #2–#6 all ran on fresh checkouts, so none of them depended on a cache like this.

After merge

Per the approved plan, v0.3.0 is tagged on this PR's merge commit. That is the first state holding both the 0.3.0 verifier and an installer that delivers it. The installer inside that tag pins the runtime to c86bf47. That isn't a contradiction: the bootstrap tooling and the pinned runtime are deliberately separate, and verify.py is identical at the two commits. Consumer qualification against Cerberus follows as #8.

Verification

Climb against eeade51f5a19 + sha256:87ffca430e23, over a baseline on main at
c86bf47: lint, tests-py311 and tests-py314 came from CI run
35846925022,
tests ran locally, and the six judgment rungs are attested.

  BLOCKED REQUIRED GATES   0
  STALE EVIDENCE           0
  STATE MATCH              TRUE
  CLEAN CLIMB              TRUE
  READY FOR HUMAN GATE     TRUE

• Local suite: 400 passed, 1 skipped (399 + 1); drift: false; Ruff clean.
• Both CI events are green: push
  35846925022
  and pull_request
  35846951533.

🤖 Generated with Claude Code

https://claude.ai/code/session_016m6di8xFVdwwq949mJx9U1

---

Generated by Claude Code

---

Generated by Claude Code