ADR-012: Local checks may gate the deploy before launch
Status: accepted 4 October 2026. Amends ADR-004 without replacing it.
Context
Section titled “Context”Before launch, fixes found in production journeys (onboarding, mail) were shipped one at a time, and each waited about five minutes for GitHub CI on the pull request and again on main, plus the Forge build. A developer machine runs the same checks faster. ADR-004’s gate still matters: Forge’s own push-to-deploy shipped a commit that had failed CI before it was switched off.
Decision
Section titled “Decision”The repository variable DEPLOY_GATE selects the deploy gate:
DEPLOY_GATE |
Deploy job | Waits for |
|---|---|---|
unset or ci |
deploy |
Every CI job on the push to main (ADR-004) |
local |
deploy-local |
A local-checks commit status on a commit whose tree is identical to the merged commit |
scripts/check-all --stamp runs every CI check locally (the same commands, against the *_test database) and, only if all pass and HEAD is committed and pushed, writes that status. A merge that changes the tree (a stale branch) or an unchecked merge deploys nothing. GitHub CI keeps running on every push and pull request in both modes, so a failure is still visible and the ci gate stays ready.
Consequences
Section titled “Consequences”- With
local, a merge deploys within about a minute plus the Forge build, and the deployed tree is exactly the one checked. - The local run is trusted: it is the developer’s machine and toolchain, not a clean runner. A red GitHub CI run on
mainafter a local-gated deploy is treated as an incident to fix immediately. - Return to
ci(delete the variable) before the first real shop goes live, or when a second developer joins.