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