admin
e02bc03819
The setup code and the owner passphrase now follow the household's language,
one word longer in English so the entropy never drops (setup 3 hu / 4 en,
passphrase 5 hu / 6 en). List and count are chosen together so a caller cannot
pair an English list with a Hungarian count. Hungarian is byte-unchanged.
Three claims in the row were wrong and are recorded as such:
- the RECOVERY CODE is minted by felhom-agent from the EFF list and has
always been English; the hub does not own it and no row was added.
- no claim mail states a word count; the only count wording was the bind
page's passphrase hint, whose English half is now count-free.
- the proposed phone-safe filter removes 68% of the list (5270 of 7772
words) and was measured, then declined, with the reason in source.
Also: guide_quote_gate binds the English volunteer guide's three quoted
messages to the controller's English bundle — nothing did, so the guide would
have gone on quoting Hungarian after the fix. Seven decoys, all convicting,
including the name-for-fact one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2.7 KiB
Live proof — the Backup page's Go-composed copy follows the language (R-598)
Box: guest 9201 (demo-felhom) on felhom-pve, controller 0.259.0, 2026-09-21.
Method: endpoint-level; signed in as the household, then GET /backups in both languages.
What was proven live
hu |
en |
|
|---|---|---|
| page title | Biztonsági mentés — Felhom.eu |
Backup — Felhom.eu |
| primary tier label | „Helyi tároló (felhom-backup)" | "Local storage (felhom-backup)" |
| offsite tier label | „Biztonsági szerver – külön hardver (PBS)" | "Backup server – separate hardware (PBS)" |
| page size | 46 384 bytes | 45 728 bytes |
Those two labels are backupTargetLabel / buildTierViews — Go-composed strings handed to the
page as struct fields, which is the whole defect class. Before 0.259.0 the English column read
exactly like the Hungarian one.
A finding about the method, worth more than the result
The first run used the felhom_lang cookie and got the Hungarian page for en. That is
correct behaviour, not a defect: langFor step 2 says a request with a session is the
household's own, so their saved setting wins and the visitor cookie is deliberately not read — a
signed-in family must never see a language a previous visitor picked on the sign-in page of the same
browser. The cookie is the right instrument for the anonymous claim page and the wrong one for a
signed-in page. ?lang= — the documented testing override — is the right one here.
This is worth writing down because the mistake is invisible: a session that had only run the cookie probe would have concluded R-598 was not fixed, and "fixed" it a second time.
What was NOT proven live, and why
The degraded and absent-drive warnings did not render, because this box is healthy — it
has a real backup drive (felhom-backup), and a working configuration is designed to render nothing
at all (E-2 Scenario E). Producing either state live would mean un-assigning a real box's backup
target, which the task fences forbid and which is not worth doing to read a sentence.
They are covered instead by tests that drive the real page handler with the agent seams set to
the two states and read the returned HTML — TestBackupWarningsFollowLanguage,
TestAbsentDriveWarningFollowsLanguageAndKeepsThePromise. Those assert both that the English
appears and that the Hungarian is gone, and the English absent-drive copy is asserted to carry
the FACT, the CONSEQUENCE and the REMEDY, matching the Hungarian.
Stated plainly: the two warnings the drill actually saw are proven by a handler-level render test, not by a live box. The next full English walk on a one-drive machine is what closes that.