For six days this month the site could not be built. Nothing was wrong with the site, and nothing was wrong with the scripts that build it. The machine simply stopped being able to run a command. A Windows security update installed on 8 September replaced a component that lets the Linux workspace where the build tools live see the Windows drive they read from—and after that, every attempt to run the citation checker, the structure checker, the safe‑write helper or the deploy chain failed before the command was dispatched.
Three consecutive build sessions ended without a page being written. Two of them ended without anything being written at all. This is a log of what that cost, what it changed about how the work is organised, and how it ended—which turns out to be the most interesting part, and the part with the least documentation behind it.
A failure with no error
The update was KB5124008, the September 2026 cumulative security update for Windows 11, builds 26200.9445 and 26100.9445. It replaced the host‑side pieces of the Plan 9 file‑sharing protocol—the mechanism that attaches folders on the Windows drive to the virtual machine the build tools run inside. After the update the handshake no longer completed.
What made it expensive was the shape of the failure rather than the failure itself. The host reported the share attachment as successful. The guest mounted nothing. No error was raised at the point of breakage; the first sign of trouble came later, when something asked for a shell and got a mount error naming the connected folder. The error pointed squarely at the folder, which was the one thing that was fine. Two separate sessions worked outward from that message and independently reconstructed the same diagnosis from scratch before anyone thought to write it down.
That is the reusable lesson and it has nothing to do with Windows. A diagnosis that costs a session to derive is worth one line in a document, and the line is worth writing the first time, not the third. The pre‑flight that now opens every build session is a single command that prints preflight-ok. If it prints anything else the session stops and follows a written procedure instead of investigating. It takes a second. It replaced roughly two days of rediscovery.
The trade nobody should have to make
There was a repair available almost immediately, and it was the wrong one: uninstall the security update. It worked reliably—several people confirmed the mounts returning within a minute of the rollback and a reboot—and it left the machine carrying an unpatched security vulnerability in exchange for a working hobby build pipeline. That is a bad trade on a personal machine and an impossible one on a managed corporate machine, and on some builds the update turned out to be a permanent package that could not be removed at all, leaving those users with no self‑service option whatsoever.
The decision here was to stay patched and wait. It is worth being explicit that this decision had a cost, because decisions that cost nothing are not really decisions: it cost two build sessions outright and delayed a third. Staying patched was still correct. Security updates are not optional in exchange for convenience, and a site that publishes once a week can afford to publish nothing for a week.
What the outage taught the process
Being unable to work turned out to be a reasonable way of discovering which assumptions about the toolchain had never been tested.
The first was that writing and authoring are separate capabilities that fail separately. A file can be written through a channel that bypasses the broken mount entirely; that was verified under controlled conditions and it works. Authoring a song page cannot proceed the same way, because authoring depends on the citation checker, and the citation checker reads the source PDFs through the mount. So the outage blocked new pages while leaving internal record‑keeping possible—a distinction that had never been drawn because nothing had ever forced it.
The second was sharper, and it is the one worth passing on. A fallback procedure had been written during the outage describing how to lift the sources into a cloud container and run the checker there. It rested on the assumption that the container’s own shell is always available. On 11 September that assumption failed: the tooling broke during start‑up rather than during execution, so there was no container to lift anything into. The fallback had been designed, documented and approved, and it had never been tried, and the first time it was needed it was unreachable.
A fallback that has not been executed is a hypothesis. It is now written with two preconditions that must be checked before it is chosen, rather than discovered halfway through.
The fix, and where it is not written down
It ended on 14 September. Microsoft released KB5129195, an out‑of‑band cumulative update taking the same servicing branch to builds 26200.9457 and 26100.9457. The tool vendor’s status page marked the incident resolved at 19:14 UTC that day and named that update as the fix. The first build session after it landed ran the full chain—citation checker, structure checker, safe‑write, mirror, deploy—without incident.
Here is the part that deserves a moment. The published release notes for KB5129195 describe two improvements: protections for an elevation‑of‑privilege vulnerability in the Windows User‑Mode Power Service, and a fix for a Remote Desktop Services problem introduced by a different September update. There is no mention of Hyper‑V. No mention of Plan 9. No mention of drive shares, virtual machines, or guest mounts. The repair is real and it is in the update, but as far as the documentation is concerned it is not there.
So the evidence that this is fixed is behavioural, not documentary. The shell answers. The mounts are back. The vendor says this update is why. What is absent is the primary source—the vendor of the broken component confirming, in writing, that they repaired the thing that broke.
Documented and reconstructed
That distinction is the one this site spends most of its time on, which is why it is worth drawing here rather than letting it pass.
The same week the shell came back, a song page was rebuilt whose central technical claim—which instrument sat on which of the four tape tracks—had been presented for months as something read off the studio’s own paperwork. It was not. The reference work it came from prints two sets of track layouts: eight taken from surviving tape boxes and track sheets, and a larger set worked out afterwards by applying the known format and the mixing desk’s fixed behaviour backwards from the stereo mix. The authors say so plainly, in the same passage—the second set was arrived at, in their words, not by access to tape boxes or other studio documentation. The song in question is in the second set. The layout was right. The claim about where it came from was exactly backwards, and no automated check on this site could have caught it, because every check tests whether a page is well‑built and none tests whether a sentence describes its own evidence correctly.
A conclusion can be sound and its provenance still worth stating accurately. The tape layout is almost certainly correct; it is a careful deduction by people who knew the equipment. The September fix almost certainly does repair the Plan 9 mount; the behaviour is unambiguous and the vendor is in a position to know. In both cases the honest description is the same: this is well‑founded, and it is not documented, and those are different things.
What stays
The pre‑flight stays. It costs one command and it is the cheapest insurance in the build, and the fault it was written for is the kind that recurs: an operating system component replaced underneath a virtual machine is not a once‑ever event. The written outage procedure stays, with its fallback now carrying preconditions it did not have. The internal record has been corrected—the first session back described the outage as intermittent and not resolved, which was wrong, and it was wrong because it had the machine’s behaviour and none of the announcements.
Six days of not being able to build produced a one‑second check, two corrected procedures, and a clearer account of what this pipeline can and cannot do when part of it is missing. That is not a good trade for six days. It is, at least, not nothing.