# REPORT — controller v0.80.0: disk card shows + acts on the stable path

## Baseline
- felhom-controller `main` @ `9596c8e`, **v0.79.0 → v0.80.0**. Trunk-based, `main`.
- Follow-up to v0.78.0 (stable-path registration) + v0.79.0 (registered badge on stable path).

## Problem (operator-reported, screenshot)
The storage disk card still displayed each external drive's **raw** host PVE mount `/mnt/<name>`
(`usb · /dev/sdc1 · /mnt/felhom-flash`). Inside the guest/controller the drive lives at the **stable**
path `/mnt/felhom-drives/<name>` (the agent's `guest_path`) — which is what the registry, app `HDD_PATH`,
and FileBrowser use; the raw path doesn't even exist in the guest. Two latent bugs rode on the same
mismatch: the Leválasztás/Törlés buttons posted the **raw** path, so `handleStorageEject`/`handleStorageWipe`
would unmount the drive but `RemoveStoragePath(raw)` would miss the **stable** registry entry (orphan);
and the impact warning `/api/storage/impact?where=raw` found no apps (HDD_PATH is the stable path).

## Fix
**`controller/internal/web/templates/settings.html`** (disk-view JS):
- Card sub-line now shows `regKey(d)` (= `d.guest_path || d.mount_path`) — the stable in-guest path.
- `actions()` passes the **stable** path to `confirmEject`/`confirmWipe` (handlers map it to raw for the
  agent via `agentWhere()` AND deregister the stable registry entry). `registerDrive` keeps the **raw**
  `mount_path` (its agent guest-attach operates on raw; `handleStorageRegister` maps to stable).
- `confirmEject`/`confirmWipe` derive the type-to-confirm name from the **basename**
  (`where.split('/').filter(Boolean).pop()`) so it still equals the server's `path.Base(where)` check
  when `where` is the stable path.

**`controller/internal/web/storage_handlers.go`** (`handleStorageWipe`):
- The agent eject now uses `agentWhere(req.Where)` (was `req.Where` verbatim), matching
  `handleStorageEject`. So a stable registered path maps to the raw mount for the agent while
  `RemoveStoragePath(req.Where)` deregisters the stable entry. Agent op is the identical raw path as
  before; only the registry bookkeeping is corrected. The format step is unchanged (keyed on `device`).

Agent-facing operations (eject unmount, format) produce the IDENTICAL raw paths/device as before — only
the controller's display + its own registry bookkeeping/impact lookups now use the stable path.

## Tests
- `go build ./... && go vet ./... && go test ./...` — **all green** (incl. `TestTemplatesParse`).
- `handleStorageWipe`'s new mapping rides on `agentWhere`, already covered by `TestAgentWhere`
  (stable→raw, raw idempotent). JS changes covered by template parse (no JS unit harness — existing
  pattern).

## Deploy (v0.80.0 → guest 9201)
- _(filled at deploy)_ built+pushed `:0.80.0` on 192.168.0.180; deployed to 9201; `:0.80.0 Up (healthy)`.

## Verification
- _(filled at verify)_ disk card sub-line shows `/mnt/felhom-drives/felhom-flash` (+usb); the rendered
  eject/wipe button onclick args carry the stable path; "Regisztrálva" intact; `2 connected`.
- NOT live-clicked: the destructive eject/wipe buttons (would unmount/format the demo drives). Verified
  the path-mapping logic by inspection + the agent ops are unchanged (raw via `agentWhere`/device).

## Observations (recorded, NOT acted on)
- `pendingActivationDrives` still keys off the agent's raw `MountPath` (the "~30 mp újraindítás" banner);
  obsolete in the live-activating intermediary model — key off `GuestPath`/`BoundUnderParent` or retire.
- Free-form settings storage-add (`handlers.go`) registers a user-typed path verbatim (advanced flow).