felhom-controller/REPORT.md

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.