From b9d9d0710a18affdac7431695e2bd4ac97186319 Mon Sep 17 00:00:00 2001 From: Timmy Date: Sun, 11 Oct 2026 14:16:34 +0000 Subject: [PATCH] queue: Q31 addendum 2 -- mtime defect root-caused in restore-mtime.py; dead digest still in the deliverable 1. restore-mtime.py could never hit its own target: it hardcodes datetime(..., 475780) -- microsecond 475780, discarding the original's trailing 303 ns -- and os.utime takes a float, so that resolves to ns-part 475780096, i.e. 207 ns BELOW the true original 475780303. Float precision is secondary; the hardcoded microsecond target is primary. Byte-exact mtime restoration was never achievable as written. 2. Which statements are wrong: the deliverable asserts 475780303Z as the post-restore value in three places (section 0 line 26; the section 3 verify pair at line 163; section 6.1 line 210), while section 7 line 241 says 475780010Z -- which is what the live file actually reads. Section 1 lines 49 and 69 cite 303Z as a PRE-INCIDENT baseline; those are correct readings and are not inconsistencies. 3. The dead digest (701 lines / 28,808 B / 60229227...) is still in recoveries/helm-collector-run.md sections 1, 4 and 7; its blob is unchanged since 300228b 13:31Z. The correction lives only in WORK-QUEUE.md and reply 14. The fix is Merlin's append; the control plane does not edit a counterparty deliverable. 4. The corrected identity is corroborated by construction: applying DIFF.txt (38 lines, +19 -1) to helm-collect-pregate.py yields a file byte-identical to /root/crucible/q31/helm-collect.py (705 / 29,085 / 8a477376...). 5. Writer discipline adopted: two scheduled control-plane jobs push under one git identity (Timmy ) -- today 067cc52 13:45:19Z, then bc4ba2c + 72d51a2 at 13:50:06Z/13:50:11Z, with the digest blocker corrected twice independently. Rule: one correction block per subject per tick, and read the tail for the other writer's coverage before appending. Staggering the two jobs is Alexander's call. --- WORK-QUEUE.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/WORK-QUEUE.md b/WORK-QUEUE.md index 91323d4..21df0e3 100644 --- a/WORK-QUEUE.md +++ b/WORK-QUEUE.md @@ -4201,3 +4201,37 @@ nor edited it, and the corrections below are the ones this tick measured itself. lane's next unit; **Q9** blocked on the audio handover; **Q13** (18 flags) and **Q19** gated on Alexander; **Q26–Q30** gated on the same §4 publish decision, now joined by **Q31**. The executable set is not empty, so **no item was opened this tick**. Nothing new is publishable — the standing public status is unchanged. + +**Q31 addendum 2 — the mtime defect has a root cause in the script, and the deliverable still carries the dead +digest. 2026-10-11 14:15Z (control plane).** One block, one subject, written after reading the tail for this +tick's other writer — the 13:50Z blocks already carry the digest blocker and the "digest read off disk in the +same pass" rule, so this adds only what they do not. + +- **`restore-mtime.py` could never hit its own target.** The script hardcodes + `datetime(2026, 10, 8, 17, 12, 59, 475780)` — microsecond `475780`, which discards the original's trailing + `303 ns` — and `os.utime` takes a float, so that timestamp resolves to ns-part **475780096**, i.e. **207 ns + below** the true original `…475780303`. Float precision is the secondary cause; the hardcoded microsecond + target is the primary one. Any claim of byte-exact *mtime* restoration needs the script fixed first, not the + prose re-worded. +- **Which statements are actually wrong.** The deliverable asserts `…475780303Z` as the post-restore value in + three places — `§0:26`, the `§3` verify pair at `:163` (`mtime_ns …303 → …303` **unchanged**), and `§6.1:210` + — while `§7:241` says `…475780010Z`. The live file reads `…475780010Z` (measured this pass), so the `…303` + claims cannot stand and `§7:241` is the honest one — though its "86 ns above" is wrong in sign and magnitude + (the gap to the original is **−293 ns**, and the gap to the script's own target is −207 ns). `§1:49` and + `§1:69` cite `…303Z` as a **pre-incident baseline**; those are correct readings and should not be counted as + inconsistencies when the addendum is written. +- **The dead digest is still in the artifact.** `recoveries/helm-collector-run.md` (§1, §4, §7) still instructs + adoption at **701 lines / 28,808 B / `60229227…`**; its blob is unchanged since `300228b` 13:31Z. The + correction lives only in `WORK-QUEUE.md` and reply 14, so anyone reading the deliverable alone is one click + from a digest that resolves to no file. The fix is Merlin's append — the control plane does not edit a + counterparty deliverable. +- **The corrected identity is now corroborated by construction, not just by reading.** Applying the record's own + `DIFF.txt` (38 lines, +19 −1) to `helm-collect-pregate.py` yields a file byte-identical to + `/root/crucible/q31/helm-collect.py` — 705 lines / 29,085 B / `8a477376…`. So the identity in addendum 1 is the + gate-carrying artifact by two independent routes. +- **Writer discipline, adopted now.** Two scheduled control-plane jobs push to this repo under one git identity + (`Timmy `): today `067cc52` 13:45:19Z was followed by `bc4ba2c` + `72d51a2` at 13:50:06Z + and 13:50:11Z, and the digest blocker was independently corrected twice. Parallel correction blocks in one + append-only queue are the likeliest way this record corrupts next. **Rule: one correction block per subject + per tick, and read the tail for the other writer's coverage before appending.** Staggering the two jobs is + Alexander's call, not a self-serve change.