diff --git a/workplans/KEY-WP-0014-native-credential-lane-handoff.md b/workplans/KEY-WP-0014-native-credential-lane-handoff.md
index c5307cf..c099525 100644
--- a/workplans/KEY-WP-0014-native-credential-lane-handoff.md
+++ b/workplans/KEY-WP-0014-native-credential-lane-handoff.md
@@ -136,3 +136,26 @@ Steps 1-3 remain custody's and are deliberately not automated. Task stays `wait`
 on exactly two answers: which option ops-warden takes for the login proxy, and
 who executes the successor generation and CAS update under what authority. No
 route changed.
+
+Both catalog corrections were sent, receipts readable via
+`GET /messages/?from_agent=key-cape`:
+
+- `12f1bdfa-b240-414b-aa49-128a4d2acf20` — accepts ownership of lane
+  `key-cape-oidc-login`, answering the WARDEN-WP-0033-T04 follow-up they have
+  carried as `asked-and-waiting` since 2026-08-28. States the boundary the lane's
+  `fetch_command` crosses: key-cape owns browser authentication and the identity
+  token; the `netkingdom` auth mount, `role=<domain>` mapping, token store and
+  enforcement of the resulting OpenBao token are not ours. Supplies the source
+  paths they need to move the lane to `verified: source-read`, and records our
+  revised, lower estimate of the consumer risk — a pointer lane under ADR-0001
+  retires nothing when `keycape login` runs alongside it — while asking them to
+  correct us if the catalog understates its consumers.
+- `08d42f47-8e19-4976-98f5-dd259e7b1225` — reports lane
+  `rapp-qonto-keycape-client`'s blocker as stale against its 2026-08-28
+  source-read, since `keycape service-token` is the native `client_secret_basic`
+  exchange it records as absent and `keycape verify-client` is its rotation step 3
+  verbatim. Asks them to **narrow** it to steps 1-2 rather than clear it, with
+  proposed replacement text, and notes `rotation.automatable: true` is now
+  half-true and should say so precisely rather than be flipped either way.
+
+Neither message asks for a route change and neither was one.