Stack baseline — decide once, build on it

Every SMB product builds on the SAME proven stack unless there's a concrete reason not to. Re-deciding framework/ORM/auth/host per build wastes the first hour of every project and fragments the codebase across products. This is the default; deviate only with a written reason in ARCH.

The pinned stack

Rules

1. One framework, one DB, one ORM, one auth lib across all products. Consistency > per-product optimization.
2. Pin it in .great_cto/PROJECT.md at scaffold time (stack: line) so every later agent reads it instead of guessing — and an existing PROJECT.md's stack always wins.
3. Money in integer cents; timestamps tz-aware; IDs are stable (compose with migration-ready-schema).
4. Auth, payments, email/SMS, jobs are owned by their specialist (auth-engineer, billing/integrations, lifecycle-messaging) — this skill only names the default library; the specialist owns the contract.
5. Deviation needs a written reason in ARCH's Components section (e.g. "Clerk over Auth.js because the customer needs SSO/SCIM on day one").

Output

When applied, write the stack into ARCH's Components section and PROJECT.md:

## Stack (baseline)
framework: Next.js (App Router, TS) · UI: Tailwind + shadcn
db: Postgres (Neon) · orm: Drizzle · auth: Auth.js (→ auth-engineer)
payments: Stripe · email: Resend · sms: Twilio · files: R2 · jobs: Inngest
test: Vitest + Playwright · host: Vercel · obs: Sentry
deviations: <none | reason>