the closing verdict, the capability-map row, and the live evidence

The three blockers yesterday's English walk found are closed and each proven on
a live system. The verdict is deliberately 'nothing known now stands in their
way' rather than 'the walk passed': fixes are not a journey, and the hour has
not been re-walked by a stranger on a fresh install.

Also filed: the HP demo box answers on no route this session has (R-601), the
cookie-vs-session language instrument trap that would have had me fix R-598
twice (R-602), and the apostrophe that silently never matches a rendered page
(R-603).

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

documentation/architecture/00-capability-map.md

@@ -219,5 +219,5 @@ likewise silent. Evidence: `audits/DRILL-r361-2026-08-22/evidence/06-part3-decis
 | **The hub reports LOSS OF VISIBILITY into either off-site store (not just how full it is)** | hub **v0.106.0** (R-339) | **IMPLEMENTED — deliberately NOT proven-live** | Both box checkers count consecutive failed fetch windows and emit `pbsdr_box_unreachable` / `offsite_box_unreachable` (severity `warning`) past a default 3 windows (≈30–45 min), each with a paired `*_recovered` all-clear routed via `recoveredPairedDownTypes` — required because the recoveries are severity `info`, which `severityNotifies` drops. Scopes stay customer-less (`pbsdr-box` / `pool-box`) → operator channel only. Fill logic untouched: a degraded read still drives no band transition. Evidence: `internal/monitor/box_reachability_test.go` + the cross-package wiring test in `internal/notify/`, which asserts an actual operator mail rather than a map entry. **Filed BECAUSE of a measured gap**, not a hypothesis: the 2026-08-18 ep0 outage ran 9 h 37 m with the hub silent | **The gap that remains is R-340**, and it is not small: the ep0 read is the `usage` op, which rides the LOCAL API daemon — the daemon that incident explicitly cleared — so this check would have shown GREEN for that entire outage. It closes "ep0 is unreachable as a host"; it does not close what actually happened. **No live or constructed outage has exercised the emit path**, and one cannot be manufactured against ep0 (Tier 2, protected) |
 | Secrets hygiene: bearer in k8s Secret, no secrets in git, single-quote credential store | hub v0.53, conventions | **IMPLEMENTED** | 07-13 closing bundle | |
 | Operator login password changeable from UI | hub v0.54 | **IMPLEMENTED** | 07-13 | |
-| **An ENGLISH-SPEAKING household's first hour: download, install, pair, bind, claim, two apps** | controller **v0.258.0** + hub v0.118.1 + ISO 1.29.0 + the whole catalog | **PROVEN-LIVE, WITH ONE BLOCKER** | `audits/DRILL-first-hour-en-0258-2026-09-20.md` — a fresh install that day, one intervention (R-494), stop rule not reached | **The claim page answers in Hungarian (R-596, P1)** — the one screen between them and their box. Also R-597 (the setup code is three Hungarian words) and R-598 (the Backup page's protection warnings). **Not walked:** the recovery code (needs ep0), backup/restore/remove/power-cut (proven 2026-09-14). **Verdict: not yet ready for an English-speaking tester.** |
+| **An ENGLISH-SPEAKING household's first hour: download, install, pair, bind, claim, two apps** | controller **v0.259.0** + hub **v0.119.0** + ISO 1.29.0 + the whole catalog | **PROVEN-LIVE on 0.258.0 with one blocker; THE BLOCKER IS FIXED AND PROVEN, THE WALK IS NOT REPEATED** | `audits/DRILL-first-hour-en-0258-2026-09-20.md` — a fresh install 2026-09-20, one intervention (R-494), stop rule not reached. Then `audits/i18n-closing-2026-09-21/live/` — the three blockers fixed and each proven on a live box or in the operator's inbox: the claim page answers English through the real cookie path; the Backup page's tier names follow the language; and the setup mail carries **four plain-ASCII English words** where the drill's carried `képző-szkítia-ásatás`, one day apart in the same inbox. | **R-596, R-597 and R-598 are CLOSED.** What this row still does NOT claim: **the fixed journey has not been walked end to end by a stranger on a fresh install.** Three fixes proven at the endpoint are not an hour proven by a person, and this project's own rule is that fixes are not a journey (see the recovery-journey row). **Also not walked:** the recovery code (needs ep0), backup/restore/remove/power-cut (proven 2026-09-14), and the two Backup-page *warnings* themselves — guest 9201 is healthy and a healthy box renders none, so they are covered by handler render tests, not live. **Verdict: nothing known now stands between an English-speaking tester and their box — and that is a different sentence from "the walk passed".** |
 | **A deletion of a customer's off-site history is NOTICED within a day** | hub **v0.111.0** (R-431) | **IMPLEMENTED — not yet PROVEN-LIVE** | 09-01 | `hub/internal/monitor/offsite.go` — third signal beside FILL and STALENESS. **On the hub deliberately:** a detector on the box is one the deletion can silence. Alarms when the reported count falls by more than HALF and by at least 5, guarded by `StatsKnown` (R-331), the declared `State` (R-204) and run success (R-100). **Threshold reasoned, not invented:** over 12 898 reports every decrease lands on ZERO and predates `stats_known`; in the 380-report `stats_known` window there are none. **ACCEPTANCE: 9 009 real points replayed → ZERO alarms** (`offsite_r431_test.go`, fixture committed). **What PROVEN-LIVE would need and this does NOT have:** a real drop observed on a live box producing a real mail — the live firing done at ship time was driven through the hub's own path with synthetic counts, which is an end-to-end delivery proof, not a proof that a genuine deletion is caught. |

documentation/audits/i18n-closing-2026-09-21/live/setup-code-mail.md

@@ -0,0 +1,50 @@
+# Live proof — an English household gets English words (R-597)
+
+**Hub 0.119.0**, deployed 2026-09-21 07:58 UTC. Read from the operator's catch-all inbox.
+Codes are redacted per §9.4; the SHAPE is the evidence and the shape is what was measured.
+
+## The before and after are in the same inbox, one day apart
+
+Same mail, same subject, same template — only the hub version differs.
+
+| when | hub | subject | the code |
+|---|---|---|---|
+| 2026-09-20 16:55 UTC | 0.118.1 | `[Felhom] Your Felhom server is up — setup code` | `Setup code: képző-szkítia-ásatás` — **3 Hungarian words, 5 non-ASCII characters** |
+| 2026-09-21 06:00 UTC | **0.119.0** | `[Felhom] Your Felhom server is up — setup code` | `Setup code: XXXXXX-XXXXXXXX-XXXXXXXXX-XXXXXXXXX` — **4 words, all plain lower-case ASCII** |
+
+The 2026-09-20 line is the actual code the drill received. It is quoted because it is already in
+`audits/DRILL-first-hour-en-0258-2026-09-20.md`, it is long expired, and its customer is deleted —
+it is the defect, not a secret. Today's is redacted because it is live at the moment of writing.
+
+## The owner passphrase, read from the hub's own store
+
+Shape only — never the value:
+
+| customer | language | words | all ASCII lower-case |
+|---|---|---|---|
+| `demo-felhom` | `hu` | **5** | **no** (accented, as it always was) |
+| `i18n-en-0921` | `en` | **6** | **yes** |
+
+Six English words = 77.5 bits, against the Hungarian five words' 74.3. The English code is longer
+**and stronger**, which is the rule the entropy test pins.
+
+## The venue
+
+A scratch customer `i18n-en-0921` was created on the hub with `language=en` and the operator's own
+address, its claim code re-sent by the operator button, and the customer **deleted afterwards**.
+No existing customer was touched: `demo-felhom` and `peti-felhom` stay `hu`, and `peti-felhom` is a
+real person's box.
+
+**This is a deviation from the task, which said to use "the demo customer (`en`)".** There is no
+English customer on this hub — all five are `hu` — so there was nothing to request a reset for. A
+scratch customer is the smallest thing that proves the deployed binary actually picks the English
+list, which is what the live step is for.
+
+## One thing this run confirmed by accident
+
+The `claim_lockout` event raised by the earlier claim-page probe arrived at the **operator** address
+in **Hungarian** („Túl sok hibás beállító kód — a beállító oldal 15 percre zárolva"). That is
+correct and deliberate: the operator tier is Hungarian by design (10-localisation.md ruling 1), and
+the customer-facing half of that same event is `mail.event.claim_lockout`, which the hub has carried
+in both languages since 0.118.0. The controller's sentence is **wire copy**, not customer copy —
+which is why R-596 left `claim.go` L563 alone.