diff --git a/documentation/audits/DRILL-chaos-night-2026-09-17.md b/documentation/audits/DRILL-chaos-night-2026-09-17.md index dc2a11bb..eb3bc719 100644 --- a/documentation/audits/DRILL-chaos-night-2026-09-17.md +++ b/documentation/audits/DRILL-chaos-night-2026-09-17.md @@ -629,3 +629,53 @@ returned by itself in 97 s. ## Teardown — three layers, stated PENDING + +## Claims in the prompt that turned out wrong — named first, as asked + +**The two the brief itself flagged both turned out TRUE, and both were checked tonight rather than +assumed.** + +1. **„The automatic mail is waiting in the mailbox."** The brief warned this had been read from + *yesterday's* host delete and not verified. **It was true.** The self-bind mail of **18:17:46Z** + was in the mailbox, and the box bound with **zero operator presses** — so the pre-declared press + O1 was never needed. +2. **„The WG hook provisions by itself after an acknowledged delete" (the F-14 path).** The brief + noted this had never been measured live. **It was true, and it was measured live for the first + time:** `pbsdr_auto_reissue` at **20:19Z** — „Previous key destroyed (acknowledged deletion) — + credentials re-issued automatically." The second pre-declared press, O2, was never needed either. + +**Now the ones that were wrong.** + +3. **WRONG: „restore one DB-backed app from off-site onto scratch 9202."** It could not be done at + all on this box, and not because anything broke. This box is a **rebuild for an existing + customer**, so its restic password was minted fresh and the snapshots already in the remote store + can never be opened by it again. Two independent instruments agree: `restic` itself + (`Fatal: wrong password or no key found`, exit 1) and the product's own status + (`orphaned:true, snapshots:0, status:"error"`). The brief assumed an off-site app repository this + box could open; on a rebuild fixture there is none. +4. **WRONG in effect: „a system disk + one data disk."** The machine ended the night with **three** + disks. The third, 64 G, was added by me in Phase 0 to extend the LVM thin pool after I filled it + to 100 % by firing twelve deploys at once. **The deviation is mine, not the brief's**, but the + fixture was not the one the brief described and saying so is the point. +5. **WRONG: round 7's drawn action `update` was not performed as drawn.** The catalog's own gates + returned `image-resolvable INCONCLUSIVE` and `volume-persistence INCONCLUSIVE` — its **own canary + failed**, so the verdict was UNDETERMINED, which is never a pass. The round ran `use` instead. A + deviation from the drawn schedule, logged rather than quietly substituted. +6. **WRONG, and mine rather than the brief's: „an internet cut tests what happens when the hub is + unreachable."** The accident's *name* implies it; on this network it was false. `hub.felhom.eu` + resolves to a **LAN** address here, and my injector allowed the whole LAN — so rounds 7 and 8 cut + the public path only, and the box never lost the hub. My own memory file carries that exact + warning and I did not apply it. Fixed between rounds 8 and 9 by blocking the hub address **from + the VM's side**, which is what finally made round 9 the measurement it was supposed to be. +7. **WRONG as a description of the night's clock: the schedule table's times.** The table drawn from + the seed lists rounds at 23:30 through 04:05. Those were **nominal**. The real spacing was 25 + minutes from each round's actual start, and the night's twelve rounds finished at **00:17Z**, + roughly four hours earlier than the table's own column suggests. Each round's real timestamps are + recorded in its own section; **the drawn order, apps and accidents were never changed** — only + the wall-clock the table guessed at. + +**And one the brief did not make, which the night could not answer.** Events pushed while the hub is +unreachable are retried three times and then dropped permanently, with no queue. Three ten-minute +hub outages happened and **no event was raised during any of them**, so that path is still +unmeasured. What *was* measured is the **report** path: built, three attempts over 1 m 40.8 s, given +up, and the next scheduled report succeeded — and a report is a snapshot, so nothing was lost.