Reports that survive being full

The patrol-report slice shipped its history view a while back, but the honest note beside it said the storage gates were still open: what happens when the retained store gets genuinely full, genuinely corrupt, or genuinely cut off mid-write. Those gates are now closed with measurements, and the verified build is the one the stable local launcher boots.

Measured, not claimed

The capacity cohort filled a real store, restarted it, and audited the raw SQLite files independently:

• At the record cap the store holds 6,554 observations, 6,553 collections, 3,277 attributions and 16,384 receipts. The report past the cap stayed as the single durable pending item across a restart, with no eviction and no duplication.
• Query time stayed flat with size. Across 48 samples per point the median region query held at about 1.5 ms from empty store to full, and paging the entire full store ran at 5.8 ms median.
• A real page-ceiling failure was induced, not simulated: pinning the SQLite page budget produced an actual SQLITE_FULL mid-commit. The published pending report survived, the reopened store committed it exactly once, and the journal emptied. This is a budgeted store refusing cleanly, which is the behavior that has to be true long before any server does this at scale.
• Corrupted headers, an oversize database and a future-format journal were all refused byte-exact, with the originals left untouched.

What you would see

Five rendered processes with 38 pixel-gated checks, on the same pinned candidate binary that is now staged: a report fixture that survives an ordinary quit and reopen, a reloaded journal that discloses the pending report exactly once, a pending “Retry storage” refusal that is readable instead of mysterious, and a view at another port that shows no cross-region disclosure. Screens were reviewed by hand, frame by frame, and the raw audit passed against retained copies of the database before and after.

Two earlier capture attempts failed on near-black frames and were kept, not quietly deleted: they turned out to be an environment change in hidden-window rendering, proven by reproducing the failure on the old staged binary and passing with its window shown. A build that fails for environmental reasons is still documented as a failure.

Staged with a way back

Staging ran through the transactional local staging journal: the whole tree is hash-verified, the old build is retired rather than deleted, and the journal can recover an interrupted publication. The stable launcher now runs WindowsReports9, and WindowsStanding27 is held as a hash-verified rollback.

Still open in this line, unchanged by any of the above: archive reclamation, shared propagation and case outcomes. And none of this is MMO capacity or OS disk-exhaustion evidence. It is a bounded local store that refuses cleanly, which is the minimum a shared world will need.

The voyage ledger

Alongside this post, the site has a new page: the voyage ledger. It lists every numbered roadmap item in the state its own validation document supports, computes the distance-to-complete from those rows under a printed counting rule, shows the measured spend so far (commits, tests, tokens, all with caveats about what is and is not metered), and names which model runs on which subscription and does what. Percent is a ledger average, not a promise. A percentage cannot feel like a boat.