felhom-controller/REPORT.md

REPORT — felhom-controller v0.56.0 (Phase 4: FileBrowser scoping + UI polish) — SLICE COMPLETE

Phase 4 closes the per-app-recovery-unit / Tier-2 slice. Built, deployed, and live-validated on guest 9201. With this, all five phases of the spec (1, 2, 2b, 3, 4) are shipped and live-validated — see git history (v0.52 → v0.56).

Phase 4 — what shipped (v0.56.0)

• 4A FileBrowser scoping (safety): the FileBrowser bind mount is scoped to each drive's appdata/ subtree (<drive>/appdata:/srv/<name>) instead of the whole drive root. The recovery units + Tier 2 copies under backups/ are not mounted into FileBrowser at all — the customer browses their userdata but cannot reach (or see) the thing that restores them. syncFileBrowserMounts mkdir's the appdata dir before binding; it runs on controller startup, so the scoping applies immediately.
• 4B Deploy-UI communication: the storage-selection step states plainly (Hungarian) that the chosen drive holds the app's files, while its database runs on the fast internal SSD and is backed up alongside the app — so the DB-on-SSD split stops being a surprise.
• 4C Monitoring storage list: buildStorageBars sorts deterministically (by path) and carries a purpose description for the user-data drives, rendered on the monitoring "Tárolók kapacitása" list. (Correction to the spec's premise: this list is the controller's registered user-data drives only — the agent's local/local-lvm/pbs storage is not in this registry, so the role-tier sort and local-vs-local-lvm descriptions live on the agent-backed storage-management page, not here.)

Live validation (guest 9201)

• 4A: after deploy, FileBrowser's mount is /mnt/felhom-usb/appdata -> /srv/felhom-usb; /srv/ felhom-usb lists romm (userdata) and the recovery units at /mnt/felhom-usb/backups are outside the mount — confirmed via docker inspect.
• 4B: the deploy page (nextcloud) renders "…adatbázis a gyors belső SSD-n…".
• 4C: the monitoring page renders "Külső adattároló — … az adatbázisok a belső SSD-n vannak."

Slice summary (all live-validated on guest 9201)

• Phase 1 (v0.52.0): deploy-side Model-A double-nest fix (catalog templates) + deploy↔backup path agreement test; RomM migrated.
• Phase 2 (v0.53.x): per-app secret-free recovery unit (compose + secret-stripped app.yaml + db-dumps + volume-dumps + manifest), idempotent capture.
• Phase 2b (v0.54.0): restore-from-unit recreate + fail-closed data_key gate (proven live on AdventureLog: refused when the encryption key was unrecoverable).
• Phase 3 (v0.55.0): auto off-drive Tier 2 with the rootfs-headroom guard (refuse-not-fill, proven live).
• Phase 4 (v0.56.0): FileBrowser scoping + deploy DB-on-SSD note + monitoring descriptions.

Known follow-ups (small, optional)

• Off-disk identity uses block-device equality; the agent's DiskInfo.DurableID is stronger for the same-disk-multiple-partitions case.
• Non-HDD apps' "2. mentés" card shows "Nincs 2." (they're in PBS); could be hidden for them.
• The README backup-paths section still has stale restic/secondary text (flagged inline) — worth a pass.
• Full readable-data restore e2e vs AdventureLog couldn't run on the 8 GB demo rootfs (images too big); the gate + recreate are unit/integration-tested and the fail-closed path is proven live.