The problem
SGAF is built with AI coding agents, often several at once. An agent will report a feature finished because the code is written. With parallel work, the risks multiply: a change that breaks the build, work stranded in a branch nobody merges, and a database change that reaches production out of step with the code that needs it.
What I built
A release process where the merge is the deploy, so nothing reaches production except through a gate.
Every change is a pull request. Build, lint, type check and tests run in a fixed order, because running them in parallel can give unreliable results. A pull request is never opened on a red gate. Before it opens, a check confirms that no commits are stranded across the parallel working copies the agents use. Database migrations are confirmed against production before merge, never applied when the pull request opens.
Around the gates sits a review guide with a checklist for each kind of change: site copy, application code, database migrations, CI workflows and internal documents. It keeps a ledger of known traps that must be checked before anything is called live. Copy has gates of its own: the brand rules, colour contrast for accessibility, and a check that every product page has a help article.
What you can see
Counted from the repository on 18 October 2026, for the period since the first commit on 1 March 2026:
- 962 merged pull requests
- 1,348 automated test files and 51 end-to-end test specifications
- 249 database migrations
- 379 written decision records
The result
A steady release rhythm with a person at the last gate. The agents move quickly in their own branches, and production only changes when a reviewed pull request merges.