R-543 closed: the household is asked for the recovery code (controller v0.245.0)

The tier-3 pause is the zero-knowledge escrow design and is untouched. What was
missing was the ASK, while the backup page promised the copy that had never run.

- VOLUNTEER-first-hour.md: a new step 6, right after the dashboard password and
  before the first app - what the code is, where, write it on PAPER, and that
  Felhom cannot get it back for them. Sections 6..12 renumbered to 7..13.
- day0-install.md A.2b: the operator step for a REBUILT box, which was missing.
  Acknowledged delete -> the hub re-issues by itself; otherwise ONE press of
  "Re-issue PBS credentials" (F-14 ruling 2026-07-13, hub/internal/web/pbsdr.go).
  This is the correction to last night's "zero presses" note.
- 07-backup-architecture.md: 6.1 records tier-3's paused state as a DESIGN, and
  2 records that the household is asked from first login.
- capability map: the first-hour row's last gap closed, with what it still does
  not claim (no volunteer has walked the ask from the written guide).
- register: R-543 CLOSED with the live measurements; R-545 filed (nothing
  un-configures an off-site target). R-511 was already closed yesterday.
- STATUS: the answered publish question removed (1.28.0 is live), readiness yes.
- evidence: red-proofs, the two-box live validation, teardown on three layers,
  and both of my own mistakes in this session.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

STATUS.md

@@ -1,36 +1,39 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-09-16 (evening) — the photos come back, and they open.**
+**Updated 2026-09-16 (late evening) — the box now asks for the recovery code, and the page stops promising a copy that has not run.**
 
-> **Ready for a volunteer: almost — one thing stands in the way, and it is small.** A brand-new box now
-> protects the household's own files: I put five photos in, deleted them the way a child would, and got
-> them back byte-for-byte from the off-site copy. The old route that used to lie now refuses politely
-> and points at the one that works. What is missing: on a new box the off-site copy is switched on but
-> **paused** until the household creates their recovery code, and nothing asks them to do it.
+> **Ready for a volunteer: yes.** The one thing standing in the way this morning is fixed. On a new
+> box the off-site copy is switched on but paused until the household writes down their recovery
+> code — that pause is deliberate and correct, because that code is the only key and we cannot open
+> their copies without it. What was wrong is that nothing asked them. Now every page says so until
+> they do it, and the backup page says „would protect" instead of „protects" while it waits.
 
-**What changed today.** The backup page stops claiming it holds files it does not hold. A restore that
-cannot bring your files back now refuses instead of reporting success — and it no longer wipes the app's
-own wastebasket on the way. „Alkalmazás telepítve" now means installed, not merely started. Every new
-customer gets the off-site copy by default, 100 GB. The off-site server got the one permission it was
-missing, so a rebuilt customer's box can be set up again without hand-work.
+**What changed today (this note).** A reminder bar on every page of the dashboard: „the off-site
+backup is paused until you create your recovery code", with the button that does it. The sentence
+under each app's local backup now tells the truth about the state it is in — protected, waiting, or
+no copy at all — instead of promising the same thing in all three. The first-hour guide asks for the
+code right after the dashboard password and before the first app, and says plainly that we cannot
+get it back for them. The operator step for rebuilding an existing customer's box is written down
+where it was missing: normally nothing to press, but one press when the old box was not deleted
+through the acknowledged flow.
 
-**What I proved on a box that installed itself this evening.** It installed from the new image, showed
-Felhom's own screen with no Proxmox address, registered itself, and **bound with nothing pressed on your
-side** — the connect e-mail it used was the one the system sent itself. It landed on today's golden.
-Then: five photos in, the local backup, the recovery-code ceremony, the off-site copy, the deletion, the
-refusal, the restore, and five photos that open — identical to the originals.
+**What I proved on real boxes.** On a box whose recovery code exists: no bar anywhere, and the page
+says the files are protected. On a box waiting for the code: the bar on every page, an off-site run
+refused with „waiting for the key to be placed in escrow" and no copy written, and an app's row
+reading „would be protected … paused until you create the recovery code". Both boxes were running
+today's build. The throwaway app and the test setup were removed afterwards and checked gone.
 
 **Decisions I took.** None under the unattended rule.
 
 **Needs you.**
-1. **Say yes or no to publishing the new installer image (1.28.0).** It is built and passed every check,
-   and it fixes the screen that kept showing the pairing code after the box was connected. Nothing is
-   published without your word. If you do nothing: new volunteers keep getting the older image, which
-   works but shows that stale screen.
-2. **One small fix before a volunteer: tell the household to create their recovery code.** Until they do,
-   the off-site copy is paused — so „your files are protected" is a promise with a delay in it. I can
-   add the prompt and make the sentence state the real state.
-3. **The slow-crash-loop counter** (yesterday's ruling) is still owed, and is a job for the nightly.
+1. **Nothing blocking.** The installer image you approved is published and live on the download page,
+   and the recovery-code gap is closed. A volunteer can start.
+2. **The slow-crash-loop counter** (the ruling of 2026-09-15) is still owed, and is a job for the
+   nightly. If you do nothing: a box that keeps crashing slowly is still reported as healthy for
+   longer than it should be.
+3. **One small thing worth knowing, not doing:** there is no button that forgets an off-site
+   destination once set — only one that disables it. Written down as a low-priority job. If you do
+   nothing: a household that types the wrong address keeps the old one on the box, switched off.
 
 ---