How a change moves from pull request to production in axon911-frontend, and why each stage of automation exists.
trunk passes through three stages: PR checks, the Graphite merge queue, and a Vercel deploy that starts on trunk. This section documents what runs in each stage, when it runs, and which checks block a merge.
review-pipeline among them), plus one approval and resolved review threads. Other checks run and report but don't block.Add to Merge Queue label, or Fast Track to Merge Queue for an urgent change. Graphite re-runs CI on a gtmq_* draft PR that holds one or more queued PRs, then fast-forwards trunk to the draft's head. People without bypass rights can't merge with GitHub's button, because only bypass actors can update trunk. See the merge-queue skill, .agents/skills/merge-queue/SKILL.md.trunk lands in the trunk environment, and production is a separate, manual promote.trunk is protected by four repository rulesets checked in under .github/rulesets/, so a change to what blocks a merge is a reviewed pull request. A required check is matched by job name, which is why a required job can't be renamed, removed or path-filtered without changing the ruleset first.review-pipeline carries the ownership check. It is a required status that stays pending while the owning team still has to decide. See docs/REVIEW-PIPELINE.md.trunk environment. Reaching production domains needs a manual promote, with rolling releases and an instant rollback path, so each shell and remote can ship independently.trunk environment, promotion and rollback.trunk-required-status-checks.json, or gh api repos/prepared911/axon911-frontend/rules/branches/trunk for the live rules. If this page and those disagree, the rulesets win.