final walk COMPLETE — data PASS, journey FAIL; R-241 filed

THE DATA: PASS. All three sentinels byte-identical out of snapshot f5c53b03, including the 12 MB binary and the accented Hungarian filename whose NAME BYTES are identical too. Disk -> restic -> SFTP -> Storage Box -> rebuilt machine -> disk, intact. THE JOURNEY: FAIL, and further from the line than the previous walk. The claim worked first try (302 in 0.164s). Then: / lands on the launcher with no recovery pointer, /recovery 302s away, and the remote page offers to CREATE a new recovery code — which would orphan the history the customer's code protects. There is no field anywhere to enter the code they hold. The operator's documented remedy also refuses, correctly and fail-closed. Recovery needed three guest command lines. R-241 — and the cause is a success this same walk proved six hours earlier. OffsiteRecoveryOffer() shows the screen only when (a) there is NO repository password (pristine rebuild) or (b) one exists but the history will not open under it. Overnight the credential self-heal collected the staged credential and applied the tier, writing a FRESH key at 03:18Z — so (a) is false; and (b) is unreachable because orphan detection needs a run, and runs are blocked by escrow_state=pending. The gap is self-locking. Measured keys: on-disk 9b4a9a9d... vs recovered-from-R 30ef574f... This is R-218's shape one level up: succeeding at the self-heal stopped the box OFFERING the recovery it still needed. Registers: R-201 moved to its outcome; R-241 filed; capability map's recovery row stays FAIL with both halves and the cause named; STATUS rewritten for the operator. Highest ID R-238 -> R-241. The venue is left with the recovered key in place and the self-heal key moved aside, never deleted. Teardown still owed.
2026-08-07 06:45:36 +02:00
parent 1ff6f8f8e0
commit 2228c0bff6
4 changed files with 102 additions and 9 deletions
@@ -1,6 +1,6 @@
 # STATUS — what works, what's broken, what's next

-**Updated 2026-08-06.**
+**Updated 2026-08-07.**

 > **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority on open work; this
 > page restates part of it in plain words, and **nothing may exist only here**. **Not `CONTEXT.md`**,
@@ -15,12 +15,23 @@ who sets their own password. They install apps from a catalogue of fifty-three,
 home network, and open apps from a launcher or a shared link. Backups run on their own to three
 places — the machine's drive, a second drive, and an encrypted off-site copy.

-**The backup promise is proved. The recovery JOURNEY is not.** On 5 August we built a brand-new
-machine from the published disc, gave it three marked files, destroyed it, and tried to get them back
-**the way a household would** — no shortcuts, no command line. The files came back **byte for byte
-identical**, all three, including one with Hungarian accents in its name. But **the journey needed us
-four times**, and the very first thing the machine did was tell the customer their correct recovery
-code was wrong. *(CAMPAIGN 11)*
+**The backup promise is proved again. The recovery JOURNEY still is not — and last night it got
+worse before it gets better.** On 6–7 August we built a brand-new machine from the published disc,
+gave it three marked files, left it alone through a full night's scheduled work, destroyed it, and
+rebuilt it. **The files came back byte for byte identical**, all three, including one with Hungarian
+accents in its name. **But the household had no way to ask for them.** The screen that takes their
+recovery code had switched itself off, and the backup page offered to make them a *new* code — which
+would have locked the old backups away for good. There was no box to type their code into at all.
+
+**The cause is a success.** A repair that runs on its own — and which this same night proved working
+beautifully, with nobody touching anything — hands the machine a fresh key. Holding that key makes the
+machine think it no longer needs rescuing. It is the same mistake the system already fixed once, one
+level higher up. *(R-241)*
+
+**And separately: today's machines do not yet have last week's fixes.** A machine installed tonight
+still gets the older in-house service, so two defects we fixed and closed are still live for a new
+customer. The code is right; it has not been packaged and approved yet. *(R-239)*
+

 ## What's broken

@@ -295,3 +295,83 @@ with **zero human action, on a box that has not even been claimed yet**:
 **That is R-218's consume half, R-236's withdrawal, and the previous walk's dead end 1, all settled by
 one unattended observation.** By the time the operator claims this machine in the morning, its
 off-site tier is already up — which is exactly the property the recovery journey needed and never had.
+
+---
+
+# THE MORNING REMAINDER, AND THE VERDICT
+
+| # | step | result |
+|---|---|---|
+| 1 | claim with the emailed code | **worked FIRST TRY** — 302 in 0.164 s, accents intact (md5 identical source→box) |
+| 2 | log in | landed on **„Indítópult"** — **the recovery screen did NOT appear**, and `/recovery` **302s away** |
+| 3 | read the screen as a customer | there is nothing to read: no recovery pointer anywhere on the landing page |
+| 4 | enter the recovery code | **impossible through the UI — there is no field to enter it in** |
+| 5 | read the listing | not reachable by a customer |
+| 6 | restore the sentinels | **byte-identical — but only via an operator command line** |
+
+## The verdict, both halves separately
+
+### THE DATA: **PASS**
+
+All three sentinels came back **byte-identical**, out of snapshot `f5c53b03`, under the key recovered
+from the sealed package with R:
+
+```
+863fa61c091c64488d8224b12f3915bfe264c46f9cad3d3d874b2ce725a1e5ee  FINALWALK-SENTINEL-A.txt
+28630aa93119af0790b749671ef3896dbab88f8d239da8313ef5631fa068efda  FINALWALK-SENTINEL-C-12MB.bin
+b56668663035a332ae9b8a77b5847c8310c7ff48c5c2068114060561389ccf23  FINALWALK-őrszem-ékezetes-árvíztűrő.txt
+name hex: 46494e414c57414c4b2d c591 72737a656d2d c3a9 6b657a657465732d c3a1 7276 c3ad 7a74 c5b1 72 c591 2e747874
+```
+
+The accented filename's **bytes** are identical too. The backup promise holds: disk → restic → SFTP →
+Storage Box → rebuilt machine → disk, intact.
+
+### THE JOURNEY: **FAIL — and further from passing than the last walk**
+
+**The customer has no route to their data at all.** Not a slow one, not a confusing one — none.
+
+- `/` lands on „Indítópult" with **no recovery pointer**.
+- `/recovery` **302s away** — the screen has retired itself.
+- `/backups/remote` says **„Helyreállítási kód szükséges … Helyreállítási kód létrehozása"** — it
+  offers to **create a NEW code**, which would mint a new key and orphan the very backups R protects.
+- **Even the operator's documented remedy refuses**: `--recover-offsite-install` returned
+  *„[REFUSED] a DIFFERENT repository password is already present… which history to keep is not a
+  decision this command may take. Nothing written."* — correct, fail-closed, and a dead end.
+
+The only way through was to move the fresh key aside by hand and re-run the install. That is three
+guest command lines, and it is what the walk exists to measure the absence of.
+
+## WHY — and it is the success I praised six hours earlier
+
+`OffsiteRecoveryOffer()` offers the screen on exactly two conditions: **(a)** no repository password at
+all — the pristine rebuilt box — or **(b)** a password exists but the history will not open under it
+(`OffboxOrphaned()`).
+
+Overnight, unaided and exactly as designed, the credential chain **gave this box a fresh repository
+password** at 03:18Z. That made **(a) false**. And **(b)** is false too, because orphan detection only
+fires when a run tries the repo — and runs are blocked by `escrow_state: pending`.
+
+**The box sits in the gap between the two conditions, and the gap is self-locking:** it cannot detect
+the orphan without running, it cannot run without escrow, and it cannot escrow without minting a new
+code that destroys what R protects.
+
+Measured, not deduced — the two keys:
+
+```
+on-disk (self-heal, 03:18Z) : 9b4a9a9dcec7898e7544f35b18470aac77c3d9064e5d3a302897617fa62edd65
+recovered from R            : 30ef574fe492a43f89bf1a5071c44e89f51c44c6b08ebcb184b320a2634fad75
+```
+
+**This is R-218's shape one level up.** That finding read *"succeeding at recovery stopped the box
+asking for what it still needed."* Here: **succeeding at the credential self-heal stopped the box
+offering the recovery it still needed** — and the self-heal is the very mechanism this same walk
+proved working, six hours earlier, as its best result. Both things are true, and reporting only the
+first would have been the more flattering half of one night.
+
+Filed as **R-241**.
+
+## State the machine is in
+
+The venue is left with the **recovered** key in place (`30ef574f…`) and the self-heal key **moved
+aside, not deleted** (`repo_password.selfheal-aside`). The old repository opens; two snapshots; the
+restored copy sits in the controller container at `/tmp/fwrestore`. Teardown remains owed.