Skip to content
Dead Water In development
Back to the devlog
Pre-production by Kit

The archive you can still read

A full patrol-report store now seals into an immutable archive generation instead of staying full forever, and the captain's history view can read those sealed generations in game: each page names its generation's hash, revision and what was still active when it sealed. Verified by rotating a real generation inside the shipped game and reading it back.

Two posts ago the store learned to make room: a saturated patrol-report store seals into an immutable, hash-pinned generation and a fresh store keeps accepting reports. One honest gap remained: the sealed bytes were readable by the audit tools, but not by the captain. History that exists and cannot be read is only half kept.

This increment closes that gap in the report view itself.

What browsing looks like

When a rotation has sealed at least one generation, the patrol-report screen grows two controls: back to the live store, and into the sealed archive, newest sealed generation first. The archive view changes the header to say so, and every generation page names its own provenance line: which generation it is, the first characters of its SHA-256, its revision, how many observations it holds, and how many hull attributions were still active the moment it sealed. Because a sealed generation is frozen, its page shows all ports at once, each row tagged with the port it belongs to. The live store’s own controls, refresh and retry-storage, are hidden while browsing: there is nothing to retry on bytes that can no longer change. Reclaimed generations simply stop appearing; their removal is already written down, hash and counts, in the ledger.

Proved by rotating a real generation inside the game

This was not claimed from reading code. A capture scenario runs inside the packaged Windows build: two actual surface-patrol encounters produce two genuine reports, the rotation seam is armed so the second report’s entry boundary seals the first generation, and then the captain’s history view is opened, pointed at the sealed generation, and screenshotted at both window sizes. The rows shown are read from the sealed bytes through the same production code path the game uses, not a test-only reader.

The native rotation cohort gained the same assertions at the queue level: browsing positions must match the manifest row for row, newest first, and positions outside the archive must be refused. Editor coverage grew to 34 vault checks, including that a foreign realm cannot browse an archived page and that out-of-bound paging cursors are rejected.

And the new assertions immediately earned their keep: the first version addressed generations by their ledger number instead of their browsing position, which quietly breaks once reclamation removes older generations and leaves gaps in the numbering. The native cohort failed on exactly that, the seam was fixed to address positions newest-first, and the failed run is retained.

After that, the whole playable set re-ran green on the same binary (harbor smoke, patrol-report history with a reload, the Express helm run, the core simulation), the storage regression held at the 16,384-record cap, 2,504 tooling tests passed, and the build was staged as the stable build with the previous one retained for rollback. The staged copy was re-verified from disk, including the archive view itself.

What this is not yet

No shared propagation, no case outcomes that could pin evidence in an open case against reclamation, no subject-requested deletion, and no claim about power-loss durability or MMO-scale capacity. The archive is local, bounded and honest about both.

No storefront, no wishlist button

Follow the build

We email when something real happens, which is rarely. The devlog covers the rest.

We will not sell your address, and this list is for the game only. No trading talk, no price talk. If we ever break that, unsubscribe and tell us why.