REPORT — v0.211.0 written, NOT DELIVERED (2026-08-10)

Parts 1, 4b and 5 of the tester-visit task. Code is on main and CI-green; the golden bake and the Day-0 approval did NOT happen, so nothing here reaches a customer yet.

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/<name> 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 golden bake and STOP 3's approval. golden_currency_gate is RED and correct: controller 0.211.0 is released and the newest bake is 0.210.0. No --no-verify was used anywhere.
The Part 1 endpoint-level live check — needs the baked image.
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.

6.0 KiB Raw Blame History