drill R-201: prepared and HALTED before the wipe — a mandatory data directory was missing from the off-site snapshot while the run said ok (R-203)

STATUS.md

@@ -46,6 +46,16 @@ Proven end to end on real hardware.
   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)*
+- **A backup reported success while leaving out a folder the customer was told is protected.** Found
+  this evening on the HP machine, while setting up the wipe-and-restore proof. We deployed an app whose
+  book folder is declared *mandatory* — the strongest protection class — put a marked file in it, and
+  ran an off-site backup. **The backup said OK. Three snapshots. The folder was not in any of them.**
+  The machine knew: one warning line inside the container says the folder was skipped. Nothing else
+  does — not the card, not the counters, not the hub, not you. This is the same shape as everything
+  else we have been fixing this month: *a path the customer thinks is protected is not in the copy.*
+  It is the reason the proof stopped before the wipe — wiping would have destroyed the marked file and
+  proven nothing. **The two apps that were already backing up off-site are unaffected** — they declare
+  no such folders. *(R-203)*
 - **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
@@ -94,10 +104,9 @@ Proven end to end on real hardware.
 
 ## What we're working on
 
-- **Now:** the proof exercise — wipe a demo machine and recover it with a saved recovery code. It is
-  designed, and it is now a much better bet than it was this morning: the first half of the path was
-  walked live today, so if the drill fails we will know *which* step failed instead of just "recovery
-  did not work". Waiting on your go-ahead. Both honesty fixes shipped today: a changed backup key now
+- **Now:** fixing the folder-left-out-of-the-backup problem above. The wipe-and-restore proof is
+  **staged and waiting on it** — the machine, the code, the working off-site store, the app and the
+  marked file are all in place; only the missing folder blocks it. Nothing was wiped. Both honesty fixes shipped today: a changed backup key now
   raises an alarm on the day, and the email that stated the opposite of what it measured now describes
   what it actually saw.
 - **Also tomorrow:** confirming what the 04:15 off-site run does on both machines. We expect it to
@@ -149,6 +158,12 @@ Proven end to end on real hardware.
 
 ## Changed since last update
 
+- **2026-08-04 (late)** — Set up the wipe-and-restore proof on the HP machine and **stopped before the
+  wipe**: a folder marked as protected was missing from the off-site backup while the backup reported
+  success. Three things were proved on the way, all firsts: a rebuilt machine's off-site backup now
+  **refuses and says so** instead of quietly starting over; the "start a new store" repair works and
+  keeps the old data aside; and the HP machine's pre-3-August history is gone for good — its key was
+  destroyed four hours before the fix that would have kept it. *(R-203, R-201, R-193)*
 - **2026-08-04 (evening)** — **Proved the backup key comes back.** A demo machine fetched its own
   sealed package, opened it with the saved recovery code, and produced a key identical to the one it
   uses. A wrong code was refused and wrote nothing. The recovery code left no trace anywhere on the