Problem
Auth is email + password ≥6 chars only (frontend/src/utils/AuthContext.tsx:51-67, modal at frontend/src/app/ChatPage.tsx:1018-1049). There is:
- no OAuth provider (Google/GitHub/etc.)
- no magic-link sign-in
- no forgot-password / reset flow
- no email verification step beyond Supabase defaults
This blocks adoption (signup friction) and traps users out (no recovery). Both flows are first-class in Supabase already; we just don't surface them.
Proposed approach
- Google OAuth: enable Google provider in the Supabase project; add a "Continue with Google" button in the auth modal calling
supabase.auth.signInWithOAuth({ provider: 'google' }). Configure redirect URL for both production and PR-beta domains.
- Magic link: add an "Email me a link" toggle in the auth modal that calls
signInWithOtp({ email }). Friendlier than passwords for occasional users.
- Password reset: add a "Forgot password?" link beneath the password field that calls
resetPasswordForEmail and shows a confirmation. Implement the redirect target page that captures the new password.
- Keep email+password as a fallback for users who prefer it.
Acceptance criteria
Out of scope
Other OAuth providers (GitHub, Microsoft) — add later if requested.
Problem
Auth is email + password ≥6 chars only (
frontend/src/utils/AuthContext.tsx:51-67, modal atfrontend/src/app/ChatPage.tsx:1018-1049). There is:This blocks adoption (signup friction) and traps users out (no recovery). Both flows are first-class in Supabase already; we just don't surface them.
Proposed approach
supabase.auth.signInWithOAuth({ provider: 'google' }). Configure redirect URL for both production and PR-beta domains.signInWithOtp({ email }). Friendlier than passwords for occasional users.resetPasswordForEmailand shows a confirmation. Implement the redirect target page that captures the new password.Acceptance criteria
Out of scope
Other OAuth providers (GitHub, Microsoft) — add later if requested.