diff --git a/workplans/WARDEN-WP-0033-native-lane-handoff.md b/workplans/WARDEN-WP-0033-native-lane-handoff.md
index 719205a..52eb47d 100644
--- a/workplans/WARDEN-WP-0033-native-lane-handoff.md
+++ b/workplans/WARDEN-WP-0033-native-lane-handoff.md
@@ -156,7 +156,7 @@ railiance-platform may deny more, deny less, or dispute a grade (`ADR-0002`).
 
 ```task
 id: WARDEN-WP-0033-T04
-status: todo
+status: wait
 priority: medium
 ```
 
@@ -177,6 +177,23 @@ Note the interaction with `ADR-0004`: the agent read-boundary already depends on
 side. A real issuance identity is what would make that boundary hold on the
 OpenBao side too, so ops-warden is an interested consumer, not a bystander.
 
+**Routed 2026-08-21 to `key-cape` (msg 903b2223); waiting on accept or refuse.**
+Reasoning given: it is an identity and issuance question about a principal
+authenticating to OpenBao, which is key-cape/Keycloak's. The precedent is an hour
+old and runs the same direction — `secrets-engine` declined `key-cape-oidc-login`
+as ops-warden's to hand them, on the grounds that login and identity-token
+issuance stay with key-cape. Absorbing this would contradict agreeing with them.
+
+Named the adjacent parties explicitly rather than leaving them to inference:
+`zone-engine` has an interest (a coding-agent identity is a strong candidate zone
+subject) and `user-engine` is **not** involved — this is a machine principal, not
+an end-user account. Stated so nobody concludes it by elimination.
+
+Asked for a refusal-with-pointer as an equally good answer. The failure mode to
+avoid is the 2026-08-17 one recorded in `.claude/rules/finding-routing.md`:
+ops-warden answered a question well and never routed it, and another repo ended
+up filing it.
+
 ## Related
 
 - `secrets-engine` `SECRETS-WP-0006` — catalog admission, decision `ae676382`