Supabase auth removed; Clerk takes over login and session management
zgbrenner replaces Gary's hand-rolled Supabase auth UI with Clerk, motivated by deployment fit rather than feature gaps. The old login system is gone; the data layer stays on Supabase. There's an explicit incomplete backend piece left for a follow-up PR.
The scope was deliberately tight: authentication only. No billing, organizations, RBAC, invitations, or multi-tenant isolation. The /login and /signup routes are preserved as URLs but now render Clerk's hosted components. Clerk's middleware handles route protection at the Next.js layer.
Rather than rewriting the roughly fifteen components that consumed the old auth context, zgbrenner kept the existing auth hook signature and reimplemented it as a compatibility shim backed by Clerk. Eight backend-calling files route through a single shared helper that attaches the Clerk session token. The sidebar account dropdown swaps to Clerk's <UserButton>. The Supabase client, Supabase auth libraries, and their frontend dependencies are deleted. React is bumped to satisfy Clerk's peer requirement.
The important caveat is that this is app-level protection only. Gary is treated as effectively single-user. The Express backend still verifies Supabase JWTs and does not yet validate Clerk tokens. The frontend already sends the Clerk session token, so data-accessing features currently depend on the documented next step: swap backend auth middleware to verify Clerk JWTs via Clerk's JWKS endpoint and map the Clerk user ID onto the existing data model. Until that follow-up merges, the auth chain is split.
The test plan noted a clean build and passing auth tests, with manual sign-in verification deferred since it requires real Clerk keys. Env files and docs are updated with the new variables and warnings to distinguish pk_... (publishable, browser-safe) from sk_... (secret, never prefix with NEXT_PUBLIC_).
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?