🔎 Why the facility_admin token got 200 — the auth chain read-only DB probe
Frontend test-agent session (drbrittany / stephen)→
clinical-api roles from config (drbrittany=facility_admin)→
proxy injects X-User-Id: 2 for ALL agents (GUID won't parse → default "2") + DevApiKey→
aims-api looks up user #2 in DB → 0 users (staging DB wiped)→
fallback → SuperAdmin (stale aims-api binary likely missing the fail-close guard)→
[Authorize(SuperAdmin,…)] → passes → 200
The reassuring half For REAL JWT-Bearer users the gate works — a real nurse/facility_admin 403s (their actual DB role is stamped). The hole is on the test-agent DevApiKey proxy path, not the prod login path.
The concerning half A DevApiKey request whose user can't be resolved may get SuperAdmin god-mode on aims-api (if the deployed binary/config allows the fallback). And ALL test agents collapse to user #2 — so the role-gate can't even be tested via test-agents today.
🛠 Recommended fix plan all Tier-3 → /synexar-task · do NOT auto-run
Fix 1 — config, immediate no code Set DevAuth__AllowSuperAdminFallback=false on the aims-api staging App Service → kills the god-mode fallback regardless of binary version.
Fix 2b — proxy per-agent identity code Forward the test-agent's real role (e.g. X-User-Role) so aims-api sees drbrittany≠stephen, instead of collapsing all to user #2.
Fix 3 — role catalog code Add CRNA to the 7 [Authorize(Roles=…)] attributes (CRNAs co-manage intra-op records). Anesthesiologist string is correct & exists.
Fix 4 — DB hygiene migration Dedupe physician(id 3) vs Physician(id 11) — case-sensitive gate would deny the wrong one.
Fix 2 — provision a staging anes test user SQL · needs your OK + a new multi-role auth sanity spec (drbrittany→403, samantha→200). The staging DB is empty post-wipe.