# REPORT — DRILL: a stranger's first hour on 0.242.0 (2026-09-14)

**Runbook-style validation. No product code written.** A parallel session owns root `REPORT.md`, so
this is a topic sibling (`CLAUDE.md`). Findings doc: `documentation/audits/DRILL-fresh-install-0242-2026-09-14.md`;
every observable: `documentation/audits/evidence-drill-fresh-install-0242-2026-09-14/journal.md`.

## 0. Claims in the brief that turned out wrong, or incomplete — named first

1. **"ep0 is not touched."** Enrolment itself registers a WireGuard peer on ep0 for every box
   (`wg registered … ip=10.77.0.5/32 … sync=ok`), DR tier on or off. I avoided the part I could (DR
   tier off, which would have created an ep0 namespace and token); the peer is the product's own act
   and is removed by the host delete (§5).
2. **"This run re-proves or narrows the journey row (~L90)."** That row is the **rebuild-and-recover**
   journey (walk 5). This drill walked the **first hour**, with off-site off. It can neither re-prove
   nor narrow that row. I added a scope note to it and a **new first-hour row** (PARTIAL).
3. **"Claim the box with the code."** There are three secrets, not one: the console **Párosító kód**,
   the operator-held **Tulajdonosi jelmondat** (nothing delivers it — R-497) and the mailed
   **Beállító kód**. Two of the three arrive by mail, which this harness cannot read.
4. **The three claims marked "read, not measured"** — measured now: **website** — true, no mention of
   the installer or `iso.felhom.eu`, and the ISO host has no index; **instructions** — true, none exist
   (R-493); **golden landing** — the box landed on 0.242.0, the new golden, with no self-update.
5. **"Newest baked golden 0.236.0; waiver to 2026-09-27; highest R-492; baselines"** — all correct.

## 1. Baselines (re-verified 12:58 UTC)

controller `406755fa8fba` v0.242.0 · agent `4586f0f7f6d1` v0.130.0 · felhom.eu `41590f8ee618`
hub v0.112.0. Hub before: agent 0.130.0, golden 0.236.0, `min_agent` 0.129.0, floor 0.242.0.
Architecture read for the area: `00-capability-map.md` (journey row), `09-update-architecture.md` §3.

## 2. The golden

**0.242.0 baked, round-trip verified, vouched** — sha `3ab480dd…e6d8`, 653 288 425 B, all markers
pass, token-leak 0 with a working control, three readers agree. Only `golden_version` moved.
`documentation/tests/golden-0.242.0-2026-09-14/README.md`. The golden-currency gate is now plain OK.
One slip: my first template pick was arm64; caught before the bake.

## 3. The verdict

**Interventions: 1.** **Ready for a volunteer: no** — no instructions exist (R-493), and the setup
mail's dashboard link does not open for a new customer (R-494). Every mechanism after that passed:
install, landing on the vouched set, deploy, use, backup, remove, **byte-identical restore**, power cut
(same versions, no alarm), code typo and lockout.

| intervention | row | what |
|---|---|---|
| **I1** | R-494 (filed before acting) | dashboard reached by LAN address with the name forced — the mailed name has no DNS |

Harness substitutions (a volunteer would not need them; each hides a part of the path): **H1** no
mailbox → operator bind instead of the self-bind page, and two box-printed setup codes via the vaulted
break-glass; **H2** US keyboard layout; **H3** auto-reboot unticked, ISO detached; **H4** Terminal UI
entry. Full list with harness slips: findings doc §3.

## 4. Findings — every one a row

| row | rank | |
|---|---|---|
| R-493 | P1 | no customer install instructions; ISO host has no index |
| R-494 | P1 | new customer's dashboard has no address (I1) |
| R-495 | P2 | installer's unanswered questions; refuses its own default hostname |
| R-496 | P2 | console sends a stranger to the Proxmox admin page; „a jelszavadat" |
| R-497 | P2 | the Tulajdonosi jelmondat is delivered by nothing |
| R-499 | P2 | „already in the PBS backup, nothing to do" on a box with no PBS |
| R-498 | P3 | 52 of 53 app pages say literal `wiki.DOMAIN` |
| R-500 | P3 | dashboard backup time in UTC, backup pages in local time |
| R-501 | P3 | the documented CI-check recipe reads only the last jobs page and can miss a run (hygiene, found at push) |

**R-469 was not touched.** R-214 reproduced (recorded, row unchanged).
**Register: 200 → 209 table rows. Opened 9 (R-493…R-501), closed 0.**

## 5. Teardown — three layers

| layer | before | after |
|---|---|---|
| **1. machine** | `qm list`: VM 330 running, 8.6 G in `/mnt/hdd_1/images/330` | `qm destroy 330 --purge` → `qm list` empty; `images/330` gone; `images/9202` untouched |
| **2. host** | `nvme-scratch` used 19 059 372 KiB · `local` used 24 768 200 KiB · ISO present · `/root/drill0242` 40 files | `nvme-scratch` **10 130 532 KiB** (≈8.5 GiB returned) · `local` **23 013 832 KiB** (the 1.7 GiB ISO) · ISO 0 · scratch dir shredded and removed. `nvme-scratch` storage itself stays — it hosts 9202. `vmbr9` pre-existed |
| **3. hub** | customer `drill0242`, host `drill0242-3f4b42` ONLINE, `deletable:false`, `wg_peer_bound:true`, `recovery_present:true` | **customer and host DELETED** — customer page 404, host page 404, both lists 0 (control customer listed 1); ep0 peer `10.77.0.5` **gone** at the next peer push (control peer present) — §5b |

### 5b. The hub record

**Disposition: DELETED.** Not retained as a fixture, not blocked.

| UTC | observable |
|---|---|
| 14:34:45 | hub: `Host staleness: drill0242-3f4b42 ok → stale (host_stale)` · `Operator email sent for drill0242/host_stale` — a **true** alarm, caused by the VM destroy |
| 14:34:53 | `/hosts/drill0242-3f4b42/delete-impact` → `"deletable":true,"status":"stale","wg_peer_bound":true,"recovery_present":true` |
| 14:35:15 | `POST /configs/drill0242/delete` `ack_hosts=1 ack_reset=1 ack_purge=1 confirm_id=drill0242 expect_hosts=1` → **303 `/configs?flash=deleted`** |
| 14:35:16–17 | `customer DELETE cascade started … (journal #17, 1 host(s))` · `host drill0242-3f4b42 deleted (escrow DEMOTED to retained custody)` · `tenantsync: deprovision ok for drill0242 (ns=drill0242, existed=false)` · `reset drill0242: PBS tenancy deprovisioned` · `[claim] reset to unclaimed` · `residue purged (reports=9 app_telemetry=16 … notif_prefs=1 selfbind_tokens=1 appliance_registrations=1)` · **`customer DELETE cascade COMPLETE for drill0242 (journal #17) — full teardown`** |
| 14:35:2x | `/customers/drill0242` **404** · `/hosts/drill0242-3f4b42` **404** · `drill0242` on `/configs` **0** (control `enkisfelhom` **1**) · on `/hosts` **0** |
| 14:35:15 / 14:37:21 | ep0 `wg show all allowed-ips`: `10.77.0.5/32` present **1**, **1** (read-only; control `10.77.0.3/32` present) |
| 14:39:30 | hub: `wgsync: pushed 4 peers to 167.233.158.164:22` (was 5) |
| 14:40:00 | ep0: `10.77.0.5/32` **0**, config files naming it **0**; control `10.77.0.3/32` **1** |

**Observation, not filed:** the delete does not trigger an immediate peer push, so the ep0 peer
outlived the customer by 4 m 14 s, until the periodic full-list push (`wgsync/reconciler.go:19-23`,
declarative by design). **The retained escrow custody the host delete mentions is empty here** —
`escrow_present:false`; no ceremony ran — and the customer purge is the step that removes it anyway.
`tenantsync … existed=false` confirms no ep0 PBS namespace was ever created (DR tier off).

**Append-only and staying, by design:** the hub's event stream (`controller_started`, `app_removed`,
`claim_lockout`, the bind and enrol lines) and the operator e-mail for the lockout.

**Untouched, and checked:** demo-hp guests 9201 and 9202 (running before and after); `local-lvm`
(44.17 % before and after); demo-felhom; DooPlex services (the bake VM, the accepted exception, back
on `virgin`); Peti's box; ep0 beyond the product's own peer. `drill-r50` does not exist (R-461).

## 6. Secrets

Hub password, BookStack and dashboard passwords, the passphrase, both setup codes, the break-glass
credential and the installer root password lived only in `0600` files in the session scratchpad.
**Every committed file was swept for each, with a planted control that was found: 0 hits.** The
pairing code is redacted in two screenshots and the text. The break-glass reveal emitted its audit
event, by design.

## 7. `unproven.py --summary`

Unchanged: 55 claims, NOT WALKED 35 of 55. It reads its own claim list, not the new map row.

## 7b. CI for my push

`38848ff` (felhom.eu `main`): **job id 581 `gates` — completed, conclusion `success`**, 14:18:23Z
(run id 582, run_number 335 on `actions/tasks`). Found by scanning every page of `actions/jobs` and
matching `head_sha`: the documented last-page recipe did not list it for 8 minutes because the list is
not in id order — **R-501**. Register now **200 → 209** table rows (opened 9, closed 0).

## 8. Observations

- The deploy page's poll has no `degraded` branch; 16 s of stale step text on BookStack.
- The drive-attach list offers the guest's own system volume as an existing drive.
- The removal dialog names „éjszakai restic pillanatképek" on a box with no restic.
- „0 °C" beside „Nincs adat" for a virtual disk; an English „Debug" menu item.
- The claim lockout is global as well as per source; its mail reaches the operator only.
- Two of my first readings were of script-rendered elements from server HTML (host-metrics banner,
  restore-finish message); both corrected in the journal. **No browser here — strict UI coverage is
  the operator's click-through.**