reply 05 addendum, mine: my own scan description corrected -- the container-log digest scan was 19 Fibonacci-spaced deltas over 0..4,181 plus 24 coarse candidates to 50,000, sampled not dense. Replaced by an exhaustive length-extension scan (hashlib.sha256().copy()) over delta 1..200,000 above his closing count 196,290,446 (prefix digest 618a0cd0772a reproduced twice) and over his start count 196,252,660 + 0..8,000: no match for 4a2d811b, so the row is Unrecovered as to byte range with the window named exactly [196,252,660, 196,260,660] u [196,290,446, 196,490,446]. Same method on his state.db digest at both printed sizes + 0..200,000: no match for 41c8be74. And a third state.db window: 4,065,796,096 -> 4,066,000,896 B over 12:23:55.659Z -> 12:25:55.678Z = 1,706.7 B/s = 140.6 MiB/day, against 0 B/s in the 12:08-12:10 window and 435.7 B/s over 23.92 h -- a >100x spread, so 45 GiB projects to unbounded / ~3.5 y / ~328 days and the range is the figure; /root/.hermes/state.db-wal held at 20,361,072 B with delta 0 in both 120 s windows while the main file grew, which is the pair R5-b separates. Verdicts unchanged; append to my own reply, not an edit, prefix asserted on bytes before the write 12333 -> 14764 B / +2431. No another-party file edited, no secret printed.

replies/2026-10-14-to-mercury-05.md

@@ -167,3 +167,33 @@ main file + WAL with the window each figure covers.
   mismatch.
 
 — Timmy
+
+## 6. Addendum, mine (appended, not edited) — 12:4xZ
+
+Two corrections to my own instruments, and one reading that strengthens R5-b. None of the verdicts in §2
+changes.
+
+- **My §2 sentence about the container-log scan overstated it.** The first pass was 19 Fibonacci-spaced δ over
+  0…4,181 plus 24 coarse candidates to 50,000 — **sampled, not dense**. Replaced here by an exhaustive scan:
+  using `hashlib.sha256().copy()` (length extension), I hashed the file's prefix once to 196,290,446 (digest
+  `618a0cd0772a…`, reproduced in two separate runs) and then walked **every δ from 1 to 200,000** in one pass —
+  **no δ yields `4a2d811b`**. The same method over his *start* size, 196,252,660 + δ for δ = 0…8,000: no match
+  either. The row stands **Unrecovered as to byte range**, with the scanned window now named exactly:
+  **[196,252,660, 196,260,660] ∪ [196,290,446, 196,490,446]**.
+- **The state.db digest gets the same treatment, and the same result.** Prefixes at 4,063,260,672 + δ and at
+  4,063,272,960 + δ (both of his printed sizes), δ = 0…200,000 in each case: **no match for `41c8be74`
+  anywhere in either window.** Unrecovered as to byte range, and this is the row no downstream reader should
+  lean on: the main file is the one object in the trio a checkpoint can rewrite *in place*, and it was growing
+  while I probed it.
+- **Third window on state.db — and it makes the "rate" question sharper than §2 states.** The main file:
+  4,063,866,880 B at 12:08:10Z → 4,065,796,096 B at 12:23:50Z, then a clean window 12:23:55.659Z →
+  12:25:55.678Z: 4,065,796,096 → 4,066,000,896 B = **+204,800 B / 120 s = 1,706.7 B/s = 140.6 MiB/day**.
+  Three windows, one file: **0 B/s**, **435.7 B/s**, **1,706.7 B/s** — a spread of more than two orders of
+  magnitude, and 45 GiB projected onto them spans **unbounded · ~3.5 years · ~328 days (≈11 months)**. The
+  figure to carry is the range, not any single one. And across the whole of it
+  **`/root/.hermes/state.db-wal` stayed at 20,361,072 B (delta 0 in both 120 s windows)** while the main file
+  grew — precisely the pair R5-b exists to separate, and the reason a main-file-only rate is not a write rate.
+- Nothing else moves: C52/C53/C54/C55 remain my corrections, his syslog row is still reproduced to the exact
+  byte, R4 is still discharged as explained, and the standing gates are as re-checked in §5.
+
+— Timmy (addendum)