chaos night: R-550 corrected - I guessed four endpoints and all four were wrong

The row first claimed a restore leaves no record anywhere, citing four status
endpoints that 404'd. All four were paths I guessed. The real route, read out
of the restore page's own JavaScript, is /api/backup/restore-status and it
exists.

The corrected finding is narrower and better: the endpoint answers with the Go
zero value (started_at 0001-01-01T00:00:00Z) and carries no 'last' field at
all, while the page's own script renders '<operation> sikertelen.' from
st.last.message. The restore record is in-memory only and does not survive the
machine stopping - exactly the case a hard reset creates.

The original wording is left visible in the audit with the correction beside
it; the register row is corrected in place because a register must be accurate.

The reusable lesson: I found the real routes by asking the controller for its
own rendered links. Guessing produced four confident 404s that I then reported
as a property of the product.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/audits/DRILL-chaos-night-2026-09-17.md

@@ -448,6 +448,18 @@ in the real data directory, there is no restore, lock or state file anywhere —
 was modified in the reset window**. An interrupted restore and a restore that never happened are
 indistinguishable, to the customer and to me.
 
+**CORRECTION, 00:24Z — the paragraph above is wrong and stays visible so the correction is too.**
+The four endpoints I called were four I **guessed**, and all four were wrong. The real route, read
+out of the restore page's own JavaScript, is **`/api/backup/restore-status`**, and it exists:
+`{"ok":true,"data":{"running":false,"started_at":"0001-01-01T00:00:00Z"}}`. So a restore status
+surface **does** exist. What is true — and is the better finding — is that after the reboot it is
+**blank**: `started_at` is the Go zero value, and the payload carries no `last` field at all, while
+the page's own script renders „<operation> sikertelen." from `st.last.message`. **The restore record
+is in-memory only and does not survive the machine stopping** — precisely the case a hard reset
+creates, and precisely when a household would want to be told. The register row is corrected to say
+that instead. I found the real routes by asking the controller for its own rendered links, which is
+what I should have done before filing anything.
+
 **The limit of that measurement, stated rather than glossed.** Only four seconds elapsed, so the
 restore may have finished or may never have written a byte — and I cannot tell, because the
 controller's log stream holds **zero lines before 23:28:00Z** (a reset starts it fresh) and the debug

documentation/audits/evidence-chaos-night-2026-09-17/round-10.txt

@@ -85,3 +85,33 @@ that holds regardless of how far the restore got.
    vanishes on reboot. It was therefore ABSENT from 23:26:12Z. It is now a file-backed, ENABLED unit
    (verified: active + enabled, MainPID cmdline "/bin/bash /root/diskguard.sh", 0 kills, 7556 MB free)
    and its script is copied off the box into this folder, which had also never been done (R-320).
+
+## CORRECTION TO THIS ROUND'S CENTRAL CLAIM, 2026-09-17T00:24Z — I WAS WRONG
+Above I wrote that four candidate status endpoints all 404 and that "there is no restore history
+surface of any kind". That was built on FOUR PATHS I GUESSED, and all four were wrong. The real
+route, taken from the restore page's own JavaScript rather than from my imagination, is:
+    /api/backup/restore-status
+It exists, it answers, and this is what it returns now:
+    {"ok":true,"data":{"running":false,"started_at":"0001-01-01T00:00:00Z"}}
+
+So the corrected finding is NARROWER and better than the one I filed:
+  * a restore status surface DOES exist;
+  * after the reboot it is EMPTY - `started_at` is the Go zero value 0001-01-01T00:00:00Z;
+  * the payload carries no `last` field at all, yet the page's own script reads `st.last.op` and
+    `st.last.message` to render "<operation> sikertelen." So there is a "last operation" branch in
+    the UI with nothing to populate it after a restart.
+The record is therefore IN-MEMORY ONLY and does not survive the machine stopping - which is exactly
+the case a hard reset creates, and exactly when a customer would most want to know.
+
+### The honest limit is unchanged, and now cuts both ways
+Only four seconds elapsed. `started_at` may be zero because the restore never really began, not
+because the reboot erased it. I cannot separate those, because the pre-reset log is unrecoverable.
+What IS certain: the surface exists, it is blank now, and nothing anywhere tells the customer that a
+restore they started did not finish.
+
+### How the error happened, because that is the reusable part
+I searched for the page at `/apps/uptime-kuma` and guessed API paths by pattern. The controller's
+actual routes are `/backups`, `/backups/remote`, `/backups/restore` and `/stacks/<name>/backup`.
+I found them in the end by asking the controller for its OWN rendered links instead of guessing -
+which is what I should have done first. Guessing produced four confident 404s that I then reported
+as a property of the product.