R-201 night run: the off-site key IS recoverable after a real rebuild (proven); the verdict is blocked by R-204

STATUS.md

@@ -36,25 +36,21 @@ 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)*
-- *(largely fixed 4 Aug)* ~~Nothing in the recovery path has ever been performed.~~ **The key now
-  demonstrably comes back — measured on a real machine this evening.** demo-felhom fetched its own
-  sealed package from the hub with its own credential, opened it with the recovery code you saved, and
-  the backup key that came out was **identical, character for character, to the one the machine is
-  using** — and to the fingerprint the hub had recorded separately. Three independent sources agreeing.
-  A deliberately wrong code, tried five minutes earlier, was refused outright and wrote nothing.
-  **What is still NOT done, and it is the half that matters to a customer:** nothing yet *puts the
-  recovered key back*, reopens the old backup store with it, or **restores a single file**. Today
-  proves the key survives and returns; it does not prove the backups do. *(R-199 closed; R-200 half;
-  R-201 open)*
-- *(fixed 4 Aug)* ~~A backup reported success while leaving out a folder the customer was told is
-  protected.~~ **Both halves fixed the same day.** The app was writing to one folder and the backup was
-  looking in another — one directory apart, on machines whose apps live on the system disk. They now
-  resolve to the same place, from a single piece of code instead of the three near-copies that had
-  quietly drifted. **And a backup that cannot capture a folder marked essential no longer reports
-  success**: it reports *Hiányos* (incomplete), names the app and the folders, and tells you — while
-  still recording what it genuinely did capture, because half a backup is not no backup. Proved on the
-  HP machine by listing the backup's own contents and finding the marked file there by name and size —
-  not by trusting a green tick. *(R-203)*
+- **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)*
 - **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
@@ -103,7 +99,10 @@ Proven end to end on real hardware.
 
 ## What we're working on
 
-- **Now:** the wipe-and-restore proof, which is **unblocked and staged**. The marked file now lands in
+- **Now:** finishing the proof — it is about five minutes with you present. 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 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
@@ -158,7 +157,12 @@ Proven end to end on real hardware.
 
 ## Changed since last update
 
-- **2026-08-04 (latest)** — **Fixed the folder-left-out-of-the-backup problem, both halves.** The app
+- **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 (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
   marked file. The wipe-and-restore proof is unblocked. *(R-203, R-201)*