Estimate: 10m · Depends on: 1.0.1
Wire up Prisma as the ORM and a local-Docker Postgres as the dev database. Create the initial schema.prisma with no user tables yet — just enough to prove the connection works and migrations apply. Real schema (user, workspace, work_item) arrives in subsequent stories (1.1.3, 1.2.1, 1.4.2).
Why local Postgres in Docker (not SQLite or a hosted dev DB): production uses Postgres, so dev should match. SQLite has too many subtle differences (no native JSON ops, weaker type system, no RLS for 1.2.1). A hosted dev DB adds a network hop and a credential dance for every contributor. Docker is the smallest, most-portable way to give every developer the right database locally.
What you'll do: Add prisma and @prisma/client deps. Create /prisma/schema.prisma with a Postgres datasource pointing at env("DATABASE_URL"). Add a docker-compose.yml with a single Postgres 16 service. Write a scripts/db-up.sh that brings the DB up and applies migrations. Add a placeholder migration (no app tables yet — just so the migration system is exercised). Add /lib/db.ts exporting a singleton PrismaClient following the Next.js dev-mode pattern (avoid hot-reload connection leaks).
prisma and @prisma/client installed./prisma/schema.prisma exists with a Postgres datasource pointing at env("DATABASE_URL").docker-compose.yml defines a single Postgres 16 service with a named volume for persistence.scripts/db-up.sh brings up the DB and runs prisma migrate deploy; exits 0 on success./prisma/migrations/ (it can be empty or create a no-op marker table)./lib/db.ts exports a singleton PrismaClient with the Next.js dev-mode hot-reload guard..env.example updated with DATABASE_URL="postgresql://prodect:prodect@localhost:5432/prodect" and a comment explaining the dev pattern.pnpm prisma migrate dev succeeds against the Docker DB.README.md (after 1.0.4) — to extend with the DB section.env.example (from 1.0.1) — to add DATABASE_URL