Session log: Cascades CA bypass phased rollout + pilot user + phone re-enroll

Cascades caregiver shared-phone bypass pilot — 2026-04-29 evening into
2026-04-30 early morning continuation.

Major work:
- Adopted phased per-group CA rollout (corrects original tenant-wide §5
  design that would have blocked off-site office users)
- Step A: backfilled admin@ into excludeUsers on all 8 existing Cascades
  CA policies (mirrors sysadmin@ exclusion posture; Option 1 break-glass)
- Outlook + Helpany + LinkRx assigned to Cascades - Shared Phones group
  and added to MHS kiosk app list (final dashboard: 5 caregiver apps)
- Created cloud-only pilot user pilot.test@cascadestucson.com,
  SG-Caregivers-Pilot group, Business Premium license, vault entry
  pushed to Gitea vault repo
- Built 4 CA changes: PATCH legacy all-users-MFA to exclude pilot group,
  CREATE 3 new Report-only policies (block off-network, block
  non-compliant, 8h sign-in frequency) with both admins excluded
- Pilot phone wipe + re-enroll after first attempt stuck; PIN set,
  awaiting MHS to take over launcher and SDM sign-in prompt

6 new project/feedback memories. Resume point at top of new session log.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.claude/memory/feedback_graph_ca_policy_eventual_consistency.md

@@ -0,0 +1,17 @@
+---
+name: Microsoft Graph CA policy reads are eventually consistent (~5s)
+description: After PATCHing a CA policy (204 No Content), an immediate GET may return stale state. Wait ~5 seconds before verifying.
+type: feedback
+---
+
+When PATCHing `/identity/conditionalAccess/policies/{id}` and immediately re-reading via GET, the read may return pre-PATCH state for a few seconds even though the PATCH was accepted (204).
+
+Observed 2026-04-29 during the Cascades admin@ exclusion backfill: 7 of 8 PATCHes returned 204, but immediate verify GETs showed the old `excludeUsers` list. Re-query after `sleep 5` showed all 8 had landed correctly. No retries were needed — the PATCH had succeeded; only the read lagged.
+
+**Why:** Microsoft Graph fronts CA policy reads through a regional cache that doesn't immediately reflect writes. Writes hit the authoritative store and return 204 right away. Reads converge after a short propagation window.
+
+**How to apply:**
+- After a CA policy PATCH that returns 204, do not treat an immediate "verify mismatch" as failure.
+- Insert `sleep 3-5` (or a poll loop with a few seconds of backoff) before the verify GET.
+- If verifying many policies in a batch, the simplest pattern is: do all PATCHes, sleep 5, then re-query everything once at the end.
+- This applies to CA policies specifically. Other Graph endpoints (e.g., users, groups) have their own consistency characteristics — don't generalize.