Files
felhom-controller/REPORT.md
T
2026-08-10 13:58:45 +02:00

110 lines
6.0 KiB
Markdown

# 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.