#Open questions — DOC-MOD-AUTH
Copied from docs/modules/MOD-AUTH.md § Needs human clarification. Resolve by accepting docs/adr/ADR-002-acc-auth-surface.md (ACC-AUTH-SURFACE, currently status open) before implement treats activation or credential cutover as decided. The same ADR closes DOC-OVERVIEW HQ-2 and DOC-ARCHITECTURE HQ-1.
| Id | Question | Why unclear (plain + IR) | Impact |
|---|---|---|---|
| HQ-1 | For ACC-AUTH-SURFACE, do we preserve Bubble signup activation (confirm email off + custom Verify email deep-link to onboarding with active=yes) or replace it with Supabase Auth confirm-email, and what is the cutover plan for existing Bubble passwords? |
Plain: Behavior of signup, verify email, and when profiles.active becomes true is encoded clearly in the export, but the target provider and cutover are a product/platform choice the metadata cannot make. IR: SignUp sets send_confirm_email false and writes role + approve false only (bTHpx1); SendEmail subject “Verify” body links onboarding?nav={role}&active=yes (bTHqT1); onboarding PageLoaded sets active true when param active=yes and currently inactive (bTHsZ1 / bTHse1). ACC-AUTH-SURFACE is a needs_adr decision (preserve vs replace + forced reset / dual-run / IdP cutover), not catalog evidence. |
blocks_implement |
#Chase notes (HQ-1)
| Catalog ref | Pointer | Finding |
|---|---|---|
bTHpx1 |
/pages/bTGbC/workflows/bTHjk1/actions/0 |
SignUp send_confirm_email: false; changes role + approve1_boolean false only |
bTHqT1 |
/pages/bTGbC/workflows/bTHjk1/actions/2 |
SendEmail subject Verify; body → onboarding?nav= + role + &active=yes |
bTHsZ1 / bTHse1 |
/pages/bTHDr0/workflows/bTHsd1 (+ /actions/1) |
PageLoaded when active=yes and inactive → set active__boolean true |
needs_adr note: ACC-AUTH-SURFACE (assessment seed) names provider preserve-vs-replace and cutover options (forced reset / dual-run / IdP). It is not a catalog ref and is not listed under chase evidence — the decision record is docs/adr/ADR-002-acc-auth-surface.md (options A–E, status open), which must be accepted before implement.
Suggested options: preserve Bubble activation chain; replace with Supabase confirm and name when profiles.active flips; cutover via forced reset, dual-run, or IdP bridge.