felhom.eu/REPORT-i18n-closing.md

REPORT — the last three things between an English household and their box

R-596, R-598 (controller v0.259.0) · R-597 (hub v0.119.0). 2026-09-21. Written as REPORT-<topic>.md because REPORT.md is shared in this repo.

---

1. Claims in the task that turned out wrong — named first

the claim	what is true
"Sixteen Hungarian literals reach the claim page"	Fifteen sites, nine distinct messages (four repeat). One of the fifteen, data["Title"], is DEAD — claim.html is standalone with its own bundle-backed <title>, and .Title is read only by layout.html. Deleted, not translated. L523 (operator stdout) and L563 (the claim_lockout event, whose customer copy the hub already localises) are wire copy and correctly untouched. Fourteen live sites converted.
"backup_handlers.go (12 Hungarian literals)"	Nine are code; three are Hungarian inside comments. backup_target_offer.go's ten is right.
"the recovery code (10 words — find its caller)" in the hub	The hub does not mint it. felhom-agent's internal/escrow does, from the EFF large wordlist — so the recovery code has always been English, ten words, ≈129 bits. No work needed, none done, and no row opened: a second definition of that secret here is exactly the cross-repo drift backupTargetAbsentText already demonstrates.
"the mail says 'three words' … strings.Count(code,"-")+1"	No claim mail states a count. They say Setup code: %s. The only count wording in the product was the bind page's passphrase hint ("five words"); its English half is now count-free, Hungarian unchanged.
"§8's phone-safe filter: no two words differing by one letter in the first six"	Measured, then declined. It removes 5270 of 7772 words — 68%, 12.92 → 11.29 bits/word — and would make this list stricter than the one the product already uses for the code a household writes on paper during a disaster. Reason and measurement recorded in source; operator may reverse. Replaced by an assertion: every word is 3–9 lower-case ASCII letters, no digit, no separator.
"request a reset code for the demo customer (en)"	There is no English customer on this hub. All five are hu. A scratch customer was created, proven, and deleted.
"demo-hp guest 9201"	Guest 9201 is on felhom-pve. I also claimed demo-hp was offline — that was MY error, withdrawn the same day (R-601): the box had been up four and a half weeks and reporting; both of my SSH routes pointed at stale addresses.
"customer.language reaches the anonymous claim page"	TRUE, verified at source before any edit and now pinned by a test rather than assumed.
"the box checks a hash and needs no change"	TRUE, and pinned by TestClaimAcceptsAnEnglishWordCode.
"29 633 words"; the line numbers	Right. (29 634 lines, 29 609 after dedup.) Every cited line number was accurate.

---

2. What shipped

Controller 0.259.0 — the claim page's fourteen sites through s.msg; the backup page's three protection constants become KEYS, with degradedMessageFor returning the key so the decision stays language-free and in one place; buildTierViews / backupTargetLabel / loadGuestBackup take the reader's language. 23 new keys in both bundles, all listed for the Go-parity gate.

Hub 0.119.0 — english.txt (EFF large, CC BY 3.0 US, provenance in source); RandomPassphraseFor(lang, use) choosing list and count together; all four callers pass a language; the English bind hint is count-free.

felhom.eu — the guide's three quoted messages corrected; guide_quote_gate.py binds them to the controller's English bundle (nothing did, so the guide would have gone on quoting Hungarian after the fix), with seven decoys; 05-hub-architecture.md §15.6; 10-localisation.md §10.6c.

---

3. Evidence

check	result
controller: build / vet / full suite	green
hub: build / vet / full suite	green
controller_gates.py --fast (17)	all OK
repo_gates.py --fast (15, incl. the new guide-quote)	all OK
i18n_go_parity.py	OK — 718 keys byte-for-byte against the frozen base
i18n_missing_gate.py	English missing 0 (ceiling 0); Hungarian formal 18 (ceiling 18)
decoys: felhom.eu 16/16, controller 23/23	all convict
unproven.py --summary	no number moved — still 35 of 55 not-walked

Four red-proofs, each seen failing:

1. One added full stop in hu.json → the go-parity gate named both sides.
2. The wrong-code Hungarian literal restored → the English test convicted twice (English absent AND Hungarian present).
3. The English setup code set to 3 words → the entropy test named the 38.77-vs-44.56 gap.
4. The engine reverted to RandomPassphrase(3) → the wiring test convicted on the word count and on the non-ASCII code.

Live, on real systems:

• Claim page, guest 9201, through the felhom_lang cookie — en: "Wrong or expired code" (the drill's own screen), "Invalid form — reload the page.", "Too many attempts — try again in 15 minutes."; hu: the byte-identical Hungarian for each.
• The lockout proved itself unasked: Hungarian attempts locked out the English request from the same source, demonstrating live that the counter is per source, not per language.
• Backups page: Local storage (felhom-backup) / Backup server – separate hardware (PBS) against the Hungarian.
• The setup mail, one day apart in the same inbox: 2026-09-20 képző-szkítia-ásatás → 2026-09-21 four plain-ASCII English words.
• Owner passphrase from the hub's own store: en 6 ASCII words, hu 5 accented — shape only, values never read out.

---

4. What I did NOT do, and why

• I did not complete a password reset on guest 9201. The task asked for it. To get an English code for that box I would have had to change the box's own language setting, because CustomerLanguage prefers the reported language over the config's — so flipping the hub's field alone would have produced a Hungarian code and proved nothing. Changing a live box's household setting to stage a test, and rewriting its password hash (this repo records a session that did exactly that and lost the original bytes), buys little: the acceptance path is untouched by this release and is pinned by TestClaimAcceptsAnEnglishWordCode. The refusals — which is what R-596 was about — were walked live in both languages, including the wrong-code answer that stopped the drill.
• The two Backup-page warnings were not walked live. Guest 9201 is healthy and a healthy box renders none, by design. Producing either state means un-assigning a live backup target. They are covered by render tests through the real handler.

---

5. Rows

Closed: R-596, R-597, R-598 — each with what it actually turned out to be, not just "fixed". Opened: R-602 (a live probe that uses a cookie on a signed-in page reports a fixed defect as unfixed), R-603 (an English string with an apostrophe silently never matches a rendered page), R-604 (a per-customer floor override silently excludes a box from every global raise — demo-hp had missed four). Withdrawn as false the same day: R-601 ("demo-hp is unreachable"). The operator looked at the hub and said it was online; it was, and had been for four and a half weeks. Both of my routes pointed at stale addresses — one at a tailnet peer for a box with no tailscale installed, one at an address the box left behind at a reprovision. The hub had carried the right address in every report. The lesson kept in the row: the standing rule says a "no access" claim must list what was tried; it does not say the list makes the claim true. Six failures against one wrong assumption is one failure.

---

6. The verdict

Nothing known now stands between an English-speaking tester and their box.

That is deliberately not the same sentence as "the walk passed". The three blockers the drill found are closed and each is proven on a live system — but the hour has not been re-walked end to end by a stranger on a fresh install, and this project's own rule, written into the recovery-journey row, is that fixes are not a journey. The next English walk is what turns this into a green row; it is also the walk that would exercise the two backup warnings, and it wants a one-drive machine.

The fleet floor is raised to 0.259.0 (operator asked, same session), min_agent 0.131.0 declared — above the vouched golden 0.258.0, so the declaration carries it (R-472). Both live boxes run 0.259.0. demo-hp took it by itself in under four minutes once its stale per-customer override was cleared, and its claim page then answered "Wrong or expired code" in English — the floor delivered the FIX to a box nobody hand-deployed, which is the only thing that shows a raise worked. Evidence: audits/i18n-closing-2026-09-21/floor-raise-0.259.0.md.

Needs the operator: nothing from this session.