The full store that made room

The Reports9 slice proved the patrol-report store can be honestly full: at its 16,384-record cap it refuses cleanly, keeps the overflow report durable and pending, and never evicts or fakes anything. That was the right first answer. It left one honest problem: full was permanent. A captain who patrols long enough would eventually just stop being able to report.

This slice adds the missing half: rotation.

Sealing, not deleting

When the live store nears its cap, the queue stops at a boundary, seals the whole store as an immutable generation file, and reopens a fresh store. Every sealed generation is hash-pinned and independently auditable: the same raw SQLite validator that checked the live store re-derives its graph from bytes. The ledger beside them, a canonical JSON manifest, records each generation’s hash, exact record counts, and how many attributions were still active when it sealed, so future decisions know what a removal would really erase.

Reclamation works the other way around from how deletion usually works: before a generation’s bytes go, the ledger first records their hash, counts and reason, fsyncs, and only then does the delete happen. If the game dies between those two steps, the next launch completes the delete, and it completes it only while the bytes still match the recorded hash. Bytes that no longer match are refused and kept for inspection. There is no path that quietly forgets.

Killed on purpose

None of this is claimed from reading the code. The build was run as a packaged Windows binary and killed with process termination inside each crash window:

• After the seal intent was durable but before the store moved.
• After the store moved but before the ledger committed the seal.
• After the reclaim was recorded but before the bytes were deleted.

Each kill, followed by a plain relaunch, settled into a valid vault, and an independent Node audit re-derived every generation from raw bytes and bound the runs, logs, barrier pids and hashes. A separate rotation cohort ran ten real reports through the production queue with a low verification threshold: five rotations fired, every occurrence ended up in exactly one generation, a report interrupted mid-receipt correctly waited for the next boundary before any seal, and re-offering an already-archived occurrence is refused instead of duplicated. The Reports9 capacity regression was re-run against this same binary and stayed green: cap, flat query times, restore, page ceiling.

What this is not yet

Rotation is wired into the production report queue, but this build is not yet the staged one: the stable launcher stays on Reports9 until the rotation build passes its playable smoke regression, which is the next step. Sealed generations are not yet browsable from the in-game history view (it reads the live store), there is no shared propagation, no case outcomes that could pin an open case’s evidence against reclamation, no subject-requested deletion, and no claim about power-loss durability or MMO-scale capacity. This is the local archive, honestly bounded.

Update, same day: it is the staged build now

The playable smoke regression passed on the rotation binary: the full harbor smoke run, the captain’s patrol-report history with a restart reload, the Express helm run and the core simulation, every frame pixel-gated and the report-history and harbor frames reviewed by hand. The rotation build is now the staged stable build on the local launcher, staged transactionally, with Reports9 retained as the hash-verified rollback and the staged copy itself re-verified green. The remaining limits above are unchanged: sealed generations still cannot be browsed in game, and there is still no shared propagation, no case outcomes and no subject-requested deletion.