Failure catalogue · The wrapper betrays the numbers · 51 of 51
OBSERVED FAILURE MODE
The blocked run that ate the good pack.
A build hit its blocking condition, cleared the output directory, and moved the failed run into its place, destroying the last certified pack. The BLOCKED page it left behind said the previous pack was untouched, so the one artifact written to be trusted during a failure carried a claim the filesystem contradicted.
What we saw
In our own audits a build reached its blocking condition and performed the destructive half of a normal publish anyway: it cleared the deliverable folder and moved its failed output into place. The certified pack that had been there was gone. The BLOCKED page it wrote was well formed, named the blocking reason, and stated that the previous pack remained untouched, which was false at the moment the sentence rendered. The failure path had never been run against a folder that already held a good pack.
Why it passes a glance
Failure paths get written once and exercised least. On an empty output folder the destructive clear is invisible, so the case that would expose it is the one nobody runs. The BLOCKED page reads as the responsible outcome, and its claim about the prior pack is prose rather than a measurement, so no check on the page could ever disagree with the disk.
What addresses it
The verification-practice skill catalogues this exact shape among its measured fatals: a refused build that still wrote into the live output directory. Doctrine principle 5, Fail closed and stale, requires the build to assemble in staging and swap only after the final gate passes, so a failed run leaves the prior pack byte-for-byte intact and marked as having a newer cut under review. The claim and the filesystem agree, or the build fails.
Check your own file in two minutes
- Put a known-good pack in the deliverable folder, force a blocking failure, and list the folder afterwards.
- Confirm no failure path clears or writes to the live folder, including paths added since the last review.
- Confirm the BLOCKED page's claim about the prior pack is computed by reading the folder, not typed.
What this does not catch
Staging keeps the prior pack intact. It does not tell the reader how old that pack now is, which is a separate obligation: the live version says a newer cut is under review, names the blocking reason, and a person is told directly.
Quick answers
- How is this different from a rerun overwriting the pack?
- The destructive write is the same. What makes this one worse is the artifact left behind: a BLOCKED page asserting the prior pack was untouched while the folder said otherwise, in the moment a reader most needs the page to be true.
- Why do failure paths break more often than success paths?
- They are written once and exercised least. On an empty output folder the destructive step is invisible, so the case that exposes it is exactly the case nobody thinks to run.
- Should the BLOCKED page make claims about the filesystem?
- Only ones it measured. Read the folder and report what is there, because a claim nothing can falsify is decoration in the one artifact a reader turns to during a failure.
Nearby failures
Last updated 2026-09-02 · Dylan, founder · one of 51 observed failure modes, every one seen in a real build or in our own audits, none invented.