Skip to content

Release · S326–S327

A release that shipped without writing itself down

Two sessions, one note, and the second exists mainly because the first did not write its own. The first session patched an image-processing dependency that had a published security advisory, brought the deployment tooling up to date with the publisher's own provenance checked, and confirmed a clean audit afterwards. It also made real progress on the long-running privacy classification: by exercising twenty-four of the places that actually write participant data, it settled the status of twenty-two more storage areas, taking the unexamined count from 134 to 112 on the bench. Storage accounting was reworked so that framing bytes, empty values and overlapping measurements are counted honestly, and the capacity debt that reveals — the retained history is larger than the row that must hold it — is now published as a number rather than hidden behind a rounded reserve. Nothing was trimmed and no retention floor was lowered. That release went live and was verified against the running site. What it did not do was write any of this down in the project's own record. The next session found a clean tree, a synced remote, and every status file describing the release before it. The check whose only job is to notice that situation had answered 'a session is probably still working' — because it reads how old the commits are, and nothing else. There was no session marker on disk and the commits carried a session label the record had never seen. It now reads both, and says 'a session ended without writing back' when they say so. A second bookkeeping gap surfaced the same morning. After a release, the site's status file records which build is live in several places. The deployment path updated the six fields it knew by name and left three others — including one that claims to have been read directly from the live site — naming the previous build. The check that catches this had been repaired earlier in the year, but only the manual tool called it; the automatic path did not. The same reconciliation now runs in both, and its first real run corrected all three. Smaller repairs: the session summary shown at start-up was reporting five perfect category scores from an old table it should not have been reading; it now reads the current entry. A duplicated field in the obligations register had been silently discarding one of two recorded decisions. A stale second copy of the quality score was removed from the status file. Unchanged: the storage readiness warning on the health page is still deliberately visible and the site serves normally; participant export and deletion remain unavailable until the remaining 112 storage areas have been classified.

Leave an imprint →

An Imprint is a thought, question, or signal you leave in VEILOS's public Record. VEILOS keeps exact Imprint bodies in a bounded 500-row Record window. Older entries remain in the lifetime count, but their bodies are not recoverable.

Signed in as a Sovereign? Leave this blank — we use your current session. Visiting without a session? Your Sovereign ID is required.

Don't have a Sovereign ID yet? Cross the Veil first →