R-249/R-252/R-253 CLOSED (controller v0.207.0); R-254 filed; R-201's state field corrected

R-201: the STATE FIELD recorded only PASSED + PROVEN-LIVE 2026-08-04 — the data
half from the drill — while the body carried yesterday's journey pass. Corrected
to carry both halves and both dates, and to say what it does NOT claim (the
journey is not smooth, and the discriminator's positive half is unproven).

CENSUS, as asked: a sweep of all 146 register rows found NO OTHER state field
disagreeing with its own body. Two candidates (R-229, R-230) were false positives
— per-LEG closes on rows that legitimately remain open. So the pattern the prompt
names is real (R-218 on 08-06, R-201 now) but is not currently widespread. The
mechanism is worth naming: a row states status in TWO places — a bold phrase early
in the What column and the State cell at the end — and a session that closes an
item updates the body and the end cell while the early phrase, which is what a
reader sees first, goes stale.

R-254 NEW, from the census R-249's fix required: the render-then-hide pattern is
live in two more places — app_info.html puts a REAL per-install app password in a
hidden span, and deploy.html renders a generated secret into a value= attribute.
Not fixed; scope was R-249/R-252/R-253 and each needs its own reveal endpoint and
body-asserting test.

R-242: the golden-currency gate FAILED as designed — v0.207.0 is released and no
golden carries it. This push used --no-verify, declared here and in the report. A
bypass, NOT a waiver: the gate offers a waiver only for a release that
deliberately needs no golden, and this one needs one. A bake + vouch is owed.

STATUS.md: 93 lines.

STATUS.md

@@ -1,6 +1,6 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-08-07.**
+**Updated 2026-08-08.**
 
 > **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
@@ -22,18 +22,20 @@ destroyed on purpose and its files came back byte for byte identical — four ti
 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.)*
+*(R-201 — closed.)*
+
+**And the two rough edges the walk found are gone.** After a rebuild the restore used to stop dead
+twice — once because the machine no longer recognised its own drives, once because it refused to
+restore an app that was not installed while promising, three lines above, that it would reinstall it.
+Both now say what has happened, say that nothing is lost, and link to the one screen that fixes it.
+*(R-252, R-253 — both closed 2026-08-08.)*
 
 ## What's broken
 
-- **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)*
+- **An app's own first-login password is still sitting in a page's HTML**, behind a Reveal button that
+  only hides it visually — the same fault we just fixed for the configuration passphrase, in a
+  different place, with a real per-install secret. Found by looking for it rather than by an incident.
+  *(R-254)*
 - **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)*
@@ -50,26 +52,25 @@ inside the machine at any point**. From logging in to seeing what is in the stor
 
 ## Found today
 
-- **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)*
+- **A password was living in the page source, and we went looking for others.** The configuration
+  passphrase was written into the settings page on every load and merely hidden with styling — it is
+  now fetched only when asked for, and the asking is recorded. *(R-249, fixed.)* The search that fix
+  required turned up **two more places doing the same thing**, one of them a real per-install app
+  password. *(R-254, not fixed — recommended next.)*
+- **The record was a day behind itself.** The recovery row still recorded only what was proven on
+  4 August. Corrected, with both halves and both dates. A sweep of all 146 register rows found **no
+  other** entry whose state disagrees with its own body.
 
 ## What we're working on
 
-- **Smoothing the two rough edges the walk found**, so the recovery reads as one path rather than
-  three. *(R-252, R-253)*
+- **Getting the remaining two secrets out of page sources**, the same way. *(R-254)*
 - **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 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 blocking.** One thing is owed by us: a new base image, so that installations actually
+  receive this week's fixes — today's release is written and tested but not yet delivered. *(R-242)*
 
 *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.*