Phase 1.c — waveflow-web skeleton (TanStack Start + Better Auth)

[InstaZDLL]

Tracking issue for sub-phase 1.c of RFC-001.

Bootstrap the waveflow-web repository: TanStack Start scaffolding + Better Auth magic-link login + empty post-login dashboard + JWKS endpoint.

Scope

• New repo waveflow-web, TS monorepo from day one (will host @waveflow/design-tokens, @waveflow/locales, @waveflow/api-types later).
• TanStack Start (file-based routing, SSR by default).
• Tailwind v4 + @theme inline block consuming the 14-theme tokens from @waveflow/design-tokens (initially copy-pasted from desktop's src/lib/themes.ts; extracted as proper package later).
• Better Auth installed with the email/magic-link provider.
• Routes:
  • / — landing (logged out)
  • /login — magic-link form
  • /auth/callback — magic-link verify
  • /dashboard — empty placeholder, requires session
• Better Auth issues RS256 JWTs (exp = 1h) + refresh tokens (90 days).
• JWKS endpoint live at /.well-known/jwks.json with the public key.
• Server URL config: env var WAVEFLOW_SERVER_URL, defaults to http://localhost:8080.

Dependencies

• Independent of 1.b — can be built in parallel. The two only meet in 1.d.

Acceptance criteria

• bun run dev serves the web on http://localhost:3000, SSR working.
• Magic-link flow: submit email → check inbox → click link → land on /dashboard with active session.
• curl http://localhost:3000/.well-known/jwks.json returns a valid JWKS.
• JWT decoded after login has expected claims: sub, email, exp, iat.
• Refresh token rotation tested.
• Dockerfile.

Estimate

~3 weeks.