Allow password signups

[tyler-dane]

Feature Description

Add first-party email/password authentication in addition to existing Google OAuth.

This includes:

• Sign up with email/password
• Sign in with email/password
• Forgot/reset password flow
• Account linking behavior so Google + password for the same email resolve to the same Compass user/data

Why

This reduces signup friction for users who do not want to use Google OAuth.

Scope and Phases

Phase 1: Web UI shell (no backend behavior changes)

• Add account icon entry point
• Add auth modal/forms and client-side validation
• Keep Google sign-in behavior unchanged
• Use mock API wiring in tests only

Phase 2: Backend + auth integration

• Add email/password auth via SuperTokens best-practice flow
• Add reset password flow
• Add account-linking logic

Phase 3: Hardening and rollout cleanup

• Validate edge cases and data consistency
• Remove temporary rollout gating when approved

Stop after each phase for confirmation before starting the next phase.

Entry Points

Show account icon on all views:

• /day
• /week
• /now

UI requirements:

• Icon uses phosphoricons
• Icon is shown only when user is unauthenticated
• Clicking icon opens auth modal/form
• Match styling from attached screenshots

Feature Gate (temporary rollout)

Render account icon only when:

• User is unauthenticated
• AND user is "foo@bar.com"

Implementation note for clarity:

• Because user is unauthenticated, use a deterministic client signal for prior known user identity (example: last known authenticated email from profile/session metadata).
• If no prior known email is available, default to hidden.

UX and Form Requirements

Auth modal

• Include Google button: Sign in with Google (existing flow)
• Include links to:
  • https://www.compasscalendar.com/privacy
  • https://www.compasscalendar.com/terms

Sign up form

• Fields: Name, Email, Password
• CTA: Create account
• Create account is disabled until all fields are valid

Sign in form

• Fields: Email, Password
• CTA: Enter
• Link: Forgot password

Forgot/reset password

• Request reset by email
• Show generic success message regardless of account existence
• Reset screen allows setting new password via tokenized link
• Handle expired/invalid token with clear retry path

Validation and Security Requirements

• Use Zod schemas for client and server validation
• Normalize email casing/whitespace before auth/linking
• Password best practices:
  • Minimum length requirement
  • Hashing handled by auth provider
  • Rate limiting / brute-force protections
• Do not leak account existence in auth/reset errors
• Follow email verification best practices before high-risk account-linking operations

Account Linking and Data Consistency

Source of truth:

• Compass userId in MongoDB is canonical identity

Behavior requirements:

• If a user already exists via Google OAuth and later signs up/signs in with same email, resolve to the same MongoDB userId
• Do not create duplicate Compass users for same person
• Existing events/tasks/settings remain intact after linking
• Log and handle conflicts safely when provider email is missing/unverified

Backend/API Expectations

• Use SuperTokens best-practice recipes for Google + EmailPassword + reset flows
• Keep existing Google /signinup flow functional
• Add/enable email/password and reset endpoints via SuperTokens integration
• Session behavior after successful signup/signin:
  • User is authenticated immediately
  • App refreshes profile/session state and routes as normal

Non-Goals

• No changes to calendar/event business logic beyond identity/account resolution
• No redesign of unrelated app navigation

Acceptance Criteria

• Unauthenticated eligible user can open auth modal from icon on /day, /week, and /now
• User can create account with valid Name/Email/Password
• User can sign in with email/password
• User can request password reset and complete reset with valid token
• Google sign-in still works as before
• Same-email Google + password flows map to same MongoDB userId
• Existing data remains visible after switching auth methods
• Clear error states for invalid creds, invalid token, expired token, and network failure
• Privacy/Terms links are present and functional

Test Plan

• Unit tests:
  • Zod validation for signup/signin/reset inputs
  • Form state: disabled/enabled CTA and error messages
• Integration tests (web):
  • Icon visibility and modal open/close behavior across /day, /week, /now
  • Auth form interactions and state transitions
• E2E tests:
  • Signup happy path
  • Signin happy path
  • Forgot/reset password happy path
  • Linking flow: existing Google account + password login/signup reuses same user data
• Regression tests:
  • Existing Google OAuth flow unchanged

Run:

• yarn test:core
• yarn test:web
• yarn test:backend

Risks / Gotchas to Watch

• Current backend is tightly coupled to Google calendar auth/sync paths
• Linking logic can accidentally fork user records without strict canonicalization
• Rollout gate condition (unauthenticated AND foo@bar.com) is atypical and must be implemented explicitly to avoid confusion