# REPORT — felhom-controller v0.45.0: storage UX polish (order, init filter, register shortcut, clarity) **Repo:** `felhom-controller` · **Version:** 0.45.0 · **Date:** 2026-06-12 · pairs with **felhom-agent v0.24.0** Part B of the storage-fixes spec — controller-side ordering/filter/clarity polish on top of v0.44.0's role-aware drive management. (Part A, the eject role-gate, lives at the agent — see felhom-agent v0.24.0 / its REPORT.) ## What changed ### B1 — deterministic disk order (`internal/web/agent_disk_handlers.go`) `agentDisksListHandler` sorts the agent's drive list server-side before rendering (`sortDisksForView`): **user-data → system → backup** (then unrecognized), alphabetical by storage name within each tier. The agent's storage view iterates an unordered Go map, so the list previously reordered on every reload (CLAUDE.md lesson #3). A stable Go-side contract beats relying on map order or template JS. Test: `TestSortDisksForView`. ### B2 — init wizard excludes mounted drives (`templates/storage_init.html`) The `formattable` filter gained `&& !d.mount_path` (matching the attach wizard): an already-mounted drive (e.g. `felhom-usb`) no longer appears as an "initialize" candidate. Eject it first to make it an init target. ### B3 — register shortcut for a mounted-but-unregistered user-data drive - New `POST /api/storage/register` → `handleStorageRegister` → reuses `registerStoragePath` (the manual-add path): records the existing mount into the `StoragePath` registry (no format, no eject), then FileBrowser-syncs. `AddStoragePath` dedupes (clean error on double-register). - `settings.html`: a mounted, **unregistered** user-data drive now shows **Regisztrálás** as its PRIMARY per-card action; Leválasztás/Törlés stay secondary. ### B4 — system-storage clarity (presentation only, `settings.html` + `style.css`) `local` and `local-lvm` are both kept (not collapsed). Each card now carries: - a plain-Hungarian **purpose description** keyed on the agent's `type`/`role` (`purposeDesc`): local-lvm → internal SSD (system, Docker, app **databases**); local → host storage, **no app data**; pbs → backups; user-data → external store for large app files. - an **app-backing tag** (`appBackingTag`): `local-lvm` → "Alkalmazás-rendszer"; user-data → "Alkalmazás-adatok". - a one-line **tiering note** above the list answering "which storage do the apps use?". Role/type stay authoritative from the agent — no agent contract change. ### B5 — eject confirmation names affected apps Already wired pre-existing: `confirmEject` → the type-to-confirm modal fetches `/api/storage/impact` and lists, by name, the deployed apps that lose their storage (parity with the wipe warning). Verified, no code change needed. ## Build / deploy - Built `felhom-controller:0.45.0` on the build server (`build.sh 0.45.0 --push`). - Deployed to **guest 9201** on `felhom-pve`: `docker pull`, updated `/etc/felhom-controller-image`, re-ran `felhom-controller-bootstrap.sh` → container recreated on `0.45.0`, **healthy**; `[selfupdate] Current version 0.45.0 is up to date`. - CHANGELOG (newest on top) + `controller/README.md` (Storage Management section) updated. ## Live validation (guest 9201, auth disabled on this demo → API reachable) - **B1 order:** `GET /api/disks` returns `[felhom-usb(user-data), local(system), local-lvm(system), felhom-pbs(backup)]` — **stable across 3 reloads** (user-data first, system alpha, backup last). - **B2 filter:** the only user-data drive (`felhom-usb`) has a `mount_path`, so the new filter excludes it from init candidates (confirmed by the live disk data). - **B3 register:** `POST /api/storage/register {where:/mnt/felhom-usb}` → `{registered:true}`; `settings.json` now lists `/mnt/felhom-usb` (label "Tárhely (felhom-usb)", schedulable); `FileBrowser mounts synced — 1 storage path(s)`. - **B5 impact:** `GET /api/storage/impact?where=/mnt/felhom-usb` → `{apps:[], where:…}` (valid wiring; no deployed app currently routes data there). - **B4 clarity:** pure presentation rendered client-side from the agent's role/type (templates parse-tested; the disk data carries the keys the JS branches on). Visual confirmation is a browser check. - `go test ./...` green for the whole module. ## Not done / human step - **Golden rebake** (to bake controller 0.45.0 into new-guest templates): NOT performed — `felhom-pve` has no registry credentials (`REGISTRY_USER`/`REGISTRY_TOKEN`, stored out-of-band) and there is no golden archive currently on the host. Controller **self-update covers the drift** (a freshly provisioned guest would self-update to 0.45.0), so existing + new guests converge regardless. The rebake remains a human/credentialed operational step.