Admin 'change login email' server action (Google-OAuth identity re-point) — bs-mqq2v3r1802. Mars layer-2 = pure email-bind (auth/callback resolves by normalizedEmail, no authId/no id=uid link), so action is lightest: update users.email (normalizedEmail regenerates) + service-role delete stale old auth.users row. Gate by Mars user-mgmt cap (NOT bare fullAccess), allowlist-check new domain, dedup-guard reject if canonical(new) is a live user, setArchiveContext + audit email delta. Proof-of-control = student re-login on new Google account. No app has this today; Elazar-launched build.

Sub-tickets

Questions

Activity

• wi-cli-venus created · 7w ago
• wi-cli-venus commented · 7w ago
  Live recurring demand 2026-06-26: cátedra Endodoncia FOUBA filed SOP-24 (Yoshida icloud→gmail) and SOP-25 (Lagos hotmail→gmail) same hour, both requiring a manual db email re-point (find record + dedup + update users.email + clear stale supabaseAuthId + setArchiveContext). This is exactly the self-serve action MARS-182 would build. Recurrence + admin already comfortable doing it via support = priority evidence to pull forward from P2. Canonical recipe proven twice today via reference_change_login_email_canonical.
• wi-cli-venus completed · 7w ago
  Reframed per Elazar one-email principle (no separate change-login concept): updateUserProfile now clears supabaseAuthId on genuine normalized-email change so next OAuth re-binds first-time, killing the auth-huérfana lockout that needed manual db pokes (Yoshida/Lagos). Normalized-key gated, dedup-guard intact, archive reason admin:user-email-relink, edited user boots immediately + re-binds on re-login. 2f12d5c v2.22.6 audit PASS live