# The Ten Quality Gates — Release Checklist **Source:** Routiine LLC FORGE methodology · published at routiine.io/forge **Purpose:** A printable checklist that runs before every release. Every gate must pass. No silent overrides. **License:** Use freely. Attribution appreciated, not required. --- ## How to use this checklist Print it or copy it into your PR template. For every release candidate, mark each gate `PASS`, `FAIL`, or `WAIVED (ADR-####)`. A release with any `FAIL` is not a release. A waiver requires a linked ADR justifying the exception; there are no unwritten exceptions. --- ## Gate 01 — Build - [ ] `pnpm build` (or equivalent) completes with exit code 0 - [ ] Zero build errors - [ ] Zero warnings (or: all warnings have a linked issue and an ADR) - [ ] Bundle size within budget (document the budget in the ADR log if set) **Pass criteria:** a clean production build that could deploy today without touching another file. --- ## Gate 02 — Test - [ ] All unit tests pass - [ ] All integration tests pass - [ ] All end-to-end tests pass - [ ] Test coverage meets the engagement's threshold (default 80% statements on critical paths) - [ ] No tests skipped without a linked issue - [ ] No `.only()` or `.skip()` checked in **Pass criteria:** the test suite is green and coverage has not regressed since the previous release. --- ## Gate 03 — Lint - [ ] `pnpm lint` passes clean - [ ] No new `eslint-disable` directives without a one-line justification comment - [ ] No ignored rules at the project level without an ADR - [ ] Formatter (Prettier or equivalent) has run on every changed file **Pass criteria:** the code conforms to the project's written style discipline. --- ## Gate 04 — Type - [ ] `tsc --noEmit` passes clean (or equivalent strict-mode check) - [ ] No new `any` types introduced (use `unknown` and narrow) - [ ] No new `@ts-ignore` directives (use `@ts-expect-error` with a reason, and only after ADR sign-off) - [ ] All public function signatures have explicit types **Pass criteria:** the type system is doing its work. Zero escape hatches added without documentation. --- ## Gate 05 — Security - [ ] `pnpm audit` (or equivalent) reports zero high or critical vulnerabilities - [ ] Auth flows reviewed against OWASP Top 10 for any changes in this release - [ ] Secrets scan clean (no hardcoded keys, tokens, or credentials) - [ ] Dependency updates reviewed for supply-chain risk - [ ] Input validation present at every system boundary (Zod or equivalent) - [ ] CORS policy reviewed if any cross-origin surfaces changed **Pass criteria:** no known vulnerabilities are shipping in this release. --- ## Gate 06 — Review - [ ] Every PR in this release has at least one approved code review - [ ] Security-sensitive changes have an additional human reviewer (not just automated review) - [ ] Every merged PR ties to a task or issue - [ ] No PRs merged with unresolved review comments **Pass criteria:** no unreviewed code is in production. --- ## Gate 07 — Performance - [ ] Lighthouse score ≥ 90 across Performance, Accessibility, Best Practices, SEO for client-facing pages - [ ] Core Web Vitals green: LCP < 1.8s, CLS < 0.01, TBT < 200ms, INP < 200ms - [ ] No new unoptimized images (WebP/AVIF where possible, `next/image` or `nuxt/image` used) - [ ] No render-blocking JavaScript on the critical path - [ ] Edge caching configured if the platform supports it **Pass criteria:** the release does not regress performance and meets the engagement's documented performance budget. --- ## Gate 08 — Env - [ ] Every required environment variable is documented in `.env.example` - [ ] No hardcoded URLs, API endpoints, or feature flags in the code - [ ] Environment-specific configuration is separated (dev / staging / prod) - [ ] All secrets are in a secret manager, not in version control **Pass criteria:** a new engineer could stand up the project locally using only `.env.example` + the README. --- ## Gate 09 — Migration - [ ] All database migrations run cleanly against staging - [ ] Rollback path for every migration is documented and tested - [ ] No destructive migrations (drops, truncations) without client sign-off and a backup - [ ] Migration order is deterministic and idempotent - [ ] ORM schema matches the migration state **Pass criteria:** the database can migrate forward and roll back cleanly. No data loss risk is shipping without explicit authorization. --- ## Gate 10 — Handoff - [ ] README is current with setup, build, deploy, and troubleshooting sections - [ ] ADR log is complete for this release's architectural changes - [ ] Runbook covers the specific operations introduced or changed - [ ] Deployment notes for this release are written - [ ] The next engineer on call can answer "what changed?" from the docs alone **Pass criteria:** no silent handoffs. The next person to touch the system, on the next shift or the next month, can pick up without interrogating the author. --- ## After the checklist A release that passes all ten gates is eligible to ship. A release that fails any gate is not a release — it is work in progress. No overrides, no "ship it anyway" escape hatches. The only way to bypass a gate is to file an ADR explaining the exception, get sign-off from the Routiine lead, and document the remediation plan. This is the operational discipline that makes the Ship-or-Pay Guarantee affordable to offer. --- *This checklist is part of the Routiine LLC Resource Hub at routiine.io/resources. The full FORGE methodology is published at routiine.io/forge. For the Ship-or-Pay Guarantee, see routiine.io/work.*