Every check that blocks a merge into trunk, where it comes from, and the checks that run without blocking.
.github/rulesets/ with a README. Between them they:
trunk, and restrict who can update it (only bypass actors: org admins, the maintain and admin roles, and the Graphite App, so people without bypass rights can't merge with GitHub's button);if counts as passing, and a check that is never created stays pending forever and blocks every PR. So a required check must come from a workflow that runs on every pull request, with no workflow-level paths filter, and from one aggregate job rather than from a matrix shard.test, storybook-test, design-rendered and lint each aggregate several jobs.rulesets.test.mjs checks every required name against .github/workflows. See the change-ci skill before editing a workflow.gh api repos/prepared911/axon911-frontend/rules/branches/trunk. The checked-in files are the same rules without their ids and timestamps.
This table is a snapshot, and the source of truth is trunk-required-status-checks.json. All but review-pipeline come from GitHub Actions.
| Check | Workflow (job) | What it checks |
|---|---|---|
lint | ci.yaml | pnpm check (lint, format, feature-flag manifest), the repo's contract tests, and the tests for the repo's own CI scripts. |
typecheck | ci.yaml | turbo run typecheck over the affected packages. |
test | ci.yaml | Vitest, sharded by package. |
localization, localization-catalog | ci.yaml | The localization regression check, and the extractor gate for shells and remotes. |
ui-migrate-check | ci.yaml | Blocks new @prepared911/ui-* imports in changed files. |
design-gates, design-package, design-rendered | ci.yaml | The design-system gates, the @prepared911/ui package checks, and the rendered checks (design-rendered aggregates its shards). |
manifest-drift | ci.yaml | A deployable directory with no apps.mjs entry (or the reverse), or colliding ports. |
lockfile | ci.yaml | The same install Vercel runs, pnpm install --frozen-lockfile. |
mf-types-contract | ci.yaml | Rebuilds the remotes and fails on drift in the generated remote-ID types (pnpm mf:types:check). |
storybook-test | ci.yaml | Storybook play functions, run in a browser. |
playwright, playwright-auth | ci.yaml | The Playwright integration suites against built Module Federation previews. |
MF runtime checks | ci.yaml | Singleton integrity (report-only) and remote-failure survival (blocking). |
lab | ci.yaml | The memory lab: DOM nodes, listeners and heap left after unmount. |
stores-frame | ci.yaml | Core's two-origin stores frame harness. |
bundle-health | bundle-health.yml | Bundle size for every shell and remote. See docs/BUNDLE-SIZE.md. |
gitleaks | secret-scan.yaml | Blocks commits that add a credential. |
codeowners | codeowners-pr.yaml | Fails when a changed file has no owner, or a new file is owned only by the * fallback. |
jira-key | pr-title.yaml | The PR title starts with [KEY-123], [HF] or [BUMP]. |
review-pipeline | The review-pipeline GitHub App (not GitHub Actions) | The review verdict. It stays pending while the owning team still has to decide. See docs/REVIEW-PIPELINE.md. |
jira-key skips bot PRs and Graphite queue drafts, which carry their own titles.
The ruleset needs one approving review and resolved review threads. It does not currently require a GitHub code-owner review (require_code_owner_review is false in trunk-pr-require.json). Ownership approvals come through the required review-pipeline status, which stays pending on paths that need a human until the owning team approves. The PR's author can't approve their own PR: GitHub's own rule applies, and review-pipeline doesn't count it either.
None of these is in the ruleset. A failure is still worth reading, and some have comments or follow-up.
| Check | Workflow | What it does |
|---|---|---|
pr-body | pr-title.yaml | Reads the PR body once: the template's sections, the ### Pattern search section for UI changes, and the changesets and ### Package Release section for publishable packages. |
review-pipeline / details and review-pipeline evals | review-pipeline app, review-pipeline-evals.yaml | The full review report (re-run it to review again), and the evals for review agents. |
| Cursor Bugbot | GitHub App | Automated review, guided by .cursor/BUGBOT.md. |
lab-comment, playwright-report-comment, bundle comments | ci.yaml, bundle-health.yml | PR comments from the memory lab, Playwright failures and bundle size. |
Preview deployments | pr-preview.yml | Vercel preview builds for the affected projects. See Deployment. |
feature-flags-governance, guidance registry, Console embed version skew, apollo-cache-benchmarks | Their own workflows | Path-filtered, so they only report on PRs that touch their inputs. A path-filtered check can't be required. |
loophole-check | loophole-check.yaml | Runs pnpm loophole-check against the base commit on pull requests and merge_group events. |
remote-ui-consumer-contract, region-class-build | ci.yaml | Real checks (the remote consumer contract, region-class and third-party-DOM checks, publishable package smoke) that can turn a PR red without being required. |
Chromatic Storybook CI, agent-evals, local-dev-smoke, review fixture changes | Their own workflows | Visual diffs, report-only agent evals, a fresh-checkout dev-startup smoke test, and a check that a changed review fixture is explained in the PR body. |
Helper jobs in ci.yaml | optimize_ci, changes, turbo-token, desktop*, pnpm-cache-warm and the like | Scope detection, tokens, caches and the desktop jobs. They gate nothing here. |
gtmq_* branch that holds it and other queued PRs, and CI runs again there. ci.yaml recognises a draft as a gtmq_* head opened by graphite-app[bot], and a few jobs the PR run and the trunk push already cover skip on it. Every required check still reports on the draft, because the draft's commit is the one trunk is fast-forwarded to. review-pipeline gives the draft a success status without a second review, and jira-key ignores it. See the merge-queue skill for labels, ejection and what to do afterwards.