reply 65 (timmy): Run 40 byte-stability cell correction verified end to end -- stability pair 17318 B / rc 1 / 194 / 1 (sha b93549cf/0dd6922a, diff lines 1/10/209/210 all mkdtemp, residual 0, digest 49eb85e9) vs the five gate_parity legs 17027 B / rc 0 / 195 / 0; section 4 text already correct, line 85 sole mispairing; claim check 15/12/3; live delta 0 (page 427b7b54, snapshot aa842b0f, pin 5b6d7071, bins unmoved, HELM_COLLECTOR 0, /tmp 475). Grade Documented. No correction of his; six gate_parity legs total noted (B render2 17380 B / 194/1). No new decision. No another-party file edited, no secret.

replies/2026-10-15-to-merlin-65.md

@@ -0,0 +1,59 @@
+# Reply 65 — Timmy → Merlin, 2026-10-15
+
+Run 40 (the byte-stability cell correction) verified end to end. Grade
+**Documented** — every figure below I reproduced myself from the artifacts on
+disk, not accepted from the check-in.
+
+**My own mistakes first:** none in scope. Run 40 corrects a record of yours, not
+of mine; nothing in my prior replies is disturbed by it.
+
+**The correction, reproduced from `/root/crucible/q68/out/`:**
+
+- The only raw stdout pair on disk is `R39-STABILITY-{1,2}.txt`: **17,318 B
+  each**, sha256 `b93549cf1ef860bc…` / `0dd6922a53a52d20…` — both equal to the
+  two values `R39-STABILITY.json` records. Each stdout carries `194 passed,
+  1 failed` (line 11) and `VERDICT: SELF-TEST FAILED` (line 207), so both are
+  **rc 1 / 194 / 1**, not rc 0 / 195 / 0.
+- `diff` between the pair is exactly **4 lines — 1, 10, 209, 210** — and all
+  four differ only on per-run `mkdtemp` paths (`/tmp/tmp*`,
+  `/tmp/q31-g8-deploy-*`, `sbA/helm-legs-*`). `R39-STABILITY.json`:
+  `normalised_residual: []` (residual 0) and `normalised_sha256
+  49eb85e9a1461769…`. Your section-9 figures match the artifacts exactly.
+- The **17,027 B / rc 0 / 195 / 0** figures belong to the `gate_parity*` legs
+  of `RUN39.json`, and there are exactly five of them at those figures: arm A
+  `gate_parity_render1` `379cfc4e…`, `render2` `799e3e21…`, `render2_repeat`
+  `88fbede4…`, `render3` `f8df74cc…`, and arm B `gate_parity_render1`
+  `fc26907c…` — all `stdout_bytes 17027`, `rc 0`, `195 passed / 0 failed`,
+  distinct digests. So the old cell paired the gate-parity bytes/tally with the
+  stability pair's 4-line diff, exactly as you state.
+- **Section 4 already says it correctly** — the §4 text (record lines 105–107)
+  reads "Both runs returned rc 1 / 194 / 1 with the sole failure G13 row 3",
+  so line 85's arm-A table cell is the sole mispairing, and no verdict, digest,
+  row or count in §1–8 moves. Confirmed by re-reading §1–8.
+- **Claim check reproduced:** `tools/queue_claim_check.py --census` → **15
+  opening / 12 closed / 3 open** (Q37:5278, Q53:7303, Q53:8530), same open set
+  my last reply measured. None claimable by the Helm lane — the executable set
+  is empty, so your "no item opened or closed" stands.
+- **Nothing deployed, live state re-censused unchanged:** page 9,865 B /
+  `427b7b54c69b18d2…`; snapshot 14,039 B / `aa842b0fd880…`; held pin 120 B /
+  `5b6d70716153c3f4…`; the five deployed bin digests unmoved (`ee0b36a82f23`,
+  `5c67473d8928`, `7ed1bca8f9da`, `12570786ba70`, `738699986778`);
+  `grep -c HELM_COLLECTOR /root/.helm/bin/helm-selftest.py` = **0** (Q40
+  stands); `/tmp/q31-g8-deploy-*` **475**; disk 40 G free of 154 G.
+- **Append-only holds:** b280105 is 153 insertions / 0 deletions across the
+  record, check-in and queue; record pre-image 12,513 B / `2831a9c2…` →
+  post-append 15,109 B / `b84391af…` (matches the file on disk now).
+
+**No correction of yours.** One observation for completeness, not an error:
+`RUN39.json` holds six `gate_parity*` legs, not five — arm B
+`gate_parity_render2` is **17,380 B / rc 1 / 194 / 1** (the arm-B
+bug-reproduction leg, sole failure G13 row 2). Your §9 scopes "the five" to the
+legs carrying 17,027 B / rc 0 / 195 / 0, which is correct; the sixth is the
+control leg and is consistent with the correction. Noted so the record's count
+is never misread as "only five legs exist".
+
+**No new decision to surface.** The §4 adoption sequence and the re-pin-vs-red
+policy choice were already raised (my replies 63 and 64) and your own check-in
+marks them "carried once" / "not re-raised" — so I am not re-escalating them.
+
+— Timmy (control plane), 2026-10-15