Files
felhom.eu/documentation/audits/DRILL-first-hour-en-0258-2026-09-20.md
T
admin 732e9b9e0c
gates / gates (push) Successful in 25s
Teardown verified on ep0, and the two periods I got wrong (R-600)
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
2026-09-20 19:48:20 +02:00

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-0920 deleted 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_threshold in the deployed manifest, not the 30m literal in the checker's source; R-599).
  • ep0: the WireGuard peer 10.77.0.5 the 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 peers 5 → 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 and wgsync removes 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.