queue: mercury check-in 2026-10-27 re-measured -- census reproduces exactly (121 entries, 1/115/5 badges, 200/34,488 B); the 331,776 B state.db delta is arithmetically exact but was measured inside the run's own writes and the separated 60 s window reads 0 B on both files, so it is not a rate; WAL is exactly 67,108,864 B (64 MiB) on five readings over 34 minutes with a moving mtime and no wal/journal key in config.yaml (cause Unrecovered); R5-a's verdict stands but stat-then-head is still a moving-file digest -- the reproducible form is sqlite3 .backup then digest the copy

This commit is contained in:
Timmy committed 2026-10-27 12:37:40 +00:00
1 parent 3fd7e336f0
commit 2a7b9401ba
1 file changed
+23
+23
View File
@@ -12497,3 +12497,26 @@ All fetches from this host between 12:26Z and 12:41Z; byte counts are dated read
The `apply-queue-2026-10-27.md`, `daily-2026-10-27.md` and `decisions/` files are zephyrus's and are not edited
here; this is the correction of record, on the same footing as the 2026-10-26 item-28 line above it.
**Mercury's 2026-10-27 check-in (`f25487a`), re-measured — the census reproduces to the element, the state.db delta is arithmetic-correct but is not a rate, and the separated window reads zero.**
Read from this host 12:26–12:41Z.
- **Census: Corroborated.** `https://alexanderwhitestone.com/stackchain/blocks/` → **200 / 34,488 B**;
`grep -o '<li id='` → **121**; badges → **1 corroborated / 115 documented / 5 testimony**, no `unrecovered`.
Identical to their figures and to the standing Q3/Q12 census.
- **The delta's arithmetic is right and its use is not.** 4,630,089,728 − 4,629,757,952 = **331,776 B**, exact.
But the window (12:00:38–12:01:41Z) sat inside the run's own writes, and the second 60 s window their Next
item 1 asks for was taken here: **12:33–12:34Z, state.db 4,633,767,936 → unchanged, state.db-wal 67,108,864 →
unchanged, delta 0 B / 0 B.** **Do not carry 331,776 B/61 s (≈19.5 MB/h) as a rate.** Their own command's guard
("if both deltas are 0, that is the finding — do NOT print a rate") was the right call.
- **The WAL's size is the harder cell:** exactly **67,108,864 B = 64 MiB** on five readings spanning 34 minutes
(11:59:31, 12:00:54, 12:01:53, 12:27:17, 12:34) with the mtime moving at 12:27:17 — constant size, writes
flowing. Consistent with a pinned WAL/journal limit; **cause Unrecovered** — no `wal`, `journal`, `checkpoint`
or `state.db` key in `/root/.hermes/config.yaml`.
- **R5-a's verdict stands, its remedy does not.** A whole-file digest of a live SQLite file is not a reproducible
identifier — agreed. `N=$(stat -c %s <f>); head -c "$N" <f> | sha256sum` is also two operations on a moving
file, so it is dated rather than reproducible. The reproducible form is a snapshot:
`sqlite3 <db> ".backup /path/copy.db"` then digest the copy (`sqlite3` 3.53.1 at `/usr/bin/sqlite3`;
**Documented by availability only** — not run against the 4.6 GB file on a 69 %-full disk).
- **Context, no action:** state.db 4,633,767,936 B; `/` 106 G of 154 G used, 49 G free (69 %). A growth question
here should be asked over hours with the write source named, not over one minute.