docs: CAMPAIGN-11 — the journey FAILED, R-198's retention PROVEN, six findings fixed

Registers and evidence for the campaign and its fix pass.

OPEN-ITEMS: R-214..R-223. Six SHIPPED (R-215/216/217/218/219/222); three deliberately
still open and each blocks a real flow (R-214 console banner, R-220 drives unenrollable
after a rebuild, R-221 a rebuilt box cannot run the escrow ceremony); R-223 minted and
WAITING-ON-OPERATOR (vouch agent 0.125.0). R-213 and R-202 untouched.

Capability map: a new row for the customer's UNAIDED journey, recorded FAILED and staying
failed until a re-walk passes — fixes are not a journey. The existing rebuild row is
corrected where it said R-198's retention was unit-proven only: it was proven in production
on the first supersession since the fix, identity_blob retained at 572 B byte-length exact.

CLAUDE.md comment-vs-code table: eighth entry — ResolveManagedFloor, the first where the
false invariant was a GUARD rather than a comment alone.

STATUS: the headline is now "the backup promise is proved, the recovery journey is not",
and the one thing waiting on the operator.

STATUS.md

@@ -15,41 +15,46 @@ 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.
 
-**And the whole backup promise is now proved.** On 4 August we destroyed a machine on purpose and
-deleted a 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; and the file was restored **byte for byte identical**. *(R-201)*
+**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)*
 
 ## What's broken
 
-- **A customer can now get their backups open on their own — but not yet put the files back.** Every
-  step from a rebuilt machine to an open backup store is done, and today the last piece landed: a
-  **full screen** meets the owner of a rebuilt machine, explains that the backups are still there,
-  says plainly that **nobody can replace a lost recovery code**, takes the code, and shows what is in
-  the store — which apps, from when, how big. Nothing needs you, and nothing needs a command line.
-  **What it deliberately does not do is put files back.** That is per-app, in the backups area, and
-  the piece that would guide it — showing what would change before anything is overwritten — is not
-  built yet. *(R-193 closed; the put-back is R-213)*
-- **Two things still owed as proof.** The final unlock has never been done with a **correct** code
-  through the new screen: no recovery code was kept for the N100 machine's orphaned history, and the
-  HP machine's is in your hands, not ours — so the live test ran the whole chain and stopped at the
-  last step. **And the whole journey has not been re-run end to end since these fixes** — the pieces
-  are proved one at a time, not as a single walk. That re-run is one more drill. *(R-201)*
+- **A machine installed today would tell its owner their correct recovery code is wrong.** The
+  recovery screen needs a newer in-house service than a new machine is given; when it asked and got
+  nothing, it blamed the customer's typing. **We fixed the lie today** — it now says plainly that the
+  *machine* cannot do this yet, and never accuses anyone. **It still needs one click from you to
+  actually work on new machines** (below). *(R-216, R-223)*
+- **Three things a rebuilt machine still cannot do by itself.** Its owner cannot re-attach their own
+  drives, so no app can be put back on its data; it cannot create a new recovery code at all; and the
+  screen at the machine itself never stops showing a stale pairing code. Each is understood, measured
+  and written down — none is fixed yet. *(R-220, R-221, R-214)*
 - **Rebuilding a machine still throws away its off-site backup HISTORY.** The machine invents the key
-  that encrypts its own off-site backups, and a rebuilt machine invents a brand-new one. Both demo
-  machines did this on 3–4 August — 51 backups (~1.2 GB) between them. The old key now survives the
-  recovery ceremony, and a changed key now raises an alarm the same day, but **the rebuild itself
-  still starts a fresh history**. *(R-193)*
-- **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. That is true for
-  machines that re-seal from now on and **false for anything already orphaned** — and the machine
-  cannot tell which case it is in. We deliberately did **not** patch the sentence: a conditional
-  promise that can still be wrong is worse there than a vague one. *(R-202)*
-- **The off-site copy can be erased by the machine that made it.** The credential that writes it can
-  also delete it. A daily snapshot is armed as a stopgap. *(R-95, R-87)*
+  that encrypts its own off-site backups, and a rebuilt machine invents a new one. **The good news:
+  the old key really is kept now — we proved it on a real machine today, for the first time**, and a
+  changed key raises an alarm the same day. *(R-193, R-198)*
+- **The kept older backups cannot be opened yet.** We keep the previous sealed package, and there is
+  no way to open it. A customer holding exactly the right code for it used to be told they had
+  mistyped; today the screen names the situation honestly instead — but it still cannot open it, and
+  it does not pretend otherwise. *(R-222, R-202)*
+- **The off-site copy can be erased by the machine that made it.** A daily snapshot is armed as a
+  stopgap. *(R-95, R-87)*
 
 ## What shipped recently
 
+- **2026-08-05 (evening)** — **Four sentences where there was one, and none of them blames you.**
+  "We did not accept your recovery code" used to appear when the code was wrong, when the machine
+  could not ask, when the store could not be read, and when the customer held the code for an older
+  backup we still keep. Only the first is the customer's doing. Also today: succeeding at recovery no
+  longer switches off the machine's own request for the thing it still needs; the screen now finishes
+  the job and shows what is in the backups instead of promising a list it could never produce; and the
+  recovery page can no longer be reached on a machine that never had backups.
+  *(R-216, R-217, R-218, R-219, R-222, R-215)*
+
 - **2026-08-05** — **The recovery screen: a customer whose machine was rebuilt is now told, and shown
   how.** Until today they had everything needed to get their data back and no way to find out — the
   only route was a command line. The screen unlocks the backups and lists what is in them; it does
@@ -113,6 +118,14 @@ over; and the file was restored **byte for byte identical**. *(R-201)*
 
 ## Waiting on you
 
+- **One click, and it is the most valuable one available: approve host-service version 0.125.0 for new
+  machines.** Hub → Configuration → Day-0 artifacts → agent. Today new machines get 0.120.0, which
+  **cannot** open a recovery package — and a reinstall actively puts the older one back over a machine
+  we fixed by hand, so every rebuild re-breaks the very thing a rebuild needs. 0.125.0 has run on both
+  demo machines since 4 August and through the entire campaign. **Until you do this, new machines are
+  correctly held back rather than lied to — which is better, but the feature does not work for them.**
+  *(R-223)*
+
 - **One thing to read after the machine next restarts — and nothing to do until then.** You told me
   not to restart DooPlex, so I did not, and the move to the second SSD has therefore never been
   through a restart. It works right now and nothing was lost, but a restart is the one test that