Live drive: §6/AGENT-001 — gate PASS, but swallowed-error + durable_id mismatch + large-disk timeout corrupts disk (F20)

LIVE-DRIVE-FINDINGS-2026-06-14.md

@@ -168,5 +168,16 @@ The demo dashboard has **no password set**, so the controller's `RequireAuth` an
 - **Full removal** (code-server): stop → remove → container gone, no orphaned volume (`docker volume ls` empty), `state=not_deployed`, route `code.demo-felhom.eu` → 404 (Traefik route withdrawn with the container). Remove response carries explicit data-handling fields (`volumes_removed`, `hdd_paths_removed`, `hdd_paths_preserved`). **PASS.**
 - **Verdict:** removal and protection guards work correctly. **Severity: INFO (PASS).**
 
+### F20 — AGENT-001 wipe gate: refusals + correct-device targeting PASS; but format error-reporting + large-disk timeout are broken — MIXED (gate PASS, execution HIGH)
+- **Area:** §6 / AGENT-001.
+- **Refusal A (no confirmation):** `POST /api/disks/format {device:/dev/sdb1, fstype:ext4}` → `formatted:false, needs_confirmation:true, "customer confirmation required"`, **HTTP 409**. No mkfs. **PASS.**
+- **Refusal B (wrong durable_id):** `+confirmed:true, durable_id:byid:wwn-0xDEADBEEF…` → `formatted:false, "operator authorization required"`, **HTTP 409** (agent log: `reason=binding_mismatch`). A non-matching confirmation does not authorize. **PASS.**
+- **Gate authorization (correct durable_id):** with `confirmed:true, durable_id:byid:wwn-0x5000039ddb108568-part1` the agent gate progressed `pending_confirmation → binding_mismatch → customer_confirmed allowed=true` and targeted the **correct re-resolved device** `/dev/sdb1`. The anti-retarget durable_id resolution works. **PASS (gate logic).**
+- **BUG 1 — swallowed format error (HIGH):** the first confirmed attempt failed because `/dev/sdb1` was mounted (`mkfs.ext4 … is mounted; will not make a filesystem here!`, agent logged `level=ERROR`), yet the **API returned `ok:true`** with `formatted:false, device:"", reason:""`. The failure was not propagated — a caller/UI would read it as success while nothing happened.
+- **BUG 2 — durable_id scheme mismatch across endpoints (MEDIUM):** `/api/disks` reports this drive's durable_id as `uuid:277a2179-…`, but the format gate expects/returns `byid:wwn-0x5000039ddb108568-part1`. A customer/UI copying the id from the disk list would always be refused (`binding_mismatch`). The two APIs disagree on the durable_id scheme.
+- **BUG 3 — large-disk format times out and leaves the disk corrupt (HIGH):** after unmounting (the gate won't unmount itself), the confirmed format on the 915GB drive ran mkfs, but the **controller→agent call timed out** (`agentapi: POST /disks/format … context deadline exceeded`, HTTP 502). The cancelled request context **killed the in-progress mkfs** (agent log: `mkfs.ext4 … signal: killed`). Result: `/dev/sdb1` is left **half-formatted** — old fs/UUID/LABEL destroyed, `blkid` shows only PARTUUID, `mount` fails `bad superblock`. The disk is neither cleanly wiped nor usable. For a real customer wiping a large drive this corrupts it.
+- **Net:** AGENT-001's *security* properties (refuse without confirmation, refuse wrong durable_id, target the durable_id-resolved device) are intact and were proven on the correct device. But the *format execution path* has two real defects (silent failure on mounted device; timeout-kill leaving a corrupt fs on large disks). **Severity: gate PASS; execution HIGH.**
+- **Disk final state:** felhom-usb (/dev/sdb1) old data destroyed, left without a valid filesystem (see "Final state" section).
+
 ### 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.