docs: R-204 items 1 & 3 — CONTEXT, REPORT, README (controller v0.198.0)

CONTEXT.md

@@ -7,7 +7,40 @@
 >
 > Ask Claude Code: "Please update CONTEXT.md with what we did today"
 
-Last updated: 2026-08-02 (v0.190.0 — R-157 A · R-170 · R-171: boot recovery finished)
+Last updated: 2026-08-05 (v0.198.0 — R-204 items 1 & 3: the reset code and the restore scope)
+
+> **2026-08-05 — v0.198.0 (R-204 items 1 & 3).** The 2026-08-04 drill (R-201) passed only because a
+> person was there; four manual interventions stood between a recovered key and a restored file. Two
+> of the three defects are in this repo.
+>
+> **Item 1 — the reset code needed a restart.** `--print-reset-code` is a SEPARATE process; it
+> persisted a new code while the running server kept the old one cached, so the code the customer was
+> told to type was refused until the controller restarted, and nothing said so. `effectiveClaimCode`
+> now calls `settings.ReloadClaimCode()` first. **The settings-vs-config precedence is unchanged** —
+> the defect was freshness, not precedence. **Read-through, not a TTL, and that is the point:** a TTL
+> makes the new code visible AND leaves a window in which the superseded one still works, which is
+> worse than the bug. That is the mutation `TestClaimCode_SupersededByASecondMint_RefusedImmediately`
+> exists to kill, and its red-proof produced exactly *"the SUPERSEDED code was accepted"*. The
+> function now returns an error and **every caller fails closed**; an absent settings file is NOT an
+> error. `ClaimConsumedGeneration` is deliberately NOT re-read — this process is its only writer and
+> re-reading could move it BACKWARDS if a save had failed, resurrecting a consumed code.
+>
+> **Item 3 — the restore's default returned the wrong thing silently.** `mode=unit` restores the
+> recovery unit (definition + config + DB dumps) and not the customer's files. `restoreScratchOutcomeMsg`
+> now names what came back, what did not, and the next step; the wizard's intent card states its scope
+> before the choice. **The size gate is untouched** and pinned unchanged by
+> `TestOffboxRestore_FullPathUnchanged`. **The default stays `unit`** — all three wizard forms set
+> `mode` explicitly, so a change would alter nothing visible while silently changing a mode-less POST.
+>
+> *Live-validated endpoint-level (no browser on DooPlex):* on demo-felhom 9201 with `restarts=0`
+> across both mints, a superseded code returned „Hibás vagy lejárt kód" and the current one was
+> accepted first time; on demo-hp 9201 a `privatebin` unit restore produced the scoped Hungarian
+> outcome and `mode=full` without confirm revealed `full_size=6.8+KB` without restoring anything.
+> demo-hp's drill scratch (`calibre-web`) was not touched.
+>
+> **Item 2 is the hub's** (felhom.eu v0.95.0, R-196). **Item 4 — a rebuilt box cannot obtain an
+> off-site credential unaided — remains OPEN (R-193)** and was deliberately not begun.
+
 
 > **2026-08-02 — v0.190.0 (R-157 mechanism A · R-170 · R-171).** Three items, one live validation
 > cycle, because all three are boot behaviour and all three are proven by hard-resetting the box.