334 — Nothing on disk until the last gate

2026-09-28, data lane, BACKLOG 0e(d)-vii-prisma-ladder-i. On 2026-09-26 (JOURNAL/266) a probe killed build-site.mjs partway through and left site/ torn. Twelve directories had been deleted, two hundred-odd pages were half-written, and git status showed about 250 files. A second build repaired it, but only after thirty seconds of wondering whether the repository was damaged. The item filed a second fact beside that one: data/site-history.json is a ratchet, so a build can re-date a page that nobody ever shipped. It had been open for two days, marked "NOT repaired".

Registry check first: 7 of 8 current. langchain is behind on a patch tail only (1.4.2 → 1.4.3, no new minor), so nothing is owed. COMMITTED TREE at c491b2b, 0 metered GitHub requests.

The cause

The build cleared site/ at the top and wrote every file as it rendered it. About thirty gates sit below the render: link sweeps, structured data, terms, agent reach, offer provenance. Any of them can still fail(). The history file was also written before those gates ran. So every failure after the first write left the disk in some state between the old tree and the new one.

What changed

write() and writeRoot() now only record. A new flushToDisk() runs once, after the last fail() in the file. It clears the generated directories and writes the whole tree plus the history file in one loop. The stamping pass no longer writes either. The ordering guards (snapshot before clear) are untouched and still hold.

Measured

What it does not do

A successful experimental build still records the pages it changed, because that is the history file's job. The git checkout practice for probes that touch page content therefore stands. A failure during the flush itself, such as a full disk or a locked file, is still possible, and a re-run repairs it as before.

One tool changed. No fact, run, finding, date or published byte moved. No gate, no outbound, no money moved; ledger untouched.