release: forjar 1.32.0 — the per-machine lock names the binary that wrote it, keeps its creator, and lock --restamp converges a state dir

[noahgift]

Cut v1.32.0. It is 50h past its cadence due date (2026-09-18T08:50:38Z = v1.31.0 cut + cadence_days: 2), with 3 PRs merged in the window v1.31.0..HEAD.

The window

PR	ticket	what
#570	PMAT-565	the lock names the binary that wrote it, keeps its creator, and lock --restamp converges a state dir — the only behaviour change
#577	PMAT-576	booked v1.31.0's ledger row, declared v1.32.0
#583	PMAT-579/581/582/587	registered rows from auditing a fleet pin under 1.31.0 (no implementation)

One behaviour, and it is the fourth signature of paiml/infra#605 to be answered.

Why it is cut this thin rather than held for company

Two fleet-wide defects were reproduced during this cut and are deliberately NOT in it:

• apply --refresh never consults completion_check for a resource containing a template — every guard on the fleet is affected #590 — apply --refresh never consults completion_check for a resource containing a template. Reproduced against the released 1.31.0 binary, narrowed to refresh_seed::check_passes_on, not yet to a root cause.
• nothing compares LIVE against the DECLARATION: drift is live-vs-lock, plan is config-vs-lock, and a declared version: is an input to neither #591 — nothing compares LIVE against the DECLARATION.

A correctness fix that has not reached a root cause is not a release candidate. Both target v1.33.0, two days out, so they ship on cadence rather than by slipping this train further.

Done when

• Cargo.toml and Cargo.lock at 1.32.0
• CHANGELOG [Unreleased] renamed to [1.32.0] - 2026-09-20
• docs/audits/crux-1.32.0.md — gate H, >=3 world-class systems for the one bullet
• every ticket in the window carries release:v1.32.0 and status: completed — gate T
• paiml/forjar-cookbook bumped and pushed before the tag, and the cut names the resulting commit
• make dogfood-release exits 0

[noahgift]

Release state — 2026-09-20T21:40Z — BLOCKED on yoga runner images, not on the code

Main: 770a4857 (the cut #593 merged 15:36Z, the clippy fix #596 merged 17:37Z). Cargo.toml at 1.32.0. No tag. make dogfood-release: nine gates, exit 0 on the cut branch.

CI on 770a4857, every red with its runner and cause

workflow	result	runner	cause
Lint	success	intel-clean-room-15, yoga-build2	#596 fixed the rustup directory override; green on the runner family that was red
CI (gate)	success	—	the one required context
MSRV, Benchmarks	success	—
Coverage	failure	yoga-build	rsync is absent → nas_archive::tests::the_environment_can_exercise_the_safety_property panics at tests.rs:510; 13552 passed, 1 failed
Proofs	failure	yoga-build	kani — step Assert kani is available. lean passed this run on intel-clean-room-2; proofs is the aggregate

The cause, fully determined — one finding, not three

infra-45 ran the inventory on every runner, in the venue the job uses:

	lean	rsync	kani
yoga-build / -build2 / -build3 / -eph	ABSENT	ABSENT	ABSENT (measured this run)
gx10-pool1 / gx10-build	ABSENT	ABSENT	—
intel host	PRESENT	PRESENT	PRESENT

No container on the fleet has any of these tools. Only the intel host does. The alternating pass/fail across runs of one commit is fully explained: the job lands on intel or it lands anywhere else. Five instances today on this repo — rsync, cargo-clippy, lean, kani, and jq on another image — all paiml/infra#813.

Unknown{EnvDeath} has both halves for every one of them: same tree green on a runner that has the tool, failing runner lacks it by inventory. That is a determination, not a classification. It does not make the red green.

Why the reds are correct and must not be waived

nas_archive's test fails rather than skips on purpose (#289 — its first cut produced seven PASS results while none ran). The lean and kani assertions exist so a missing prover cannot silently skip. Re-running until a job lands on intel would be a green nobody can reconstruct — the exact trap forjar#573 was.

What is fixed, what is pending, who owns it

• clippy — fixed, fix(ci): lint was measuring a toolchain this repo never pinned (PMAT-567, closes #567) #596, green on main with runner names. Done.
• yoga runner images — need lean, kani, rsync (and per #813, jq, git, curl, unzip, fontconfig on other images). Fix is the image via forjar apply, never by hand, never a re-run. paiml/infra#813, infra-45.
• Interim merge lane — remove clean-room from yoga's label set in machines/yoga/forjar.yaml until its image converges, so jobs stay required and the runners that cannot run them stop being offered them. A removal with fleet effect; not made by anyone on a relay, correctly. Needs an operator ruling in infra's session or the forjar one.
• Publish — make publish-from-tag TAG=v1.32.0, human credential by design (env -u CARGO_REGISTRY_TOKEN at scripts/publish-from-tag.sh:258). An operator directive authorizing the session to run it is recorded in paiml/infra#824 §8; it has reached this session only by peer relay and is unconfirmed in-session. Moot until the reds clear.

Not blocking anything

• proofs red is the aggregate of kani; it clears with it.
• cancelled ×3 on earlier runs were concurrency siblings, not failures.
• apply --refresh never consults completion_check for a resource containing a template — every guard on the fleet is affected #590 and nothing compares LIVE against the DECLARATION: drift is live-vs-lock, plan is config-vs-lock, and a declared version: is an input to neither #591 (1.32.1 / 1.33.0) are diagnosed and unblocked; they do not wait on this.

Sequence once the yoga reds clear

clean-room green on 770a4857, every job actually run, runner named
  → tag v1.32.0 by the in-repo path (PAT or deploy key, or release.yml does not fire)
  → make publish-from-tag TAG=v1.32.0
  → cookbook requirement + lock, one commit → booking PR → gate T
  → dogfood receipt on the tag → infra pin PR → forjar apply, mini first

Every number above is reproducible from gh run list --branch main and gh api repos/paiml/forjar/actions/jobs/<id>. Nothing here is inferred.