# REPORT — agent v0.22.0: expose durable_id in GET /disks (2026-06-11)

**Repo:** `felhom-agent` · **Version:** 0.22.0 · **Pushed commit:** `4734d4a` · paired with
`felhom-controller` v0.43.0 (the controller-side storage-management rebuild that needs this).

## What shipped (one read-only field)

`internal/localapi/DiskInfo` gains `durable_id` (mapped directly from `StorageTarget.DurableID` — e.g.
`"uuid:<fs-uuid>"` for usb/local-dir, `"path:…"`/`"store:…"` otherwise). That's the entire change.

**Why it's necessary:** the de-privileged controller cannot read a device's filesystem UUID itself, yet
`POST /disks/assign` mounts **strictly by fs UUID** (`EnsureMount` → `/dev/disk/by-uuid/<UUID>`). Without
the UUID surfaced somewhere the controller can reach, the guided init/attach flows could not complete the
mount. `GET /disks` already carried everything else (name/type/state/device/mount/class/data_bearing) but
dropped the durable id. The controller strips the `uuid:` prefix to get the assign key.

**Security:** no new privilege, no subprocess, no behaviour change to `format`/`assign`/`eject` or the
data-bearing signature gate. The agent still inspects the device itself at format time and refuses a
data-bearing wipe with a `pending_op` (the controller surfaces the `felhom-opsign` command).

## Validation (live, guest 9201)
`GET /disks` (via the controller's `/api/disks` proxy) now returns `durable_id` per disk, e.g.
`felhom-usb` → `/dev/sdb1`, `data_bearing:true`, `durable_id:uuid:277a2179-a764-4758-b840-9ea741517914`.
The controller's guided init on `sdb` correctly drove the agent to a **data-bearing refusal** (HTTP 403 →
`pending_op{op:storage_wipe, host_scope:demo-felhom-01, durable_id:byid:wwn-0x5000039ddb108568-part1}`),
which the controller surfaced as the operator `felhom-opsign` command — the gate held end-to-end.

## Notes
This pairs with the controller's storage-management rebuild (build-golden default bumped to controller
0.43.0; golden rebaked). No other agent change.