Checks

Every finding Ordnung reports carries a stable check identifier from the list on this page. The identifier is the name you use everywhere: filtering output, setting a severity in .ordnung/overrides.toml, granting a fleet exception, or discussing a finding in review.

Run ordnung --list-checks to see the checks your installed binary carries, with their one-line instructions. That output comes from the binary, so it is the authority if this page and your installed version ever disagree.

How to read the tables#

Severity is the default the built-in policy assigns; any layer of configuration may raise, lower, or switch a check off.

Scope says what one finding covers. A repository check has one verdict per repository — there is one README, one default branch, one Dependabot configuration. A project check reports once per detected project root, so a monorepository receives one finding per directory.

Some checks read the local working tree, some read GitHub repository settings through the gh CLI, and some do both. ordnung check runs the local side; ordnung repo-check --repo owner/name is the full audit.

Repository shape#

Documentation and text#

GitHub safeguards#

These read repository settings through the gh CLI, so they report in ordnung repo-check and ordnung github check rather than in a plain local ordnung check.

CI safety#

Build and toolchain#

Dependencies#

Maintenance automation#

Changing a severity#

Outside a fleet, a repository sets check severities directly in .ordnung/overrides.toml:

[checks]
codespell = { severity = "off" }
test-mirror = { severity = "required" }

Inside a fleet, a member requests an exception under [overrides] instead, and every exception must carry a reason. Unknown check IDs are an error at every layer, so a typo fails loudly instead of silently doing nothing.