# REPORT — felhom-controller: slice 10 (external user-data drives) — controller side

**Version:** 0.50.0 · **Date:** 2026-06-12 · pairs with **felhom-agent v0.25.0–v0.27.0**

The controller's half of slice 10 (the agent owns the host-side execution + self-heal; see
felhom-agent's REPORT for P1 spike / P2 passthrough / P2 activation endpoint / P3 self-heal). All
live-validated on guest 9201; golden rebaked to 0.50.0.

## P2C — enroll passes the drive into the guest (v0.48.0)
- `agentapi.GuestAttach(where)` → agent `POST /disks/guest-attach`. `runStorageInit` /
  `runStorageAttach` / `handleStorageRegister` call `attachIntoGuest` after recording the StoragePath
  (best-effort; a transient failure is logged — P3 self-heal completes it). Closes Branch A: an enrolled
  drive becomes usable in the guest (app `HDD_PATH` writes land on `/dev/sdb1`; the "nem elérhető"
  banner clears).

## Activation-UX (v0.49.0)
- The host-side live inject is blocked on unprivileged LXC, so a drive enrolled into a *running* guest
  activates at the next guest boot. Per decision: enroll persists (no forced reboot) + a user-triggered
  restart.
- `pendingActivationDrives()` flags registered drives the agent reports present+attached but which
  aren't a live mount in the container. The settings page shows a banner + a batched **"Újraindítás
  most (~30 mp)"** button → `POST /api/storage/activate` → `agentapi.GuestReboot` → agent
  `POST /guest/reboot`. Live-validated: activate → guest reboots → drive active.

## P4 — dual-role drives + backup-aware wipe warning (v0.50.0)
- **4A:** a user-data drive is appdata AND backup-target-eligible (not locked to one role) — surfaced
  in the drive overview's per-card purpose note. `felhom-pbs`/system/backup roles unchanged.
- **4B:** `handleStorageImpact` now also returns `backup_copies` — apps whose cross-drive (secondary)
  backups are stored on the drive (`backupCopiesOnPath` scans `felhom-data/backups/secondary/<app>`,
  skipping the shared restic repo / `_infra`). The type-to-confirm wipe/eject modal names them ("Ez a
  meghajtó más alkalmazások biztonsági másolatait is tárolja — a törlés ezeket is eltávolítja"). The
  wipe stays **customer-confirmable** (the copies are redundant; originals live on the source drive).
- **OUT OF SCOPE:** the cross-drive backup ENGINE (restic USB1↔USB2, scheduling, pruning) — a follow-on
  slice (needs a 2nd physical drive to validate). The 4B detection is forward-compatible (empty until
  the engine writes there).

## Live validation (9201)
- P2C: app bytes on `/dev/sdb1`, banner `[PASS] 1 connected, 0 disconnected`.
- Activation: `/api/storage/activate` → reboot → drive active.
- P4: `/api/storage/impact?where=/mnt/felhom-usb` → `backup_copies:[]`; after creating
  `felhom-data/backups/secondary/immich` → `backup_copies:["immich"]` (detection live).
- `go test ./internal/{web,agentapi}/` green; golden rebaked to 0.50.0, build guest purged.

## Note (carried from P2)
The controller's app/backup path helpers still join `felhom-data` under the registered drive path; in
Model A the in-guest mount IS the felhom-data namespace, so backup paths double-nest
(`felhom-data/felhom-data/...`) — functional but untidy. Reconcile when wiring app-data-backup-to-drive
(not in this slice; app `HDD_PATH` data lands correctly today).