# Buildboard Auth + Hardening Roadmap — 2026-04-06

## Direction change
Buildboard should move away from a waitlist-first flow and toward a real self-serve product flow:
- signup
- email verification
- login
- password recovery via email

## Core product principle
The default CTA should eventually be "create trial account" rather than "request access".

## Required auth flows

### 1. Signup
- user submits email + password
- password stored hashed, never plaintext
- account starts unverified
- verification email sent immediately

### 2. Email verification
- one-time verification token
- token expires
- on success: account becomes verified
- after verification: allow login / trial access

### 3. Login
- email + password
- session cookie
- failed-attempt controls / rate limiting

### 4. Forgot password
- email-based password reset request
- one-time reset token
- expiry + single use
- password update flow

## Hardening priorities
- rate limit auth endpoints
- generic error wording where useful (avoid leaking account existence too broadly)
- hash passwords with a modern slow password-hashing algorithm (or equivalent supported path in the runtime)
- expire and single-use all verification/reset tokens
- minimize public admin/debug surfaces
- keep dashboard routes behind authenticated session checks
- validate slugs/inputs consistently
- avoid exposing public email addresses on site pages

## Buildboard-specific security notes
- Turnstile can stay on public intake forms where useful
- request→roadmap owner flows should require authenticated ownership of the workspace
- embed flow should preserve attribution but avoid exposing unsafe host-side control

## Migration path from current scaffold
Current scaffold is magic-link-like and workspace bootstrap oriented.

Next implementation steps:
1. add `password_hash` and `email_verified_at` to `users`
2. add dedicated verification/reset token purposes
3. add signup endpoint
4. add login endpoint
5. add forgot-password / reset-password endpoints
6. update docs + landing CTAs over time from early-access framing to account-creation framing

## Public-site implications
- de-emphasize waitlist language over time
- introduce a clear signup path
- keep docs updated with auth flow changes

## Not yet done
- no complete password-based auth flow yet
- no email verification flow yet
- no password recovery flow yet
- hardening is only partial and must stay active while auth expands