diff --git a/docs/file-system-development/storage-architecture.md b/docs/file-system-development/storage-architecture.md
index c232a72..c1ae20b 100644
--- a/docs/file-system-development/storage-architecture.md
+++ b/docs/file-system-development/storage-architecture.md
@@ -28,7 +28,7 @@
 > crashes while its device stays present (a channel-liveness `geometry()` probe
 > reaps the volume and rebuilds it on the restarted driver's fresh channel). The
 > re-adopt-and-remount path is QEMU-proven by the driver-crash rebuild; a physical
-> unplug/replug exercises the same path and is bench-verified (QEMU cannot
+> unplug/replug exercises the same path but is bench-pending (QEMU cannot
 > re-present a usb-storage `device_add`). **Still pending**: the `filesystem UUID`
 > rung (ext-family superblocks, which need such an engine); and arbitration when
 > two volumes both resolve the boot markers (S3 mounts both and logs each claim;
diff --git a/docs/file-system-development/storage-design-rationale.md b/docs/file-system-development/storage-design-rationale.md
index 430d7c5..838ae89 100644
--- a/docs/file-system-development/storage-design-rationale.md
+++ b/docs/file-system-development/storage-design-rationale.md
@@ -251,8 +251,9 @@ matrix-proven shape; genuinely open.
    whether USB port, hub depth, SATA port, or a stick that left as USB and
    returned in a SATA dock; **replug remounts at the same path** (the id-path is
    content-derived, so a volume returns to `/volumes/<id>` wherever it reappears;
-   remount-on-replug end-to-end is bench-verified, not QEMU-tested, because QEMU
-   can't re-present the boot-controller device); **the boot volume** is the volume
+   the re-adopt+remount code path is QEMU-proven by the driver-crash rebuild, but
+   remount on a *physical* replug end-to-end is bench-pending, not QEMU-testable,
+   because QEMU can't re-present the boot-controller device); **the boot volume** is the volume
    that resolves `/system/configuration` on its own media, findable on any port or
    partition; and **duplicate identity is a known S4 gap** — two cloned sticks
    share one content id, so today they collide on `/volumes/<id>` (the kernel