diff --git a/LIVE-DRIVE-FINDINGS-2026-06-14.md b/LIVE-DRIVE-FINDINGS-2026-06-14.md
index 5592c5c..3eff003 100644
--- a/LIVE-DRIVE-FINDINGS-2026-06-14.md
+++ b/LIVE-DRIVE-FINDINGS-2026-06-14.md
@@ -78,5 +78,19 @@ The demo dashboard has **no password set**, so the controller's `RequireAuth` an
 ### F8 — cloudflared `TUNNEL_TOKEN` stored in plaintext in docker-compose.yml — LOW/INFO
 - The cloudflared infra stack's compose holds `TUNNEL_TOKEN=<redacted>` in plaintext on disk (not `enc:`-wrapped like app.yaml secrets). May be acceptable for an infra/base-bringup stack, but worth confirming against the "secrets must be encrypted at rest" posture. Token redacted here. **Severity: LOW/INFO.**
 
+### F9 — felhom-usb HDD is NOT passed through to guest 9201 → HDD apps undeployable; disk APIs misrepresent it as available — CRITICAL
+- **Area:** §2 HDD deploy / §7b data migration / §11 storage.
+- **Action:** `POST /api/stacks/romm/deploy` with `HDD_PATH=/mnt/felhom-usb` (the path `/api/disks` reports). Then traced the guest/container mount topology.
+- **Expected:** an HDD-requiring app (romm) deploys onto the user-data HDD.
+- **Actual:**
+  - Deploy **rejected** at field validation: `{"ok":false,"error":"path \"/mnt/felhom-usb\" does not exist for field \"Adattárolási útvonal\""}`.
+  - **The HDD is not in the guest.** `/etc/pve/lxc/9201.conf` has only `mp0` (docker-data → /var/lib/docker) and `mp9` (bootstrap, ro). **No mountpoint for felhom-usb.** `findmnt` in the guest shows `/mnt` is just `pve-vm-9201-disk-0[/mnt]` — a subdir of the **32G rootfs**.
+  - The controller's only "drive" is `/mnt/sys_drive/felhom-data`, which `df` inside the controller confirms is on `/dev/mapper/pve-vm--9201--disk--0` (**the 32G OS rootfs**), not a data drive.
+  - **The HDD does exist on the Proxmox host**: `findmnt /mnt/felhom-usb` → `/dev/sdb1 ext4 915.8G`, containing real data (`felhom-data`, `images`, `storage`, `Dokumentumok`, …). It is host-mounted but never bind-mounted into the LXC.
+- **Source-of-truth disconnect:** `/api/disks` reports felhom-usb `state:attached, role:user-data, data_bearing:true, mount_path:/mnt/felhom-usb`; `/api/host-metrics` reports the *same* drive as `content: "backup"`. Both are the **agent's host-side view** and say "attached/reachable", but the guest/controller genuinely cannot see it. Meanwhile `/api/system/info` correctly reports `hdd_configured:false` (the controller's local view). Three endpoints, two contradictory stories about whether the customer has usable external storage.
+- **Impact:** **All HDD-requiring apps (romm, nextcloud, immich, jellyfin, paperless-ngx, plex, navidrome, audiobookshelf, komga, calibre-web, emby, sonarr, radarr — 13 of 55) are undeployable.** A user who reads `/api/disks` and enters `/mnt/felhom-usb` gets a confusing rejection. If they instead pick the offered `sys_drive`, their "external storage" app data silently lands on the **32G OS disk** — the exact failure the OS/data-split slice was meant to prevent.
+- **Root context:** the 2026-06-13 re-provision of 9201 left "RomM/USB re-enroll" as a documented pending step (CONTEXT.md); this drive confirms it was never completed **and** that the agent's disk APIs do not reflect the gap — they advertise the HDD as usable. The honest customer-facing status should be "external drive present on host but not attached to your server".
+- **Verdict:** broken. **Severity: CRITICAL** (blocks a quarter of the catalog + risks silent data-on-OS-disk placement; API misrepresents storage availability). **This is the data-migration verdict: cannot be exercised — there is no second/HDD drive attached to the guest to migrate to or from.**
+
 ### F4 — `/api/stacks/rescan` returns "stack not found: rescan" — LOW
 - The runbook's documented rescan endpoint `GET /api/stacks/rescan` is routed as a stack name lookup → `{"ok":false,"error":"stack not found: rescan"}`. Either the route was removed/renamed or the runbook is stale. (Sync/rescan is reachable via `POST /api/sync`.) Cosmetic but documents a stale/missing endpoint.