The customer delete cascade logged "full teardown" while the drill box's WireGuard peer 10.77.0.5 was still configured on ep0. Checked THERE rather than inferred from the hub, then watched until it went: gone about 6 minutes later. The mechanism is asynchronous, not broken; the log line claims a completeness it does not yet have. Both periods this session inferred from two log lines were wrong — the delete's staleness window and wgsync's push interval. A period read off two log lines is not a measurement, and both rows now carry what was actually observed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
8.9 KiB
DRILL — an English speaker's first hour on 0.258.0 (2026-09-20)
Interventions a volunteer could not have made: 1 (I1 — reaching the dashboard at all, R-494, filed 2026-09-14, long before this walk). Felhom-owned Hungarian things the stranger met: 4 kinds — the claim page's messages, the setup code itself, the Backup page's two protection warnings and its two target names, and the menu word "Debug" (which is correct English for this reader).
Ready for an English-speaking tester: NOT YET — because the one screen that stands between them and their box answers them in Hungarian. Everything else held: the mails, the console, the bind page, the dashboard, the apps, the catalog, the language switch. The blocker is R-596, and it is a day's work, not a redesign.
Evidence: i18n-slice6-2026-09-20/drill/ — journal.md (every observable, in order),
screens/ (22 console and installer captures), pages/ (the dashboard as the household saw it),
box-logs/. Golden: ../tests/golden-0.258.0-2026-09-20/. R-516: ../audits/i18n-slice6-2026-09-20/R-516-item-by-item.md.
1. What held, in one table
| # | step | result | time |
|---|---|---|---|
| 0.1 | golden 0.258.0 baked, published, vouched — one run, no aborted attempts | PASS | bake ≈8 min |
| 0.2 | customer created with language=en; bind mail auto-sent on creation |
PASS | — |
| 1 | download page felhom.eu/en/download |
PASS — 200, 0 Hungarian, names file + checksum; the ISO the VM booted hashes to the published checksum exactly | 0.12 s |
| 2 | install — the GRAPHICAL installer, which 2026-09-14 did NOT exercise | PASS, with F1 (the guide told an English reader to keep a Hungarian keyboard) and F2 (it describes a reboot prompt the defaults never show) | install → console banner ≈11 min |
| 3 | first screen, pairing | PASS — bilingual banner, code P3G-JGW readable in both halves; /etc/issue in English |
power-on → "waiting to be paired" ≈11 min |
| 4 | self-bind through the mailed link | PASS — and this is what 2026-09-14 could not do at all (its H1). Page, refusal and success all English, 0 Hungarian lines | bind at 16:54:42Z |
| A2 | typo in the pairing code | PASS — "Those details are not right…", in English, does not say which half was wrong; hub logged attempt 1/5 |
— |
| 5 | setup code → claim | PASS, with F3 (the page's messages are Hungarian) and F4 (the code is three accented Hungarian words) | power-on → claimed ≈23 min |
| 4b | the dashboard's first language | PASS — English from customer.language alone, nobody touched a switch |
— |
| 6 | the two apps the guide names | PASS — installed with the default subdomains; API answered in English; both app pages 0 Hungarian | PrivateBin ≈40 s, BookStack ≈50 s |
| 7 | the Backup page as a first-timer | F5 — 4 Hungarian strings in 73 lines, and two of them are the protection warnings | — |
| 9 | version labels | PASS — "Up to date" in English (R-589, fixed this morning, proven on a fresh box) | — |
| 13 | the language switch, both ways | PASS — the globe moves the household; a visitor's switch on the sign-in page sets only their own cookie | — |
| 14 | the mailbox | PASS — all three customer mails in English; the operator's copy Hungarian by design; [+household(en)] in the box's own log |
— |
| — | R-214 (console never stops asking to be paired) | CLOSED — it no longer reproduces. The last paint is the bilingual "the box is linked" banner | — |
Not walked, and saying so rather than implying coverage: steps 8 (Back up now), 10 (remove with "delete my data too"), 11 (restore), 12 (the launcher a week later) and A1 (power cut). All five were proven on 2026-09-14 and none is language-bearing except through pages this walk already read in both languages. Step 7's recovery-code section could not be walked at all — the off-site tier needs ep0, which this task fenced, exactly as on 2026-09-14.
2. The intervention
I1 — the dashboard has no reachable address (R-494). The setup mail names
https://felhom.drill-en-0920.felhom.eu; getent hosts finds nothing, because no Cloudflare tunnel
was created and the token is an optional field on the customer page. The walk reached the dashboard
by breaking glass into the box (the hub-vaulted host_recovery credential) and driving the
controller from inside the guest. R-494 was filed on 2026-09-14 and narrowed to P3 by an operator
ruling, so it was filed long before it was performed. It was performed once and covered every later
dashboard and app request. The stop rule (four) was not reached.
3. Harness substitutions — not interventions, and why
| what | consequence for the claim | |
|---|---|---|
| H1 (GONE) | 2026-09-14 had no mailbox and could not exercise the mailed link or the self-bind page. This walk had one (the @felhom.eu catch-all), so the bind mail, the setup-code mail and the confirmation mail were all read as the customer, and the self-bind page was driven end to end. |
the biggest gap in the previous walk is closed |
| H2 (NOT a substitution this time) | The keyboard layout was set to U.S. English. On 2026-09-14 that was a harness need (qm sendkey speaks US scancodes). Here it is what the persona would genuinely choose — and the fact that the guide said otherwise is F1. |
— |
| H3 (GONE) | auto-reboot was left ticked, so the install rebooted itself — the path 2026-09-14 avoided. | the "stick still in" reboot is now exercised |
| H4 (GONE) | the graphical installer was used (it is the default), not the Terminal UI. | the graphical path is now exercised |
| H5 | no browser: every page was fetched through the endpoint it renders from, inside the guest. | script-rendered state was not observed |
Harness slips, recorded: the owner passphrase was printed to stdout once by a probe, against the
project's own file→file rule — it belongs to a throwaway customer and the teardown invalidates it;
every later use read a 0600 file. The first claim POST used the wrong field names (password instead
of new_password) and was answered 200 — a refusal, not a success (the "HTTP 200 can be a refusal"
trap, met and caught). Both are in journal.md.
4. Findings
| row | rank | one line |
|---|---|---|
| R-596 | P1 | The claim page — the first screen they touch — is English chrome with 16 Hungarian messages, two of which the guide quotes in English |
| R-597 | P2 | The setup code is three Hungarian words with five accented characters, inside a fully English mail |
| R-598 | P2 | The Backup page's two protection warnings and its two target names are Hungarian on an English dashboard |
| R-599 | P3 | A drill's teardown is blocked for 30 minutes by design (report staleness), and the 409 does not say so |
Classification of every Hungarian thing met: (F) R-596, R-597, R-598 · (A) the apps' own English UIs, which for this reader are an advantage · (K) "Debug" in the menu (R-516 item 1, correct English here), the operator-tier event copies (Hungarian by design), the 18 counted formal „ön" forms (R-516, unchanged by rule).
5. Scope and what this walk does NOT claim
- Not the recovery-code journey. Off-site needs ep0, which was fenced. Guide §7 — its longest and most emphatic section — is unproven by this walk, exactly as on 2026-09-14.
- Not a backup/restore/remove/power-cut walk. See the "not walked" note above.
- Not a Hungarian walk, which is why R-516 does not close — see
R-516-item-by-item.md. - Not a browser. Endpoint-level throughout, stated at every step.
6. Teardown — three layers
- Machine: VM 9301 stopped and
qm destroy --purged;/mnt/hdd_1/images/holds only 9202's disk. - Hub: customer
drill-en-0920deleted through the guarded path (confirm_id+ three acknowledgements +expect_hosts), which cascades the host, the claim, the DR recipe and 17 residue rows. The hub refused until the host went stale — 45 minutes after its last report (alerting.stale_thresholdin the deployed manifest, not the 30m literal in the checker's source; R-599). - ep0: the WireGuard peer
10.77.0.5the enrolment registered. Checked on ep0 itself, not inferred from the hub — and it was still there 3 minutes after the cascade logged full teardown. Watched until it went: gone by 17:47:46Z, about 6 minutes after the delete (wg show wg0 peers5 → 4). The mechanism works; the log line is premature about this layer. Filed as R-600. The 2026-09-14 findings say the host delete removes it; measured, the host delete removes the hub's RECORD andwgsyncremoves the peer on its next push.
Untouched, and checked: demo-hp guests 9201 and 9202 (running throughout, 24 containers
before and after), demo-felhom, DooPlex beyond the golden bake's own VM (reverted to virgin),
Peti's box, and ep0 beyond the product's own peer.