diff --git a/LIVE-POC.md b/LIVE-POC.md
index fe2f4b5..eea1475 100644
--- a/LIVE-POC.md
+++ b/LIVE-POC.md
@@ -61,14 +61,23 @@ Self-hosted on `backstage-wus2-v4` via Flux; vendor Helm chart **1.8.8**
   servers must be **registered** (run the server + dashboard "Add Server", type Arcade, URL + worker
   secret) — the tunnel pattern for local dev, or an in-cluster deploy for prod — not `arcade deploy`.
   Relevant to cat-4 (SDK/deploy), cat-8 (deployment), cat-9 (DX).
-- **Per-user Google OAuth: consent URL works, but token does NOT vault for the headless
-  `Arcade-User-ID`** (verified 2026-06-18, cat-2). `tools.authorize("GoogleDocs_CreateDocumentFromText",
-  user_id)` stays `status=pending` for both a real id (`ztaylor@servicetitan.com`) and a fresh id
-  (`gdoc-test-user`) even after completing the exact consent link in-browser (Google approval 200 →
-  coordinator callback 303 → dashboard 200, no visible error). Provider `google-docs-provider` is
-  configured (mints consent URLs; scopes userinfo.email/profile + drive.file; redirect via
-  `coordinator.arcade.st.dev`). Root cause TBD: (A) token exchange/storage fails server-side (Google
-  client secret / redirect-uri misconfig), or (B) browser consent in a dashboard-logged-in session
-  rebinds the token to the dashboard/account identity, not the headless user_id. Next: check
-  `arcade-coordinator` logs for the callback/token-exchange. **Blocks headless per-user execution for
-  OAuth tools.** (cat-1 `whoami` exec-proof uses no external OAuth, so it's unaffected.)
+- **Per-user Google OAuth — two distinct issues, both cat-2 (the load-bearing category):**
+  1. **Google provider redirect-URI / secret mismatch (RESOLVED 2026-06-22 by user).** Initially the
+     consent URL was minted but no token vaulted (`tools.authorize(...)` stayed `pending`). Cause: the
+     Google client's Authorized redirect URI / client secret didn't match the Arcade `google-docs-provider`
+     connection (Arcade re-mints a new connection id → new redirect URI on reconfigure). Fixed by matching
+     the redirect URI + re-pasting the secret in both consoles.
+  2. **Identity-namespace mismatch blocks consent binding under Entra User Source (OPEN, important).**
+     With the gateway in **User Source (Entra OIDC)** mode, a Claude Code session resolves to the **opaque
+     Entra `sub`** (`ArcadeEvalRef_Whoami` → `GvgRofe5xGzPoeS0w__hSMmBY1JkU7F6pR4yLKOP-Qk`). When the user
+     completes the downstream Google consent in a browser signed into the Arcade dashboard as
+     `ztaylor@servicetitan.com`, Arcade's callback **refuses to bind**: *"Your code provided the user ID
+     GvgRofe5… but the currently signed-in Arcade account is ztaylor@servicetitan.com."* Correct safety
+     guardrail (no cross-user token grants), but it means the **gateway User Source keys user_id on the raw
+     `sub`, while the dashboard/coordinator login resolves the same Entra person to `email`** — so agent
+     identity ≠ consent-completer identity. **Likely fix:** configure the Entra User Source to map user_id
+     to the `email`/`preferred_username` claim (so `whoami` = `ztaylor@servicetitan.com`, matching the
+     dashboard). Until aligned, downstream OAuth consent can't complete for a User-Source agent session.
+     **This is a key cat-2 / identity-mapping finding** and also bears on cat-10 (what string the vault is
+     keyed on for multi-tenancy). Headless **Arcade-Headers** mode is unaffected (you pass the email
+     directly as `Arcade-User-ID`, which matches).