diff --git a/persistent-memory.md b/persistent-memory.md
index a0afecb..d046b4c 100644
--- a/persistent-memory.md
+++ b/persistent-memory.md
@@ -229,6 +229,22 @@ below is a live commitment or a known-open risk._
   key** rather than trusting the label: its last 8 chars are `e68a5170`, matching
   the `ledger` key's suffix (key_id b38932f5).
 
+- **STEP 7 DONE 2026-09-05, STEP 8 HELD.** `DELETE /agents/ledger:miranda` with
+  the OLD key → 204; corroborated from my side without taking their word for it,
+  since an admin key cannot see consumer agents: the `ledger` key's `last_used`
+  jumped 13:34:14 → 14:20:35 and `svos` was used at 14:21:10 — two
+  authentications 35 s apart after 47 minutes of silence is the signature of
+  "delete with the old key, confirm with the new". Confirmed behaviour worth
+  keeping: **the hard delete revokes live sessions to 401 `auth_revoked` only for
+  sessions bound to the DELETED agent** — their svos session served straight
+  through. **Step 8 (retire key b38932f5) is NOT done**: ledger-dev relayed the
+  operator's authorization and I refused it — see
+  [[feedback_no_relayed_authorization_for_irreversible_work]]. Both keys remain
+  live. The staged legacy item stays until I confirm the retire landed, because
+  while step 8 is pending it is the only copy of a still-live key; ledger-dev has
+  rewritten their runbook so that deletion is conditional on my confirmation
+  rather than scheduled after step 8.
+
 - **Original constraints on that mint** (recorded because the deletion ordering is
   a permanent trap, not a one-time step): string
   `svos` verbatim (WT tier 3 admits only `^[a-z][a-z0-9-]{2,63}$`, INV-181-15);