Build Log
A Plan That Survived Its Own Failure
The project plan was supposed to preserve continuity. When a mounted-file edit silently cut off its tail, continuity itself became the object of engineering.
A successful-looking write
The plan grew during the v3 design pass and was found truncated at line 181. The mounted editing path had conserved the earlier byte length and discarded the new tail. A normal read could appear to confirm the damaged file because it used the same stale mount view.
The plan was reconstructed from surviving sections and dated records, then written through host Python with byte-count verification. The incident was not treated as an isolated annoyance; it became evidence about the storage boundary.
Defence in depth for ordinary text
Growth edits under C:\Local now use a verified safe-write helper. Session-close integrity scans check zero-byte files, NUL bytes, missing final newlines, malformed JSON, and suspicious Markdown fences. Deployment refuses HTML that opens without closing or text containing NUL bytes.
Versioned releases and project history provide recovery points if prevention fails. The point is not that text files are fragile; it is that every system boundary can fail in a characteristic way, and controls should reflect observed failure modes.
What became standard
A control document is production infrastructure. Writes need independent verification, resolved work moves to an append-only history, and the live plan stays a compact statement of current state. Incidents update the shared standard so another project does not have to rediscover them.
That discipline supports the public Editorial Standards, the maintained Build Log, and every version of the calculator.