--- title: The Premature Pin status: ANTICIPATED repo: archive observed: 2026-07-20 caught_by: reasoning through the failure path in review one_line: Writing the release pin at the start of a --release run would have silenced the very NOT-CURRENT notice it was meant to trigger — caught before any release hit it. guard_location: museum/generate.mjs · the pin is written after a successful build, at line ~2401 (commitPin), never in resolveReleasePin() at line ~255 verified: a museum on disk and its pin can never describe two different releases — the pin is written in exactly one place, after the atomic swap exhibited: true lesson: A guard added in the wrong order can cause the exact failure it was built to prevent; ordering is part of correctness. provenance: - museum/generate.mjs resolveReleasePin() lines ~255-264 (the inline account) and writePin()/commitPin() - mockup museum/design/2026-07-identity-pass/04-bug-museum-records.html (specimen 05) --- ## What happened This defect **never shipped** — it was caught in review as a failure path in the release machinery. Writing the release pin at the **start** of a `--release` run looked harmless. It was not: a run that failed partway would leave the pin claiming a release the museum was never generated for. The museum on disk would be the **old** release, the pin would claim the **new** one — and because the pin then matches the newest tag, the NOT CURRENT notice (see [[silent-flatline]]) goes **dark** at the exact moment it should fire. The guard meant to prevent "authoritative and quietly wrong" would itself have *caused* it. ## How it was caught By reasoning through the failure path in review, before any release ever exercised it. The inline comment in `resolveReleasePin()` records the reasoning verbatim. ## The guard The pin is written in exactly **one** place — `commitPin()`, **after** the new museum has been validated and atomically swapped onto disk. `resolveReleasePin()` marks the intended tag `pendingWrite: true` but writes nothing. A failed run leaves the old museum and the old pin, still honestly describing each other. ## What the guard costs A failed `--release` run must be re-run from the start; the pin can never be advanced "in preparation" for a build that has not succeeded yet. ## Containment Structural: there is exactly one write site, downstream of the atomic swap, so a museum on disk and its pin can never describe two different releases. This is a design invariant, not a test result — the state that would violate it is unreachable. ## Provenance `museum/generate.mjs` — the `resolveReleasePin()` inline comment (lines ~255-264) states the failure and why the up-front write was rejected; `writePin()` / the commit-the-pin step at line ~2401 is the one write site. Mockup specimen 05 corroborates. No commit ref is cited for a "fix" because the defect was designed out, never committed and reverted — an honestly absent field, not an omission.