Failure catalogue · The wrapper betrays the numbers · 47 of 51
OBSERVED FAILURE MODE
The rerun that trampled the good pack.
A refreshed pack is written into the folder people already have open. A failed build that writes file by file over the last known-good deliverable leaves a mixture of two runs that still looks like one certified pack. Some pages are yesterday's, some are the failure's, and no surface in the folder says which is which.
What we saw
On a Meridian Journal Group refresh, a failed run wrote into the live deliverable folder as it went, replacing artifacts one at a time until it stopped. What remained was neither the previous pack nor the new one: pages from the good run beside artifacts from the failed one, a manifest describing something in between, and index links pointing at both. Nothing announced a failure. An operator opening the folder saw a deliverable, and the version they could have stood behind no longer existed anywhere.
Why it passes a glance
Writing in place is the default of nearly every build script, and it works flawlessly until the day a run stops halfway. The failure has no visual signature: files carry fresh timestamps, the folder is full, and the pages that survived are genuinely correct. Recovery depends on a backup nobody made, because until this run the folder had always been the backup.
What addresses it
The trust-the-upload skill treats config, history and published output as one state committed atomically: build into a staging directory promoted by rename only on success, so no failure path, including ones not yet written, can touch live output. Doctrine principle 5, Fail closed and stale, is the reason. A failed check blocks the update, the last known-good version stays live and marked as having a newer cut under review, and a person is told.
Check your own file in two minutes
- Kill a build halfway and confirm the live folder is byte-for-byte what it was before.
- Confirm output is assembled in staging and promoted by a single rename after the final gate passes.
- Confirm the old directory is deleted after the swap, never before, so no reader hits a missing page.
What this does not catch
Staging protects the pack from the build. It does not protect it from a person editing published files by hand, which the next build erases anyway. Keep the deliverable folder build output only, and put the first line of the runbook there: do not quick-fix the page.
Quick answers
- Why not just back up the folder before each build?
- A backup depends on someone remembering, every time, including the run that fails. A staging directory promoted by rename makes the destructive step structurally impossible rather than forbidden by a convention.
- When should the old directory be deleted?
- After the swap, never before, so no reader hits a missing page in the middle of a deploy. The swap is the moment the new pack becomes true, and nothing before it touches what readers can see.
- What does a reader see while a build is blocked?
- The previous pack, still live, marked as having a newer cut under review, with the blocking reason named. Stale and correct beats fresh and wrong, and the gap between them is where trust is lost for good.
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.