# REPORT — v0.211.0 built, baked and published; AWAITING THE DAY-0 VOUCH (2026-08-10) **Parts 1, 4b and 5 of the tester-visit task. Code is on `main` and CI-green, the image is published, and golden 0.211.0 is baked and published. The ONE remaining step is the operator's Day-0 vouch — until that is saved, a fresh install still receives 0.210.0.** Commits: `b762a37` (Part 1), `86a78c6` (Parts 4b + 5). CI runs confirmed by id: **296** and **297**, both `success`. Green gate: `go build`/`go vet` clean, **28 packages ok, 0 FAIL**; all ten controller gates OK. --- ## What shipped **R-280 — the drive can be re-attached after a reinstall.** `attach` now also carries the controller's own mounted-but-unregistered filesystems (`internal/web/attach_sources.go`), read from its own mount table. `initialize` is untouched, so the format wizard's system/backup protection is unchanged. These candidates are REGISTERED in place (`POST /api/storage/register-mounted`, path re-derived server-side and refused if not currently offered). The „két kattintás" sentence is conditional on the picker being non-empty; the false branch says what is true and names a route. **R-294 — the orphan card stops promising restorability.** Copy replaced verbatim from `SPEC-orphan-card-copy-2026-08-10.md` §4. **R-295 (controller half) — one name per secret.** „Visszaállító kód" retired; the dashboard code is „Beállító kód" on both branches and in both operator-facing strings. Naming only. **Instrument fix.** `secret_in_markup_gate.py` no longer convicts Go template comments (stripped before render); `` comments deliberately still convict. Proven both ways: passes the comment, still convicts a planted `{{.RecoveryPassword}}`. --- ## The Part 1 mechanism, corrected against live source The prompt's mechanism is real but **mislocated**, and the fix it proposed would not have worked. - `handleDiskCandidates` is in **felhom-agent** (`internal/localapi/disks.go:425` → `internal/storage/candidates.go:33`), not the controller. - **Widening the agent's scan would have offered the wrong drive.** The filesystem a rebuilt box must re-register is an IN-GUEST one — on demo-hp `/mnt/sys_drive`, the guest's own 70 GB data volume, which is what the escape hatch registered. The agent enumerates HOST block devices and would have offered the 1 TB NVMe (`/etc/pve/storage.cfg`: `dir: felhom-backup` → `/mnt/nvme-1tb`). - Verified the controller container sees `/mnt/sys_drive` in its own `/proc/mounts` (`/mnt` is bind-mounted in), so the source and the action agree. - **Consequence for the session's shape:** no agent release. `agent_version` 0.128.0 and MinAgent 0.127.0 are both unchanged. **One deviation from the spec, stated:** the attach list is a **union**, not a replacement. A pure replacement fixes the reinstall and breaks the case the wizard was built for — a fresh external drive carrying a filesystem, not yet mounted, which a mount table cannot report precisely because it is not mounted. --- ## Red-proofs — every one failed against the mutated tree, mutation asserted applied | # | Mutation | Failure observed | |---|---|---| | 1 | attach reverted to the unclaimed scan | `attach candidates: 0, want 1 (/mnt/sys_drive) — got []` — **yesterday's exact wall** | | 2 | `initialize` switched to the new source too | `/mnt/sys_drive` present in the FORMAT list; protection breaking in the open | | 3 | `{{if .HasAttachDestination}}` removed | all three assertions; the false „két kattintás" promise returns | | 4 | rootfs-alias guard disabled | `/mnt/rootcopy` offered as a data store | | 5 | old orphan-card sentence restored | the restorability promise quoted back | | 6 | `{{if .IsReset}}Visszaállító kód…` restored | reset branch shows the retired name | **The Part 1 proof failed against today's tree** (red-proof 1) — that is the answer to the question asked explicitly. Guard 4 was not in the spec. It was found while building the live reproduction: a bind mount republishes a filesystem under a second path, so a bind of the guest rootfs under `/mnt/` would have been offered as a data store. --- ## STOP 2 — the route used Neither of the two bad options. **The live store was not unregistered and no reinstall was needed.** A fresh loop-backed ext4 filesystem was created on demo-hp's guest; loop devices turned out to be unavailable in an unprivileged LXC, which is what surfaced guard 4. Artefacts cleaned up (verified: directory gone, 0 matching mounts). The endpoint-level live check needs the new image and therefore belongs after the bake. --- ## NOT DONE — and none of it is "nearly done" - **The Day-0 vouch (STOP 3).** Not made, deliberately — it is the operator's. All three values are verified fetchable AND selectable; see `felhom.eu/documentation/tests/golden-0.211.0-2026-08-10/`. `golden_currency_gate` went from RED to GREEN with the bake. **No `--no-verify` anywhere.** - **The Part 1 endpoint-level live check** — the image is published but was NOT deployed to a box in this session, so the new picker has not been exercised through a live endpoint. Unit- and render-proven only. - **Part 2 (installer removal leaves dnsmasq)** — dropped first, per the task's own drop order. - **Part 4a (hub half of the naming)** — dropped second. Filed as R-295 PARTIAL. - **Part 3's "establish before changing"** — a fresh install was never watched taking a stale local golden. The installer fix exists in `felhom.eu` but is committed-only and unpublished for that reason. ## Observations, not acted on - **R-298** — `/storage`'s unregistered list is gated on `role==='user-data'` (`storage.html:363`), so a drive that is also the backup target renders locked with no actions. This is the SECOND, independent reason that page was empty on the rebuilt box; R-280's fix does not touch it. - **R-296** — `backups_remote.html:98` makes the same unevaluable promise the spec calls "Accurate; keep", in a conjugation the spec's own guard does not match. Left unchanged deliberately: not improvising Hungarian at the customer. ## Deliberately out of scope (so they do not read as forgotten) The CI runs that fail with no log; the twenty facts the machines report that nothing reads; the nine claims still honestly grey; and proving that a *retained* key can actually open an old store — the one thing the retention fix has never been shown to do.