R-201 CLOSED — the unaided recovery journey passes, both halves, on the fifth walk

Capability map: the unaided-recovery row turns FAILED -> PROVEN-LIVE, scoped, with
what it still does not claim stated in the row itself: shape (c) did not fire
positively (with the mint guard holding there is no local key, so the offer comes
from shape (a)); and 'unaided' here means possible-without-a-shell, not obvious,
because two obstacles are unsignposted.

OPEN-ITEMS: R-201 closed with its evidence. Five new rows R-249..R-253 (the
retrieval passphrase in page HTML; the host-key scan ladder vs AAAA settle; the
listing's per-tag rows; the two unsignposted restore steps). R-243 annotated
rather than re-filed: on a REBUILD offsite_delivery_stuck does not skip, so the
row's gap is narrower than it reads.

STATUS.md: headline changed, and trimmed 97 -> 92 lines rather than extended, per
its own header.

Teardown recorded as OWED with its before-measurements, the stop-and-age gate, and
the positive controls that must survive.

STATUS.md

@@ -1,16 +1,14 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-08-08.**
+**Updated 2026-08-07.**
 
 > **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority; this page restates
 > part of it in plain words, and **nothing may exist only here**. Not `CONTEXT.md`, which is technical
 > state written for Claude Code. **Items, not paragraphs. One screen.** If it does not fit, something
 > belongs in the register instead.
 >
-> *Rebuilt from the register on 2026-08-08. It had reached 258 lines; its "waiting on you" list asked
-> for two things already shipped and carried a stray line reading only "Nothing."; and it mixed the
-> DooPlex infrastructure work in with the product. The old "what shipped recently" log — 100 lines of
-> it — is what the per-repo `CHANGELOG.md` files and the register are for, and is not restated here.*
+> *Rebuilt from the register on 2026-08-07, from 258 lines. The old "what shipped recently" log is what
+> the per-repo `CHANGELOG.md` files and the register are for, and is not restated here.*
 
 ## What works
 
@@ -19,21 +17,31 @@ sets their own password. They install apps from a catalogue of fifty-three, shar
 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.** A machine has been destroyed on purpose and its files came back byte
-for byte identical — three separate times, including a filename with Hungarian accents.
+**The backup promise is proved, and so is getting the data back yourself.** A machine has been
+destroyed on purpose and its files came back byte for byte identical — four times now, including a
+filename with Hungarian accents. On **2026-08-07 the household's own journey passed for the first
+time**: someone with a browser and their recovery code got everything back with **no command line
+inside the machine at any point**. From logging in to seeing what is in the store took **72 seconds**.
+*(R-201 — closed. Two rough edges remain, below.)*
 
 ## What's broken
 
-- **A household still cannot get their own data back unaided.** Every individual link now works; no
-  single walk has completed end to end without someone stepping in. *(R-201)*
+- **The recovery works, but two steps are unsignposted, and one of them the machine gets wrong.** After
+  a rebuild the restore stops with "no data drive available" and never says the drives must be
+  re-attached *(R-252)*; then it refuses because the app is not installed — on a page that says, three
+  lines above, that the restore will reinstall it *(R-253)*. Both are fixable from the dashboard in a
+  couple of minutes. Neither is something a household would work out on its own.
+- **The passphrase that fetches a customer's whole configuration is sitting in the page's HTML**, behind
+  a Reveal button that only hides it visually. Anything that reads the page rather than looking at it
+  gets it, with no record that it was read. *(R-249)*
 - **The machine's own screen keeps telling an already-paired box to pair itself** — 25 minutes after it
   was paired, on a screen that promises it refreshes itself. *(R-214, R-235)*
 - **A rebuilt machine cannot create a new recovery code at all.** *(R-221)*
 - **A backup that covered nothing still calls itself „Sikeres".** The state is honest; the word is not.
   *(R-240)*
-- **A machine waiting for its recovery code raises no alarm to us.** It quietly stops making off-site
-  backups, and three separate safety nets each correctly decide it is not their business. The
-  household can see it; we cannot. *(R-243)*
+- **A machine waiting for its recovery code can stop making off-site backups without alarming us.**
+  Measured on 7 August: after a *rebuild* we ARE told, promptly and correctly. The gap is narrower than
+  it read — it is a machine that reaches the state without a working tier behind it. *(R-243)*
 - **The card offering to reopen set-aside backups promises more than we can deliver** — we keep the old
   sealed package, but nothing can open it. *(R-202)*
 - **Deleting a customer leaves rows behind** on every test machine ever torn down, while reporting a
@@ -42,31 +50,29 @@ for byte identical — three separate times, including a filename with Hungarian
 
 ## Found today
 
-- **A leftover flag had been silently switching off the new recovery detection on one demo machine
-  since 4 August — found, and cleared with your approval.** A Re-issue during the recovery drill set it, using code we removed the next day.
-  **The flag is wrong** — the sealed package does cover the key that machine is using, and the two
-  fingerprints match exactly. Because of it the hub withholds a figure the machine needs, so the
-  machine tells its owner *"create a new recovery code"* — the one act that would put their old backups
-  beyond reach. **A freshly installed machine cannot reach this state**, because nothing has set that
-  flag since 5 August. **Cleared the same day; the machine now compares its key correctly again.** What
-  is still owed is a ruling on the flag itself: nothing sets it, nothing can see it, and it changes
-  what a household is told. *(R-246, R-247, R-248)*
+- **The recovery walk passed** — see above. It also turned up five things: the retrieval passphrase
+  sitting in the page HTML *(R-249)*, a customer create that can fail on a fresh sub-account's DNS and
+  only says "try again" by not saying anything *(R-250)*, a recovery listing that shows the household
+  an "app" they never installed *(R-251)*, and the two unsignposted restore steps *(R-252, R-253)*.
+- **The leftover flag that had been switching off recovery detection on one demo machine since
+  4 August was cleared with your approval**, and the fresh machine built for the walk confirmed it
+  cannot reach that state. Still owed: a ruling on the flag itself — nothing sets it, nothing can see
+  it, and it changes what a household is told. *(R-246, R-247, R-248)*
 
 ## What we're working on
 
-- **The walk that either finishes the arc or says why not.** It needs the base image current (done
-  today) and a machine whose recovery detection is not silently switched off (answered today). *(R-201)*
+- **Smoothing the two rough edges the walk found**, so the recovery reads as one path rather than
+  three. *(R-252, R-253)*
 - **Proving the hub really keeps the old sealed key** when a machine re-seals. Never run outside a
   test; needs a second deliberate wipe and its own session. *(R-198)*
 
 ## Waiting on you
 
-- **Nothing.** The new base image was approved and is live — every future installation now carries
-  this week's fixes. *(R-239, R-242)*
+- **Nothing blocking.** One thing is owed by us, not you: the walk's machine (`walk5`, VM 325) is
+  still standing as the evidence and needs tearing down.
 
-*Nothing else is pending. R-245 — whether an undecided household is auto-abandoned after 30 days — was
-**settled on 7 August** (we do not build it, and the reasoning is recorded). It has been re-filed as a
-decision taken rather than a question sitting in your queue.*
+*R-245 — whether an undecided household is auto-abandoned after 30 days — was settled on 7 August: we
+do not build it, and the reasoning is recorded.*
 
 ## DooPlex infrastructure — separate from the product
 
@@ -80,8 +86,7 @@ being readable.*
   free — clutter, not space. Nothing deleted. *(R-210)*
 - **The hub password needs rotating** — a diagnostic printed it into a session log; nothing suggests
   anyone else saw it. *(R-132)*
-- **One thing to read after DooPlex next restarts.** The move to the second SSD has never been through
-  a reboot; it now writes PASS or FAIL to `/var/log/felhom-store-postboot-check.log` on every start.
-  On PASS, 34 GB comes back. *(R-209a)*
+- **One thing to read after DooPlex next restarts** — the second-SSD move has never survived a reboot;
+  it writes PASS/FAIL to `/var/log/felhom-store-postboot-check.log`. On PASS, 34 GB comes back. *(R-209a)*
 - **Backup scripts on DooPlex are unversioned host state.** *(R-231)*
 - **Instruction-file follow-ups**, each needing a decision rather than an edit. *(R-229, R-230)*