The save the player does not choose

EREME has no manual save. No button, no slots, no "save and quit": the menu quits, period, because the game is already written. The engine saves at a single canonical point: the entry of a voyage node, before the event card is revealed. Two echoes at the dock complete the list: a voyage's Binding and a crew change are written too. The boundary is not cosmetic: revealing the card draws on the random generator and arms a decision. Saving after that would freeze a game mid-choice.

The prohibition is executable, not documentary: the save store inspects the state and refuses to write if a decision is in flight. And the file carries the generator's state, serialized as a string because a 64-bit integer above 2 to the 53rd gets truncated as a JSON number: reloading gives back exactly the same draw. The risky bet plays out after the save point; reloading does not replay it differently. It is a save of continuity, not a retry machine.

The write itself is paranoid in proportion to what it protects: a temporary file, re-parsing that temporary before touching the target (a corrupted write never destroys the previous save), delete then rename because renaming over an existing file fails on Windows, and failure propagates: the function never answers "written" wrongly.

That architecture dated from July 18th, tested by a harness that replayed entire sagas comparing the narrative thread byte for byte. On August 6th, I made the honest measurement: the game played on screen almost never got written.

The cause is an inverted ordering. The view refreshed the screen before saving; but reading the state reveals the card, which arms a decision, and the store then refused to write, rightly so. The commit puts numbers on the silent disaster: "Twelve refusals per session, a single save on disk, with no voyage in it." The save point had existed for nineteen days without a single caller on the side where players actually play.

And the harness stayed green. "The ironman gate was green for fourteen seeds straight, because its probe re-loaded the id it had just picked: it measured a path nobody takes." The probe verified the store; nobody verified the view.

The fix inverts the order, save before refreshing, and above all it changes what gets measured: a harness block now cuts the process at the sixteenth screen and demands in-flight writes and zero refusals; the next block literally resumes the game that was just cut, same user folder, same seed. The refusal, once silent, became a watched metric. The code comment owns it: "A save that fails silently is worse than no save at all: the player believes their game is written."

One exception runs through all of this: the prologue. Until its Binding, it writes nothing to disk; a saga's first write is precisely that Binding. That is owned: with the same seed, the prologue replays identically.

On August 15th, the morning playtest died hard, exactly there: at the end of the prologue. No error window, a blank engine log, ten minutes of choices lost, and above all nothing to diagnose. The zone without a save net was also the zone without a diagnostic net.

My answer was not to add a save to the prologue, but to admit that two different things deserve to survive a crash: the game, and the diagnosis. The game has its store. The diagnosis got, that very day, its black box.

A separate journal, where every line is flushed to disk before handing control back: the line belongs to the operating system, the death of the process can no longer take it back. The gesture is noted before being executed, its result after, the card at its reveal, the seed at undocking. The commit title sums up the contract: "A dying process leaves the scene, the seed and the last gesture."

The most elegant part is the reversal of the burden of proof. A clean shutdown writes an end marker; a death writes nothing. At the next launch, the trace without the marker is filed as a death trace, apart from the clean ones: the absence is the confession, and yesterday's crash survives today's healthy sessions.

And the harness proves the box the way the box deserves: the probe kills a real process, no shutdown, no final flush, and a second process reads the file. "A real death cannot be measured from inside the process that suffers it." I sabotaged the gate twice to check that the net bites, and the commit's measurement is blunt: without the line-by-line flush, the dead process leaves zero bytes.

The August 15th crash has still not been reproduced. The black box did not fix it, and that is the point: it is the instrument set in place to catch it next time, with the scene, the seed and the last gesture already on disk.

Saving and diagnosing are two disciplines, with two distinct proofs. The game is protected by a single write point and proven by a replayed power cut; the diagnosis is protected by lines flushed one by one and proven by a process actually killed. Confuse the two, and you discover at the first real crash that you have neither.