R-201 PASSED: a customer's file survived a machine rebuild and came back byte-identical

STATUS.md

@@ -36,21 +36,19 @@ Proven end to end on real hardware.
   the old backups stay recoverable. Both keys are now kept. **What this cannot undo:** anything
   superseded before today is gone for good, which includes both demo machines' pre-4-August keys — so
   those 51 orphaned backups were beyond reach even if the recovery codes had been kept. *(R-198)*
-- **THE BACKUP KEY COMES BACK AFTER A REBUILD — proved on real hardware last night.** We destroyed the
-  HP machine's controller data on purpose, deleted the marked file from its disk, and then used the
-  recovery code you saved. The key that came out was **identical, character for character**, to the one
-  the machine had been using — and to the fingerprint the hub had recorded separately. It installed
-  cleanly onto the empty machine. Nothing re-sealed itself in the meantime, so the sealed package
-  survived the rebuild untouched. *(R-201)*
-- **But the machine still could not use it, and that is the night's real finding.** Three things stand
-  between a recovered key and a restored file, and each one is now measured rather than guessed:
-  **(1)** a rebuilt machine cannot set up its off-site connection at all — its one-time password was
-  spent by the machine it replaced; **(2)** the fix for that (re-issuing the credential) marks the
-  sealed package "stale" even though the key never changed, and a stale package blocks every off-site
-  backup; **(3)** the only documented way to clear that is to make a new recovery code — **which
-  replaces the sealed package and destroys the key we just recovered.** And before any of it, the
-  rebuilt machine is unclaimed, so nothing on its dashboard responds until the customer claims it
-  again — a step written down nowhere. **The key comes back and cannot be used.** *(R-204)*
+- **IT WORKS. A customer's file survived a machine being destroyed and came back — proved last night on
+  real hardware, end to end.** We wiped the HP machine's controller data on purpose and deleted the
+  marked file from its disk. Using the recovery code you saved: the backup key came back **identical,
+  character for character**; the existing off-site store **opened** rather than starting over (the same
+  three backups, the same 42 026 bytes as before the wipe); and the file was restored **byte for byte
+  identical**. That is the whole backup promise, demonstrated for the first time. *(R-201)*
+- **But a customer could not have done it alone, and that is now the open work.** Getting from "the key
+  is recoverable" to "the file is back" took four steps that appear in no instructions: re-issuing the
+  storage credential; re-claiming the machine (whose local reset-code tool **does not work until the
+  controller is restarted** — two attempts failed before we spotted it); manually clearing a "stale"
+  mark that the re-issue sets even though the key never changed; and choosing the *full* restore,
+  because the default one returns the app's settings and **not** the customer's documents — with
+  nothing saying so. **The capability is real; the experience is not built yet.** *(R-204)*
 - **One screen still tells the customer something we cannot yet promise.** The „elárvult tároló" card
   says the old backups may later be restorable with the matching recovery code. From today that is true
   for machines that re-seal from now on and **false for anything already orphaned** — and the machine
@@ -99,10 +97,11 @@ Proven end to end on real hardware.
 
 ## What we're working on
 
-- **Now:** finishing the proof — it is about five minutes with you present. The HP machine is sitting
+- **Now:** making that journey something a customer can actually follow — the four steps above, worst
+  first: the restore default that silently returns the wrong thing. The HP machine is sitting
   mid-drill with the recovered key already on it; it needs re-claiming and one setting confirmed, then
   the backup runs and the file is restored. **Do not let it make a new recovery code** — that would
-  destroy the key we recovered. Then the deeper fix for the wall above. The marked file now lands in
+ The marked file now lands in
   the off-site backup, so there is finally something to recover. Everything else is already in place on
   the HP machine — the recovery code you saved, a working off-site store, the app and the file. Nothing
   has been wiped; that step waits for your go-ahead at a marked stop point. Both honesty fixes shipped today: a changed backup key now
@@ -157,11 +156,10 @@ Proven end to end on real hardware.
 
 ## Changed since last update
 
-- **2026-08-04 (night)** — **Wiped the HP machine on purpose and got the backup key back with your
-  recovery code — identical, character for character.** First time that has ever been done. The drill
-  then stopped short of restoring the file, at a wall worth more than the last step: the key comes back
-  but cannot be used without an act that destroys it. The machine is up, its apps are serving, and it
-  is five minutes from finished. *(R-201, R-204)*
+- **2026-08-04 (night)** — **The drill PASSED.** We destroyed a machine on purpose and the customer's
+  file came back byte-for-byte identical, using the recovery code you saved. First time the backup
+  story has been proved end to end. It needed four undocumented manual steps to get there, which are
+  now the next piece of work. The machine is up, healthy and re-armed. *(R-201, R-204)*
 - **2026-08-04 (evening)** — **Fixed the folder-left-out-of-the-backup problem, both halves.** The app
   and its backup now look in the same directory, and a backup that misses a folder marked essential
   reports *incomplete* instead of success. Proved by listing the backup's own contents and finding the