Glossary

check, rule, and gate each name one thing. This page is the standard; every other page in this repo — the docs site, README.md, and the root AGENTS.md — uses the words this way.

• check — one of the runnable units the workflow enforces: colocated-test, one-function-per-file, unit-lint, unit-coverage, mutation, integration-lint, packaging, workflow-lint, e2e-verify, changelog. Each is named by the value the gates input takes and that appears in a rules = […] exemption. A check is a unit of enforcement, not a CI job — see Checks for the job shape: some checks run as their own job, several share one job as steps, and one check produces two jobs.
• rule — an individual assertion inside a lint check: no-first-party-patch, no-monkeypatch, no-inline-patch, no-environ-mutation, no-constant-patch, no-out-of-module-call, no-out-of-module-import, no-first-party-double, unmocked-collaborator, untyped-mock, no-first-party-mock, unknown-tier. A rule lives one level below a check, the way an ESLint rule (no-unused-vars) lives one level below the linter that runs it. Isolation and docs/internals/python/isolation.md write every sentence at this level and are the pages to copy.
• gate — a check in its merge-blocking role, and the gates workflow input that names which checks run. Use "gate" for the blocking role and the input — "mutation is a binary gate, not a score", "an escape hatch needs a reason" — and "check" for the unit itself.

Three named exceptions

Three populations use one of these words for something other than the definitions above. Each is its own thing, named here once, so a page that meets it doesn't need to re-argue the boundary.

The rules config key is a mixed namespace. rules = […] in an exemption entry accepts a check id (colocated-test, coverage, mutation) or a rule id (no-monkeypatch, unmocked-collaborator) side by side, in the same array. The key name predates this glossary and stays: it names "any exemptable unit, check or rule," a namespace one level wider than either definition above, not a fourth term.

GitHub's own check-runs are a different population. GitHub Actions reports check-runs — a per-job pass/fail status on a pull request — and the word collides with this repo's "check." The two do not map 1:1: the workflow declares nine job names, five checks share the one Static checks job, and unit-coverage produces two jobs. "Check" in a sentence about the pull-request UI means a GitHub check-run; "check" in a sentence about colocated-test or mutation means one of the ten above. Context carries the distinction; the words are the same.

tc-checks is a third population. The repo's own internal CI-assertion tooling (internals/checks, invoked as tc-checks <subcommand>) verifies this repo's own wiring — changelog fragments present, a lint rule still registered, a workflow output still consumed. Its subcommands are not one of the ten checks a consumer's build runs; they're this repo dogfooding its own gates on itself.