How a deploy reaches production

Every change to every app on this network goes through the same gates. This page is the description; the gates themselves live in each repo.

1. A branch, never main

Source control is GitHub, in the bryancalabro organisation. Pull requests and Actions run against it. (V-3, source: the git remote and .github/workflows in calabrodesign, verified 2026-09-21)

Work happens on a feature branch and arrives as a pull request. Pushing to main without approval is not something the process discourages, it is something the house rules forbid.

2. The local gates

Before a push, the same five commands a reviewer would run:

npx tsc --noEmit
npm run lint
npm test
npm run build
npm run audit

npm run audit is the house audit: footer format, version format, agent rule files, secrets, theme tokens, reduced motion, SEO files, strict TypeScript, CI, and sentence case. It exits non-zero on any failure, and a repo with a failure does not ship.

A push that turns CI red costs a review cycle and some of the reviewer's patience. Running the gates locally first is cheaper than both.

3. The same gates again, in CI

Every pull request runs .github/workflows/verify.yml, which runs typecheck, lint, test, build, and the house audit on a clean checkout. Each step is conditional on the repo actually having that tool, so one workflow file works unchanged across every app here.

The point of running them twice is that the second run has no local state. A test that only passes because of something on my machine fails here.

4. The version bump

Every shipping commit bumps package.json by exactly one increment on the rightmost digit, rolling over at 9. Never a jump to a round number, never a version invented for the footer. The footer reads the version from package.json at build time, so the two cannot disagree.

That rule sounds fussy until you are looking at a live page trying to work out which commit is serving it.

5. Review, then deploy

Hosting is Vercel. It serves the site build, with the SPA rewrite and the output directory set in vercel.json. (V-2, source: vercel.json and README.md in calabrodesign, verified 2026-09-21)

A merged pull request becomes a production deployment. The build output is static; there is no server process to restart and no migration to run, which removes a whole category of deploy failure and is most of why the stack is shaped this way.

When a gate is red

Red CI is work, now, not a thing to note and move past. The order is: fix a merge conflict first, then a failing check, then review comments.

"Flake" is not a root cause. A job is re-run only to confirm a failure that names something the change does not touch, or one that died before any test ran. At most once. A second failure is real.

Skipping, disabling, or quarantining a test to get green is not available.

What is not automated

Nothing here deploys itself on a schedule, and nothing rolls back automatically. The rollback is a runbook a person executes. For a network this size, a procedure someone follows beats an automation someone has to debug at the worst possible time.