Design spec and implementation plans for the Supabase exit

The design spec (2026-05-08-local-postgres-design.md, 201 lines) states the goal - Mike fully offline against a Docker Postgres, no Supabase anywhere, same code path in dev and prod - and makes the architectural choices specific: Auth.js v5 Credentials provider with JWT session strategy, Express reading the same cookie via next-auth/jwt's decode() using a shared AUTH_SECRET, Drizzle as the single schema source of truth. It lists exactly which Supabase tables, triggers, functions, and RLS policies get dropped.

Plan 1 (2026-05-08-local-postgres-foundation.md, 1075 lines) sequences the foundation into numbered tasks with step-by-step commands and expected output. The vertical-slice approach is explicit: migrate exactly one route (/user/*) end-to-end to prove the new stack works, leave everything else broken at runtime until Plan 2. That's a deliberate risk-management choice, and the plan flags the broken-state period honestly.

Plan 2 (2026-05-08-local-postgres-migration.md, 536 lines) is the most directly reusable document. It includes a translation table for every PostgREST call pattern to its Drizzle equivalent - .single(), .upsert(), .contains(), .or(), .rpc() all get explicit mappings. The error-handling section explains why Drizzle's throw-on-error behaviour requires adding try/catch everywhere supabase-js's { data, error } pattern previously handled errors silently. A deferred note calls out that 500 responses currently forward raw err.message, which leaks Postgres constraint names.

None of these files contain runnable code. Their value is methodology: the foundation-first then vertical-slice then mechanical-sweep then uninstall sequencing, and the translation reference for the PostgREST-to-Drizzle mapping problem.