Checks

Cairn verifies work as it happens, so an agent gets feedback on its own changes without anyone hand-running a test suite. A project declares its checks — test, lint, type-check, format, and build commands — in .cairn/config.yaml, and Cairn runs the affected subset automatically on two cadences.

Two cadences

Per-commit. Right after a commit that touches source, Cairn runs the fast checks whose inputs that commit changed — typically the related unit tests, a formatter, and lockfile and migration guards. Their verdicts, each annotated with a test count, duration, or a cached marker, are appended straight onto the result of the tool call that made the commit. A formatter that rewrites files folds its edits back into the just-made commit.

Turn-end. When an agent finishes a turn, Cairn runs the fuller suites in the background — the whole type-check, lint, and test runs, plus the build. Each re-runs only when its own inputs changed, so a green result is cheap to re-confirm.

Verdicts come back to the agent

Turn-end results are delivered into the session rather than run silently. A failure wakes the agent with the failing detail inlined, so it resumes already knowing what broke; an all-green run rides along passively on the agent's next turn — never a wasted turn on green, but still recorded. Because a red result actively pulls the agent back, "the checks pass" is a state the agent works toward rather than a report a human has to chase.

What a green verdict covers

A green verdict with a test count covers the code on the diff — correctness a suite can assert. It does not cover whether a feature actually works for a person: live UI and cross-system behavior still need a browser or a running instance. Nothing else gates a merge, though — this cadence is the whole pre-merge verification surface, not a preview of a separate CI run.