dependency-discipline

name	dependency-discipline
description	The "no invaders" gate for Synthex. The ship already carries everything it needs. NEVER add a new npm dependency, external SaaS, framework, datastore, or auth system to solve a problem an existing system already solves — adding one is a CEO-gated decision. ALWAYS prove the capability isn't already present (grep package.json, lib/, the skills list, Vercel env) before integrating anything new. Activate on ANY request to "add a package / install / npm i / integrate X / we need a tool / use library Y / add a provider / new database".
metadata	{"author":"synthex","version":"1.0","type":"governance-skill","triggers":["add a package","npm install","npm i","install a library","new dependency","integrate","we need a tool","add a provider","new database","new framework"],"requires":[],"context":"fork"}

Dependency Discipline — no invaders board this ship

A new dependency is a passenger you feed forever: bundle size, serverless cold-starts, a CVE surface, a migration tax, and one more thing that can break a paying client's product. The default answer to "let's add X" is NO — because the ship almost certainly already carries something that does it.

The rule

Before adding ANY new npm package, external SaaS, framework, datastore, or auth system:

1. Prove it isn't already here (the checklist below). If it is — use it.
2. If a wired-up capability is close, extend it rather than add a rival.
3. If it is genuinely new and necessary, it is a CEO-gated decision — surface the trade-off (what it buys, bundle/cold-start cost, the maintenance tax, the alternative we already own) and wait for explicit human approval. Log the decision.

There is exactly one auth system (Supabase), one ORM (Prisma), one deploy target (Vercel + Railway). Do not add a second of anything that already exists.