You don't break your app once.
You break it every time you ship.

Set up controlled database migrations for this project. Stack: Next.js on Vercel, Postgres, Prisma. RULES - Never run `prisma db push` or `prisma migrate reset` against any database that has real data. Remove both from any script that could reach production. - Every schema change is a migration file under prisma/migrations, created with `prisma migrate dev --name <change>` against the LOCAL database only. Never apply schema.prisma directly. - Additive changes only: new columns are nullable or have a default. No DROP COLUMN, no RENAME, no type changes. If a column has to go, it goes in a later migration after the code stops reading it (expand, then contract). - Show me the generated SQL before anything is applied anywhere. LOCAL - The local Docker Postgres and seed from local-dev-prompt.md are the only database `prisma migrate dev` ever talks to. After creating the migration, run `npm run db:reset` and confirm every migration replays from zero and the seed still loads. PRODUCTION (Vercel) - Build command: `prisma generate && prisma migrate deploy && next build`. `migrate deploy` only applies pending migrations. It never generates, never resets. - App uses the pooled connection string in DATABASE_URL; migrations use the direct one in DIRECT_URL. Add `directUrl = env("DIRECT_URL")` to the datasource block. - Preview deployments must not migrate production: point preview DATABASE_URL at a branch database, or skip migrate deploy when VERCEL_ENV !== "production". - Before the first production run, take a snapshot (provider snapshot or pg_dump) and tell me where it is. Finish by printing the migration SQL, the updated package.json scripts, and the exact command you intend to run and against which database. Do not run anything against production until I say go.

Set up a local development database for this project so I can run it on my laptop from a clean, seeded database every time. Stack: Next.js, Postgres, Prisma. Do not touch production or any Vercel environment variable. DOCKER COMPOSE - Create docker-compose.yml with one service, db: image postgres:16-alpine, ports 5432:5432, POSTGRES_USER/POSTGRES_PASSWORD/POSTGRES_DB set to app/app/app, a named volume for /var/lib/postgresql/data, and a healthcheck using pg_isready with interval 5s. - Add a .env.local (git-ignored) with DATABASE_URL=postgresql://app:app@localhost:5432/app and DIRECT_URL set to the same value. Add .env.example with the same keys and placeholder values, committed. - Confirm .gitignore covers .env.local and .env*.local. SEED FILE - Create prisma/seed.ts. It uses the Prisma client, wraps everything in a single function, and uses upsert keyed on a stable field (email, slug) so running it twice produces the same data, not duplicates. - Seed a small realistic dataset: 2 to 3 users including one admin, one of every core record in the app (whatever a customer creates on day one), and one record in every "edge" state the UI has to handle (empty, pending, cancelled, expired). Use fixed values, not random ones, so tests can rely on them. - Passwords are hashed with the same helper the app uses. Print a summary of what was created at the end. - Register it in package.json: "prisma": { "seed": "tsx prisma/seed.ts" }. Install tsx as a dev dependency if missing. SCRIPTS (package.json) - "db:up": "docker compose up -d --wait" - "db:down": "docker compose down" - "db:nuke": "docker compose down -v" (deletes the volume, full fresh start) - "db:migrate": "prisma migrate dev" - "db:seed": "prisma db seed" - "db:reset": "prisma migrate reset --force" (drops the local db, replays every migration from zero, runs the seed) - "db:studio": "prisma studio" - "dev": "npm run db:up && next dev" README - Add a "Run locally" section: clone, npm ci, cp .env.example .env.local, npm run db:up, npm run db:reset, npm run dev. Five commands, nothing else. GUARDRAIL - At the top of prisma/seed.ts, refuse to run if DATABASE_URL does not contain "localhost" or "127.0.0.1" unless ALLOW_SEED=1 is set. Same check in a small script that wraps db:reset. Seeding production by accident is the failure we are designing against. Finish by running npm run db:up, npm run db:reset and npm run dev, and show me the output of each. Then stop.

Setting up docker compose + a Prisma seed file, and resetting to a clean database in one command

Add a test setup to this project so every change is verified before it deploys. Stack: Next.js on Vercel, Postgres, Prisma, docker compose + prisma/seed.ts already in place. UNIT (Vitest) - Install vitest and @testing-library/react. Add "test": "vitest run" and "test:watch": "vitest". - Tests live next to the code as *.test.ts(x). Start with the three most important pieces of business logic (pricing, permissions, anything that touches money or deletes data). Pure functions only, no database, no network. E2E (Playwright) - Install @playwright/test. Add "test:e2e": "playwright test". - playwright.config.ts uses webServer to boot `next dev` against the local Docker Postgres. globalSetup runs `prisma migrate reset --force` so every run starts from the seeded database. Never point E2E at production. - Write three flows: sign up and log in, the core action a paying customer does, and the one thing that must never break (checkout, export, whatever pays the bills). Use data-testid, not CSS classes. CI (GitHub Actions, .github/workflows/ci.yml) - Trigger on pull_request and push to main. - Services: postgres:16 with a healthcheck. DATABASE_URL and DIRECT_URL point at it. - Steps: checkout, setup-node with npm cache, npm ci, `prisma migrate deploy`, `prisma db seed`, `npm test`, `npx playwright install --with-deps chromium`, `npm run test:e2e`. Upload playwright-report as an artifact on failure. - Add a branch protection rule on main requiring this workflow to pass. Vercel already deploys on merge, so a red check means nothing ships. Do not weaken or skip a failing test to make CI green. Print the workflow file and the list of tests you wrote, then stop.