felhom.eu/documentation/audits/evidence-drill-fresh-install-0242-2026-09-14/journal.md

Journal — DRILL fresh install 0.242.0, 2026-09-14

Every observable in the order taken. Times are UTC unless marked. Hub log lines print CEST (UTC+2). Screens are in screens/, named by step.

Baselines (re-verified 12:5x UTC)

repo	main	version
felhom-controller	406755fa8fba	v0.242.0
felhom-agent	4586f0f7f6d1	v0.130.0
felhom.eu	41590f8ee618	hub v0.112.0

Hub, before the bake: agent 0.130.0 vouched · golden 0.236.0 vouched · min_agent 0.129.0 · floor min_controller_version 0.242.0. Highest register id R-492.

Phase 0.1 — golden 0.242.0

Baked 13:01:04 → finished before 13:06:42 · round-trip verified · vouched 13:08:41. Full record: documentation/tests/golden-0.242.0-2026-09-14/README.md.

Phase 0.2 — what a volunteer receives

Searched, with what was searched:

source	what was looked for	result
website/*.html (9 pages)	iso.felhom, iso, letolt, telepit	no mention of the installer, of iso.felhom.eu, or of any install step (only technologiak.html "comparison" and two FAQ answers on power loss / backups matched the loose pattern)
https://iso.felhom.eu/	the root, index.html	HTTP 404 both. Only a named object answers: felhom-installer-1.26.1-pve9.2-1.iso (200, 1 705 322 496 B, last-modified 2026-07-31)
RUNBOOK-onboarding-draft-v4.md	customer steps	operator document, operator present at the visit ("operator narrates"); C7 marked never executed
email.md in the workspace	find /mnt/5_hdd/felhom.eu -maxdepth 5 -iname '*email*.md'	absent (only audits/FINDING-app-email-rollout-2026-06-29.md, unrelated)
the R-11 tester one-pager	find … -iname '*one-pager*', register	never written — ROADMAP-HISTORY: "RULED 2026-07-21 (channel); doc is the architect's"
hub e-mails to a new customer	hub/internal/notify/templates.go	two: „Kösd össze a Felhom dobozodat" (self-bind link, at customer creation) and „Elindult a Felhom szervered — beállító kód" (claim code, after day-0). Neither says how to get or install the software

Harness limits, declared before the walk (not interventions — the volunteer is not limited this way)

• H1 — no mailbox. Both customer mails go only to the registered address. The hub stores hashes; the Resend key on DooPlex is send-only (401 restricted_api_key … only send emails, probed 13:00). A volunteer reads their inbox; this harness cannot.
• H2 — keyboard. qm sendkey emits US scancodes; the installer defaults to Hungarian. The layout was switched to U.S. English (as walk 5). A volunteer keeps Hungarian.
• H3 — the USB stick. Auto-reboot was unticked so the VM does not re-enter the installer from the still-attached ISO; the ISO is detached by qm set after the install. A volunteer pulls the stick.
• H4 — the Terminal UI entry was chosen over the graphical default for key-drivability. Both entries were release-gated.

Scope choice

• Customer created with the DR tier OFF (the form defaults it ON). The DR tier provisions an ep0 namespace and token; the brief fences ep0. Offsite is OFF by default and stayed OFF.

Step 1 — download

13:01:27 on demo-hp: curl https://iso.felhom.eu/felhom-installer-1.26.1-pve9.2-1.iso → rc 0, 32 s, 1 705 322 496 B, sha256 f3cc86d5f0ec68bba4155c994b4fa84e208d50209bb6e815636c99e5441059a6 = the published .sha256 exactly. (No release report records a sha for 1.26.1; walk 5 recorded "same sha256" without the value.) A volunteer must already know the exact file name — the site lists nothing.

Hub side — the operator's steps

13:03:03 POST /configs/new customer drill0242, name "Drill 0.242 first hour", domain drill0242.felhom.eu, e-mail drill0242@felhom.eu, DR tier off → 303 13:03:04. Hub log (CEST):

15:03:04 [INFO] Customer config created: drill0242
15:03:04 [INFO] self-bind link (hash 4270bdd2…, valid 7 days) emailed to the registered address of drill0242
15:03:04 [INFO] self-bind link auto-minted for drill0242 on customer creation (the console banner's promised email now exists)

The 5-word Tulajdonosi jelmondat was read from the customer page into a 0600 file on DooPlex (shape: 5 words, 42 chars). The operator must hand it to the volunteer out of band — nothing sends it. (The self-bind mail says „amelyet a beállításkor kaptál" — "which you received at setup".)

Step 2 — install

VM 330 drill0242-fresh-install on demo-hp: q35/OVMF (pre-enrolled-keys=0), 4 cores, 8 GB, cpu=host, scsi0 200 G · scsi1 50 G · scsi2 50 G qcow2 on nvme-scratch (dir at /mnt/hdd_1, the mount root), MAC bc:24:11:0c:23:cc.

UTC	screen	what it said / what was done
13:03:43	power on	—
13:03:49	GRUB (s01, s02)	Felhom logo, „Saját felhőd, saját szabályaid"; entries „Felhom telepítés" / „Felhom telepítés (szöveges mód)" — the only Hungarian the installer shows
13:05:09	s04	English Proxmox EULA, „I agree"
13:05:27	s05	„Target harddisk: /dev/sda (QEMU HARDDISK) (200.00 GiB)" — default is the right disk here; three disks present, no guidance which
13:05:43	s06	Country Hungary · Timezone Europe/Budapest · Keyboard Hungarian (H2: changed to U.S. English)
13:09:18	s13	Root password [at least 8 characters] · Confirm · Administrator email prefilled mail@example.invalid — the volunteer must decide what to type; set drill0242@felhom.eu
13:12:01	s16	nic0 bc:24:11:0c:23:cc · Hostname pve.example.invalid · IP 192.168.0.134/24 (the DHCP lease, frozen as static) · GW 192.168.0.1 · DNS 192.168.0.250
13:12:21	s17	Next on the defaults → „Invalid values: hostname does not look valid". The default is refused; the volunteer must invent a hostname. Set drill0242.felhom.eu
13:14:40	s22	Summary: ext4 · /dev/sda · Europe/Budapest · U.S. English · drill0242@felhom.eu · nic0 · drill0242.felhom.eu · 192.168.0.134/24 · 192.168.0.1 · 192.168.0.250 · „[X] Automatically reboot" (H3: unticked, s25)
13:15:54	Install pressed	—
≤13:19:18	s28	„Success — Installation finished - reboot now?" (≤ 3 m 24 s of copying; disk 4.0 G)
13:19:44	first boot	H3: qm stop, --delete ide2, --boot order=scsi0 in its own qm set (verified boot: order=scsi0, ide2 lines 0), qm start

Step 3 — the first screen and the claim

13:21:10 — the hub lists an Unclaimed appliance (86 s after first power-on): appliance 25, pairing code ***-*** (redacted), MAC bc:24:11:0c:23:cc, "Standard PC (Q35 + ICH9, 2009)", 7.7 GB, three SSH host keys.

The console (s29, code redacted), verbatim:

Welcome to the Proxmox Virtual Environment. Please use your web browser to
configure this server - connect to:
  https://192.168.0.134:8006/
drill0242 login:
Felhom — a doboz készen áll, és a párosításra vár.
Párosító kód:  ***-***
Nyisd meg az e-mailben kapott linket, és add meg
ezt a kódot és a jelszavadat.
Ez a képernyő magától frissül — nincs teendő a
doboznál, és nyugodtan itt hagyhatod bekapcsolva.

Two things a stranger meets here: an English line telling them to open the Proxmox admin page, above the Felhom text; and „a jelszavadat" ("your password") for the secret the self-bind mail calls „Tulajdonosi jelmondat" (R-323 renamed the mail, not the console).

The bind (H1 consequence). The volunteer's route is the self-bind link, which is in a mailbox this harness cannot read. The operator's documented fallback was used: POST /appliances/25/bind (customer_id=drill0242) at 13:21:43 → 303 flash=appliance_bound. The self-bind page itself was therefore NOT exercised.

Hub log (CEST = UTC+2):

15:21:44 appliance 25 BOUND to customer drill0242 (mode=appliance) — delivery staged for its next poll
15:21:45 appliance credentials DELIVERED once to appliance 25 (… passphrase withheld)
15:21:52 [claim] claim code (gen 1) emailed to the registered address of drill0242
15:22:21 host enrolled: drill0242-3f4b42 (customer drill0242)
15:22:21 vaulted break-glass recovery credential for host drill0242-3f4b42 (user=root@pam, secret 32 chars)
15:22:22 Artifact manifest served for customer drill0242 (agent=0.130.0 golden=0.242.0)
15:22:38 wg registered: host=drill0242-3f4b42 … ip=10.77.0.5/32 changed=true gen=1 sync=ok
15:22:39 DR-recipe host-half stored for customer drill0242 (host drill0242-3f4b42, v1)
15:23:58 Event from drill0242: controller_started (info) — Controller elindult (0.242.0)
15:23:58 managed floor SERVED for drill0242: floor 0.242.0, agent requirement "0.129.0" from manifest (golden 0.242.0)

Note on ep0: wg registered … sync=ok is a WireGuard peer written on ep0 by enrolment itself, with the DR tier OFF. The brief fenced ep0; the product touches it on every enrolment. Teardown owes its removal.

Step 4 — "ready", and the version

	vouched	landed
agent	0.130.0	0.130.0 (felhom-agent --version)
controller	golden 0.242.0	0.242.0 (docker ps: felhom-controller:0.242.0 … (healthy))

No self-update happened because none was needed — golden == floor. Power-on → controller running 4 m 14 s; bind → controller 2 m 15 s. Infra: traefik:v3.6.7, gtstef/filebrowser:1.3.3-stable. First local whole-guest backup ran unaided 15:28:53–15:29:23 CEST, OK (seen as a backup lock).

The console still shows the pairing banner and the stale code after bind (s30, 13:24:38) — R-214, still open.

Intervention I1 — the dashboard has no address (R-494, filed 13:2x BEFORE acting)

The claim mail says https://felhom.drill0242.felhom.eu. Measured:

felhom.drill0242.felhom.eu @1.1.1.1      A: (none)  AAAA: (none)
control felhom.enkisfelhom.hu @1.1.1.1   A: 104.21.3.175 172.67.130.252
https://felhom.drill0242.felhom.eu       curl rc 6 (cannot resolve)
@192.168.0.1 (router)                    (none)
@192.168.0.250 (installer-offered DNS)   (none)
@192.168.0.134 (the box) 13:27:39Z       (none)      — google.com resolves: the resolver is alive
agent 15:27:44 CEST  lanresolver: applied split-horizon record vmid=9201 domain=drill0242.felhom.eu ip=192.168.0.158
@192.168.0.134 (the box) 13:29:18Z       192.168.0.158

The hub has no tunnel/DNS creation code; cf_tunnel_token is an optional pasted field. Act: the dashboard is reached at the guest LAN address with the name forced (--resolve felhom.drill0242.felhom.eu:443:192.168.0.158), from demo-hp — which is where a browser on the household LAN would be. GET / → 302 /claim; the page, verbatim:

A szerver beállítása — Drill 0.242 first hour — „Add meg az e-mailben kapott beállító kódot, majd válassz saját jelszót a vezérlőpult védelméhez." · Beállító kód (szó-szó-szó) · Új jelszó (min. 12 karakter) · Új jelszó megerősítése · Beállítás és belépés · „Nem kaptad meg a kódot? Új kód kérése"

H1 — the setup code (harness substitution, not a volunteer act)

The code is in the mail. Observe access to the appliance: POST /hosts/drill0242-3f4b42/reveal-recovery-credential → 200 (the designed operator path; it emits an audit event), stored 0600, never printed. Then pct exec 9201 -- docker exec felhom-controller … --print-reset-code.

Harness slip, recorded: the first mint at 13:29:28 (generation 2) was captured with a pattern [a-z-]* that does not match accented letters, and the raw output was shredded before the capture was checked — that code was lost unseen. Re-minted (generation 3) with a byte-agnostic capture. Both mints supersede the mailed generation-1 code.

Step 3 (cont.) — the claim, through the front door

All dashboard requests from here are made from demo-hp (the household LAN) to the guest's traefik on 192.168.0.158:443 with the dashboard name forced — intervention I1, once, for the whole walk. Secrets travel on stdin to curl, never on a command line; the dashboard password is a generated 24-character value in a 0600 file on DooPlex.

UTC	request	result
13:31:19	GET /claim	200; felhom_claim_csrf cookie (82 B) + form token (64 hex)
13:31:20	POST /claim _csrf, code, new_password, confirm_password	302 → /, Set-Cookie: felhom_session
13:31:2x	GET /launcher	200 — „Indítópult — drill0242.felhom.eu", one tile Filebrowser, „Indítópult megosztása … A megosztás jelenleg ki van kapcsolva." Menu: Vezérlőpult · Alkalmazások · Tárhely (Meghajtók, Hálózati tárhely) · Biztonsági mentés (Áttekintés, Távoli mentés, Alkalmazások, Visszaállítás) · Megosztás · Rendszermonitor · Debug · Beállítások · version 0.242.0

Power-on → claimed dashboard: 27 m 37 s (13:03:43 → 13:31:20), of which the harness's own keyboard driving is most of the install phase.

Step 5 — the app list

GET /stacks → 200, „Alkalmazások — drill0242.felhom.eu", filters Mind / Futó / Leállítva / Telepíthető, 52 „Telepítés" links. GET /stacks/bookstack/deploy and /stacks/privatebin/deploy → 200. Both pages, verbatim in the parts a stranger reads:

BookStack — Telepítés · „Egyszerű, könyv-szerű wiki és dokumentáció platform" · ~150M · Pi kompatibilis · Memória 1058 MB / 3712 MB (28%) · „Hol lesznek az adatok: ennél az alkalmazásnál nincs külön adatmeghajtó-választás, ezért az adatai a rendszermeghajtóra kerülnek (/mnt/sys_drive). A mentései így is elkészülnek." · „Automatikusan generált értékek … Jegyezze fel a szükséges jelszavakat!" (Alkalmazás kulcs, Adatbázis jelszó — Megjelenítés) · Aldomain wiki · „Az aldomain telepítés után nem módosítható…"

PrivateBin — Telepítés · „Titkosított jegyzet és szöveg megosztás" · ~30M · Memória 1089 MB / 3712 MB (29%) · same data sentence · Aldomain paste

Observation, not yet a row: the drive page's „Meglévő meghajtó csatolása" candidate list (GET /api/disks/candidates) offers the guest's own system volume /dev/mapper/pve-vm--9201--disk--1 (mount_source /mnt/sys_drive, already_mounted: true, data_bearing: true) beside the two blank 50 G disks.

Step 5 (cont.) — deploy

Both through the deploy page's own call: every named input of #deploy-form → POST /api/stacks/<app>/deploy {"values":{…}}, then GET /api/stacks/<app> every 5 s (the page polls every 3 s). Generated secrets travelled on stdin and were shredded.

app	fields sent	POST	state transitions	running after
bookstack	APP_KEY, DB_PASSWORD, SUBDOMAIN=wiki	13:34:38 → 202 „Telepítés elindítva – az állapot a kártyán követhető"	+6 s deploying · +26 s degraded · +42 s starting · +68 s running	68 s
privatebin	SUBDOMAIN=paste	13:35:47 → 202	+5 s starting · +21 s running	21 s

Observation: the deploy page's poll handles deploying / running / starting / unhealthy / exited / stopped and has no degraded branch (deploy.html ~1040–1095), so for those 16 s the page keeps showing its previous step. Harmless here; recorded.

App pages (/apps/bookstack, /apps/privatebin): „Fut" · „Naprakész" · „Megnyitás ↗". BookStack's „Első lépések": „Nyisd meg a wiki.DOMAIN címet a böngészőben · Jelentkezz be: admin@admin.com / password · Változtasd meg azonnal az admin jelszót és email címet …" and a box „Alapértelmezett belépés admin@admin.com / password — Az első bejelentkezés után azonnal változtasd meg!". PrivateBin: „Nyisd meg a paste.DOMAIN címet …" → R-498 (52 of 53 templates).

Step 6 — using both, through their front doors

Front doors from demo-hp: wiki.drill0242.felhom.eu → 302 /login; paste.drill0242.felhom.eu → 200, 22 896 B, PrivateBin UI (English).

BookStack (over HTTPS, so its secure cookies work — R-460's 419 was a plain-HTTP effect):

UTC	act	result
13:37:18	log in admin@admin.com / password (the page's own instruction)	302 → /; logged-in markers 3
13:37:19	change password via POST /users/1	405 — harness wrong route (BookStack ≥23 is /settings/users/1)
13:37:52	change admin e-mail + password via POST /settings/users/1 _method=PUT	302 → /settings/users; old default login now → /login (refused); new → / (accepted)
13:38:44	create book „Családi receptek DRILL0242"	302 → /books/csaladi-receptek-drill0242
13:38:4x	save a draft with _method=PUT	405 — harness (the route is POST)
13:39:35	new draft 3 → POST name „Töltött káposzta", body DRILL0242-OLDAL Töltött káposzta: árvíztűrő tükörfúrógép 2026-09-14	302 → /books/csaladi-receptek-drill0242/page/toltott-kaposzta
13:39:3x	upload attachment nagymama-recept.bin, 262 144 B random, sha256 2e252913844f8931…	200, attachment id 1
13:39:3x	read back	page 200, sentence present 2 (negative control 0); attachment listed 1; GET /attachments/1 200 262 144 B, sha256 equal: YES

PrivateBin — the browser's own v2 format (AES-256-GCM, PBKDF2-SHA256 100 000, zlib), key only in the fragment, as a browser does:

UTC	act	result
13:38:08	POST / a paste „DRILL-0242 privatebin sentinel … — árvíztűrő tükörfúrógép", expire 1 week	200 {"status":0,"id":"3963448c37a87005",…}
13:38:08	GET /?pasteid=3963448c37a87005, decrypt	200, 471 B, decrypted == sent: True (sha256 5920d11290cca367…); wrong key → InvalidTag

Step 7 — the backups pages, read as a first-timer (13:38:55)

/backups verbatim, in order: „Csak egy másolat készül (nincs második meghajtó) — a 3-2-1 mentéshez csatlakoztasson egy második meghajtót vagy offsite tárolót." · „A rendszermentés jelenleg ugyanazon a lemezen van, mint a rendszer — így hibás fájlok ellen véd, lemezhiba ellen nem. …" · Rendszer (/) 1.96 GB / 68.7 GB (3%) · DB mentések – · Utolsó teljes mentés 2026-09-14 15:28 (10 perce) 624.3 MB Helyi tároló (local) Naprakész · „Következő mentés — 0 órája — a mentési ablakon belül" · Visszaállítás ellenőrizve „Még nem futott" · Mentés most · window 02:30 / 03:30 / 04:15 / 04:30–08:30 · Távoli rendszermentés „nincs beállítva".

• Honest: both warnings; the whole-box backup's date and target.
• Confusing: „Következő mentés" (next backup) with „0 órája" ("0 hours ago") under it — the value is the age of the LAST backup (backups.html:101-102, .AgeHours).

/backups/apps: „Utolsó adatbázis mentés: Még nem futott"; BookStack „Konfig + DB + Adatok" and PrivateBin „Konfig + Adatok", each „1. mentés Auto helyi Utolsó: most" · „Nincs 2. (off-drive) másolat" · „3. mentés Nincs beállítva".

„Utolsó: most" was checked, not assumed: timeAgoStr renders „most" only for a parseable time under a minute old (an empty value renders nothing, funcmap.go:283-296), and GET /api/backup/snapshots?stack=… returned for both apps {"time":"2026-09-14T13:38:53Z","short_id":"helyi","tier":1,"drive_label":"Belső SSD (rendszer)"} — 3 s before the page was read. True. (That unit predates the BookStack content of 13:39:35.)

/stacks/bookstack/backup → R-499: „… már szerepelnek a teljes rendszermentésben (PBS) … ehhez az alkalmazáshoz nincs külön teendő." — this box has no PBS.

/backups/restore: app select BookStack / PrivateBin, „Pillanatkép: — Válasszon alkalmazást —", „Még nincs mentés felhasználói adattal."

Step 8 — „Mentés most" (the app-backups page's button, POST /api/backup/run)

UTC	observable
13:41:21	pressed → {"ok":true,"message":"Mentés elindítva"}
+5 s	{"enabled":true,"running":true}
+21 s	{"db_dump":{"count":1,"duration":"15.752362463s","last_run":"2026-09-14T13:41:37.325510764Z","success":true},"enabled":true,"running":false}
13:41:42	both apps' restore points: {"time":"2026-09-14T13:41:37Z","short_id":"helyi","tier":1,"drive_label":"Belső SSD (rendszer)"} — one entry each; the 13:38:53 unit is gone (one local point kept)
13:41:4x	/backups/apps: „Utolsó adatbázis mentés: 2026-09-14 15:41 (most)"; Adatbázisok: bookstack · MariaDB · 59.0 KB · 15:41 · 41 tábla · OK

The date moved, to the true time, on both pages (R-476 class: holds). 21 s end to end.

Step 9 — version labels and Update

Both app pages: „Fut · Naprakész". GET /api/stacks/<app> at 13:42:28:

bookstack   template_images {bookstack: lscr.io/linuxserver/bookstack:26.05.2, bookstack-db: mariadb:12.3}
            catalog_images  {bookstack: lscr.io/linuxserver/bookstack:26.05.2, bookstack-db: mariadb:12.3}
privatebin  template_images {privatebin: privatebin/pdo:2.0.5}   catalog_images {privatebin: privatebin/pdo:2.0.5}

The catalog offers no newer version of either app, so there was nothing to press. Skipped, per the brief. „Naprakész" is true on this evidence (installed == catalog).

Step 10 — removal: what the dialog shows for PrivateBin

The app page's delete opens removeStack() (layout.html:396), which loads /api/stacks/privatebin/hdd-data → {"hdd_paths":null,"has_hdd_data":false} and /backup-data → [{"path":"/mnt/sys_drive/felhom-data/backups/primary/privatebin","size_human":"40K","exists":true}]. Rendered text, in order:

Alkalmazás eltávolítása: privatebin · „Az alkalmazás visszaáll "Nincs telepítve" állapotba. A sablon megmarad, újratelepíthető." · „Ez a művelet nem visszavonható!" · Mindig törlődik: Docker kötetek (adatbázis, alkalmazás konfiguráció) · Telepítési konfiguráció (app.yaml) · Másodlagos mentés ütemezése · Mentési adatok: /mnt/sys_drive/felhom-data/backups/primary/privatebin (40K) · ☐ Mentési adatok törlése · „Az éjszakai restic pillanatképek nem törölhetők egyenként — a megőrzési szabályok szerint automatikusan elavulnak." · Mégsem · Eltávolítás

No „delete my data" box appears — PrivateBin has no drive data; its data is in a Docker volume, which the dialog says is always deleted. „Delete my data too" was therefore performed as every delete box ticked: remove_backups: true (the only box), remove_hdd_data: false (no box shown). Observation: the sentence about „éjszakai restic pillanatképek" appears on a box with no restic configured at all.

Step 11 prep — the household loses a recipe (13:43:07)

Through BookStack's own delete: GET …/page/toltott-kaposzta/delete → token; POST …/page/toltott-kaposzta _method=DELETE → 302 to the book. Then: page 404, /attachments/1 404, the book page lists the title 0 times. The last backup containing both is the 13:41:37 unit (step 8).

Step 11 — restore BookStack from its backup, through the restore page

The page's own submit: POST /backup/restore _csrf (from the page meta), stack_name=bookstack, snapshot_id=helyi (the only point, 13:41:37 — step 8).

UTC	observable
13:44:13	302 → /backups/restore?flash=Visszaállítás elindult — az állapot itt frissül.
+6 s	app stopped
+11 s	starting
+26 s	running (probe pending)
+32 s (13:44:45)	running, health_probe.healthy: true
13:45:09	read back through the front door — login with the post-change password → /; page …/page/toltott-kaposzta 200; sentence present 2 (negative control 0); árvíztűrő tükörfúrógép present 2; /attachments/1 200, 262 144 B, sha256 equal to the pre-backup upload: YES

DATA: PASS. The recipe the household deleted at 13:43:07 is back, with its attachment byte-identical and its Hungarian text intact, 32 s after pressing restore.

Reading the page at 13:45:11, after completion: the one-shot flash is gone and the page shows the empty form again („Pillanatkép: — Válasszon alkalmazást — · Még nincs mentés felhasználói adattal."). CORRECTED 13:46 — the first reading here was wrong. The page's script polls /api/backup/restore-status, which at 13:46:03 returned "last":{"op":"restore","stack":"bookstack","ok":true, "message":"A(z) bookstack: 2 adatkötet és az adatbázis visszaállítva — az alkalmazás újraindult.", "finished_at":"2026-09-14T13:44:39Z"},"last_recent":true. So a Hungarian finish message exists and names what came back; whether the page shows it is script-rendered and was not observed (no browser here). The server-rendered HTML alone shows only the empty form.

Step 10 — removal, done the way the screens lead

Harness shortcut, withdrawn as a finding. At 13:43:36 the harness called POST /api/stacks/privatebin/remove on a running app and got 409 stack "privatebin" is still running — stop it first before removing (English). The screens never offer that: for an operational app stacks.html:99-102 shows Frissítés · Újraindítás · Leállítás and no „Eltávolítás"; the app page shows none either. Nothing changed on the box (before/after identical, step10-remove-observe.txt).

UTC	act	result
13:45:26	„Leállítás" → POST /api/stacks/privatebin/stop	{"ok":true,"message":"Stack privatebin stop completed"} (English message; the UI shows its own text) · stopped at +6 s
13:45:32	observe before	volume privatebin_privatebin_data ×1 · containers 0 · /opt/docker/stacks/privatebin/.felhom.yml · backup dir 40K
13:45:33	„Eltávolítás" with every box ticked → POST …/remove {"remove_hdd_data":false,"remove_backups":true}	200 {"removed":"privatebin","volumes_removed":["privatebin_privatebin_data"],"hdd_paths_removed":[],"hdd_paths_preserved":[],"backup_paths_removed":["/mnt/sys_drive/felhom-data/backups/primary/privatebin (40K)"]}
13:45:39	observe after	volumes 0 · containers 0 · backup dir No such file or directory · only the catalog template .felhom.yml remains (the dialog: „A sablon megmarad")
13:45:4x	front door / API	paste. → 404 · restore points [] · state not_deployed, deployed=false

PASS — the drive is clean of the app's data and its backups, and the response names each thing it removed. (volumes_removed is populated here; R-489 recorded null over removed volumes on demo-hp — this box did not reproduce it.)

Step 12 — status pages, read as a customer would a week later (13:46)

• /launcher: tiles BookStack, Filebrowser (PrivateBin gone — correct).
• /dashboard: „3 Futó alkalmazás · 0 Leállítva · 55 Összes alkalmazás" · Memória 1.0 GB / 4.0 GB · Rendszer (/) 2.11 GB / 68.7 GB · Lemezek állapota: QEMU QEMU HARDDISK „Nincs adat" „0 °C" · „Utolsó mentés: 2026-09-14 13:41" while /backups/apps says 15:41 for the same run → R-500 (dashboard.html:154 formats without the box zone).
• /monitoring: „Hub kapcsolat — Kapcsolódva … Utolsó sikeres jelentés: most"; graphs „Még nincsenek adatok…". The banner „A gazdagép metrikái jelenleg nem elérhetők" appeared in my text extraction, but it is display:none by default and shown only by script (monitoring.html:15) — not evidence; withdrawn. Whether the host card fills in was not observable without a browser.
• Observation, not filed: „0 °C" beside „Nincs adat" on a virtual disk.

Evidence off the machine, end of Phase 1 (13:46)

box-logs-phase1/: controller.log (526 lines), agent-journal.log (2461), bootstrap-journal.log (173, pairing code redacted), box-state.txt. Secret sweep over the copies for the claim code, passphrase, dashboard password, BookStack password, break-glass credential and installer root password: 0 each; control (passphrase planted in a throwaway copy) 1.

Accident A1 — power cut (A1-power-cut.txt)

UTC	observable
13:47:31	before: felhom-controller:0.242.0 · bookstack:26.05.2 · mariadb:12.3 · filebrowser:1.3.3-stable · traefik:v3.6.7, all healthy · agent 0.130.0
13:47:33	qm stop 330 (hard)
13:48:36	qm start 330 (60 s dark)
+37 s	appliance answers SSH
+2 m 07 s (13:50:43)	hub: Event from drill0242: controller_started (info) — Controller elindult (0.242.0)
+2 m 9 s	dashboard /api/health 200
13:58:11	the dashboard session did not survive: /api/stacks/bookstack → 401 authentication required (the customer logs in again; the harness loop misread this as unparseable for 8 min — harness fault, stopped)
13:58:33	after re-login: bookstack running, healthy, template images unchanged; every container Up 7 minutes (healthy), same five image tags; agent 0.130.0
13:58:36	BookStack front door: page 200, sentence 2 (control 0), Hungarian 2, attachment 262 144 B, sha256 equal: YES

Hub log across the cut (non-routine lines only): DR-recipe host-half stored 15:49:04 CEST, controller_started 15:50:43, DR-recipe app-half stored 15:50:44. No alarm, no warning, no customer mail event.

A1: PASS — every app back on the same version (Slice 3 holds), data intact, no false alarm, ≈2 min to a working dashboard. Cost to the household: one re-login.

Accident A2 — a typo in the code

Where it can be tried. The setup code is single-use and this box is already claimed, so the first-claim screen cannot be re-entered. The login page's „Elfelejtett jelszó" opens the same /claim form and the same code gate, titled „Jelszó visszaállítása — Felhom · Add meg az e-mailben kapott beállító kódot, majd válassz új jelszót." A2 was run there, on the same box. The pairing-code typo on the hub's self-bind page was NOT exercised (H1: no link).

Code: generation 4, minted by H1 at 13:59:30. The typo is the real code with its last letter changed — exactly one character different, same length (checked, never printed). Limiter, from source (claim.go:32-33, :170-200): 5 failures → 15-minute lock, counted per source AND globally.

UTC	attempt	result
14:00:09	typo	200, form re-rendered (not accepted)
14:00:10	the right code, new 24-char password	302 → / — accepted after the typo
14:00:10	log in with the new password / the old one	302 / 200 (old refused)
14:00:10–12	four more wrong codes (the spent code)	200 each
14:00:12	the 5th failure	box: [WARN] [web] claim: code lockout tripped (source 192.168.0.104) — 15 min · Event pushed: claim_lockout (warning) — Túl sok hibás beállító kód — a beállító oldal 15 percre zárolva
14:00:12	a 6th attempt, during the lock	200
14:00:16	hub	Event from drill0242: claim_lockout (warning) … · Operator email sent for drill0242/claim_lockout

Harness note: the text filter used on these replies missed the refusal wording, so the on-screen messages are taken from the reply bodies below, and the plain „Hibás vagy lejárt kód" reading is repeated after the lock expires. | 14:15:26 | a wrong code after the 15-minute window | 200, error box „Hibás vagy lejárt kód" — the form accepts attempts again |

On-screen wording, read from the reply bodies: during the lock „Túl sok próbálkozás — próbáld újra 15 perc múlva."; after it „Hibás vagy lejárt kód". Both Hungarian, both true.

A2: PASS — a one-letter typo is refused without harm, the right code is accepted right after it, the lock is honest about its length and lifts on time. Two properties recorded, not filed: the lock is global as well as per source (claim.go:188-200) — five wrong guesses from anywhere lock the real household out for 15 minutes, by design against guessing; and the lockout e-mail went to the operator only (Operator email sent for drill0242/claim_lockout), while the screen tells the customer.

Teardown — three layers (teardown-before.txt, teardown-layer1.txt, teardown-layer2.txt, teardown-layer3-hub.txt)

Evidence was copied off the box before the destroy (box-logs-final/, 14:16, secret sweep 0).

layer	UTC	result
1. machine	14:16:23	qm destroy 330 --purge → qm list empty; /mnt/hdd_1/images/330 gone; images/9202 untouched
2. host	14:16:27	ISO removed (0 left); /root/drill0242 shredded, removed; nvme-scratch used 19 059 372 → 10 130 532 KiB; local 24 768 200 → 23 013 832 KiB; local-lvm 44.17 % before and after; 9201 and 9202 running; vmbr9 pre-existed
3. hub	14:35:15	host stale at 14:34:45 (true host_stale operator mail); customer DELETE cascade COMPLETE (journal #17); customer and host pages 404; lists 0 (control 1)
3b. ep0 peer	14:40:00	10.77.0.5/32 removed at the 14:39:30 periodic push (5 → 4 peers); 4 m 14 s after the delete; control peer present

Disposition of drill0242: DELETED. The hub's event stream and the three operator mails (claim_lockout, host_stale, and the bind/enrol log lines) are append-only and stay, by design.