Score A-Math — Tournament Score & Pairing System

Next.js (App Router) + Prisma/PostgreSQL + Auth.js (Credentials for dev, Google OAuth for real use). See tournament_score_pairing_uxui_spec_v2.md (in the parent folder) for the full product spec this implements. Phases 1–4 below are functionally implemented and deployed to production on Vercel + Supabase Postgres.

Visual design: minimal white UI — frosted/translucent white cards (.surface in globals.css) over a soft light-gray background with a subtle small-dot texture, no dark mode. Shared primitives live in src/components/ui/ (Card, Button/LinkButton, Badge, EmptyState, PageHeader, NavLink/TabLink for active-state nav, ConfirmSubmitButton for destructive actions, Pagination/PageSizeSelect for tables, and a cookie-driven Toast/FlashToastHost pair) — reuse these instead of one-off Tailwind classes when adding pages. Badge colors are semantic and consistent app-wide: upcoming/preview = yellow, ongoing/confirmed = green, completed = gray, ADMIN = red, STAFF = blue (info variant).

Getting Started

1. Start a local Postgres dev database (Prisma's own local server — no Docker needed):

   npx prisma dev -d
   

   This prints a connection string pointed at a template1 database — don't use that database directly (DATABASE_URL in .env already points at a separate score_amath database instead). Writing schema into template1 itself poisons every future database this local server creates, since CREATE DATABASE clones its template by default; we hit exactly this once already. If you ever regenerate the local server, create a dedicated database first (psql/pg client: CREATE DATABASE score_amath;) and point DATABASE_URL at that.

   Also: on this local dev server, prisma migrate dev can fail with a shadow-database error (P3006/P3005) even against a clean database — it's a quirk of this ephemeral server's copy-on-write internals, not the schema. Workaround used so far: prisma db push to sync the schema, hand-write the migration .sql, then prisma migrate resolve --applied <name> to mark it applied. On a real Postgres/Prisma Postgres, prisma migrate dev should work normally.

2. Apply migrations and seed sample data (see the shadow-database note above — on this local dev server prisma db push + prisma migrate resolve --applied <name> may be needed instead of a plain prisma migrate dev):

   npx prisma migrate dev
   npx prisma db seed
   

   Seed creates:

   • Admin login: [email protected] / admin1234
   • Staff login: [email protected] / staff1234
   • One sample "Sample Open Tournament" with 8 players and 4 tables.

   Seed only ever touches the local dev database (DATABASE_URL from .env) — it is never run automatically against production. Bootstrapping the first production Admin is a one-off, separate step (see Deployment below).

3. Run the dev server:

   npm run dev
   

   • Public site: http://localhost:3000
   • Admin: http://localhost:3000/login
   • Account (Google login / player link): http://localhost:3000/account

   Google sign-in needs real AUTH_GOOGLE_ID/AUTH_GOOGLE_SECRET values in .env (see the comment there for how to create them) — without them, use the credentials (dev) login on the same page. The credentials provider is excluded entirely when NODE_ENV=production.

This is the beginning of the README. Read the rest at the original. Read the full README ↗