diff --git a/TEST-REPORT.md b/TEST-REPORT.md
index 00ab4f7..a1b63a5 100644
--- a/TEST-REPORT.md
+++ b/TEST-REPORT.md
@@ -110,7 +110,23 @@ State: 9201 healthy throughout, controller up, tunnel up (verified before + afte
 | Cleanup | PASS | `pct stop 9300 && pct destroy 9300` → both LVs removed; `pct list` shows only 9001/9201/9999; local-lvm freed to 9.71% |
 
 **Core DR claim proven end-to-end:** PBS whole-CT restore → guest boots → controller + all app stacks + DB data recovered from restored volumes — twice (agent self-cleaning primitive + manual deep inspection), both collision-safe per §0.6.
-## Phase 5 — Storage lifecycle — _pending_
+## Phase 5 — Storage lifecycle — **PARTIAL (blocked by a controller→agent connectivity defect)**
+
+State: 9201 healthy, controller up, tunnel up. Agent (`felhom-agent v0.39.0`) healthy on the host.
+
+### 🔴 HEADLINE FINDING — controller cannot reach the agent local API (8443)
+The controller container's calls to the agent local API fail: `agentapi: GET /disks: dial tcp 192.168.0.162:8443: connect: cannot assign requested address` (and same for `/host/metrics`). Reachability matrix **from the controller container**:
+- `192.168.0.162:8006` (Proxmox pveproxy, binds `0.0.0.0`) → **200** (reachable)
+- `192.168.0.162:8443` (felhom-agent local API, binds **`192.168.0.162`** specifically) → **refused/EADDRNOTAVAIL**
+- `192.168.0.141:443` (guest's own traefik) → 404 (reachable)
+From the guest **host namespace**, `192.168.0.162:8443` is OPEN. So the agent is up and listening, but its 8443 socket is unreachable specifically from the **docker container** path while 8006 on the same host is fine — consistent with the agent binding only to the host LAN IP vs a NAT/interface mismatch on the container→host path. **Confirmed:** `ss` shows agent `LISTEN 192.168.0.162:8443` (bound to the specific LAN IP, not `0.0.0.0` like pveproxy:8006); **no** iptables rule references 8443; pve-firewall disabled. So it is not a firewall — likely a container→host-IP routing/source-bind mismatch (the docker-NAT'd path to the host's own `.162` fails for the agent socket while pveproxy's `0.0.0.0` socket is reachable). Suggested fix direction (supervised): bind the agent local API to `0.0.0.0` (or the vmbr0 bridge address the guest routes through), or point the controller's `local_api.endpoint` at a container-reachable address. **Impact: the whole agent-backed feature set is down in this demo** — storage management UI (`/api/disks`, `/api/storage`), host metrics (monitoring "gazdagép metrikái nem elérhetők"), and whole-guest backup ("A host-ügynök jelenleg nem elérhető"). **Needs supervised network/bind diagnosis** (likely agent listen-address or PVE firewall on 8443). Not fixed unattended (network reconfig is out of scope per §0.1/§0.8).
+
+| Check | Result | Evidence |
+|---|---|---|
+| Scan / observe / health / FS / model / durable_id (agent tier) | PASS | `--selftest=storage`: 5 targets — felhom-flash (usb, attached, class=slow, `uuid:81a26531…`, /dev/sdc1, /mnt/felhom-flash); **felhom-usb (local-dir, `uuid:da9e7089…`, /dev/sdb1, SMART=PASSED temp=35 poh=2736 realloc=0)**; local-lvm (thin data=9.7% meta=0.8%); felhom-pbs (21%); local. All `reach=true` |
+| Label edit + revert (via UI) | SKIPPED | blocked — controller→agent path down (headline finding); UI storage mgmt non-functional |
+| Eject → re-enroll cycle (via UI) | SKIPPED | blocked — same; not driven directly at agent-tier (would mutate live-drive state via the broken path; unattended caution per §0.7) |
+| Destructive loopback (scan→format→mount→migrate→decommission) | SKIPPED | the init wizard drives the agent via the broken path; doing it purely agent-side needs the per-guest local-API token + TLS-pin reconstruction — high-effort/low-confidence unattended. Deferred to supervised. No scratch loopback was created (nothing to clean up). |
 ## Phase 6 — Monitoring/alerts/hub — _pending_
 ## Phase 7 — Resilience (optional) — _pending_