anchors check
Run the quality gates (the pipeline).
Confronts the nodes against the quality gates declared in anchors.yamland reports the verdict profile (QUALITY §5-§6).
By default it is INCREMENTAL: it runs over the impact path of a changed file(--changed <file>). With --all, it sweeps every node (expensive; the full picture).
Each gate that fails generates an issue; a blocking gate that fails barspromotion. Informative gates enter the profile but do not bar (maturation, §7).
--deterministic SKIPS the AI judgment gates (measures: judgment) and runs onlythe computable ones. It is the PRE-COMMIT mode: a judge gate cannot bar a commit(there is no waiting for the AI) nor should it queue judgment on every commit (repeatedgarbage). Without that mode, judge becomes invisible (it neither bars nor records).anchors check [flags]| Flag | Default | What it does |
|---|---|---|
--all |
scan every node (the full picture; expensive) | |
--category |
enforces only the gates of this nature (types|style|traceability…) | |
--changed |
changed file(s) — repeatable or comma-separated; the gates run ONCE over the union of the impact paths | |
--commit-msg |
path to the commit message file, from which to read the [skip-<gate>@<CODE>: reason] markers |
|
--deterministic |
runs only the computable gates (skips the AI-judgment ones) — the pre-commit mode | |
--fix |
self-healer: applies the automatic repairs (e.g. fixes updated_at) before confronting | |
--index |
the gates read the files as the git index has them — what the commit records (the pre-commit mode) | |
--map |
path to the map | |
--no-record |
report only: neither stamps the map nor opens issues | |
--only-issues |
omits from the table the gates that passed everything and left no pending item (the total remains in the footer) | |
--phase |
enforces only the gates of this phase (pre-commit|pre-push|ci|manual) | |
--record-issues |
github mode: open/close board issues from a local run too (by default only CI does); manual mode: write the issues to issues/ (by default none is written) | |
--root |
. |
project root |
--show-drift |
lists ALL the pending items (⚠) with the address of each one; without the flag, only the table counter | |
--skip-rule |
waives rules in this run: id=reason[,id=reason]. The reason is mandatory |
|
--skip-slow |
skip gates declared cost: slow |
|
--timing |
measures how long each gate took, and names the slowest targets — to find what makes a scan expensive |
Confronting the project — family
Section titled “Confronting the project — family”Commands of the same family — what tells each apart:
| Command | What it does |
|---|---|
anchors check |
Run the quality gates (the pipeline) |
anchors verify |
Run EVERYTHING the phase requires: Anchors gates + external tools |
anchors coverage |
Show coverage by scenario, by line, of the DIFF and the delta |
anchors stale |
List stale edges — what changed and has not been reconfronted |
anchors impact |
Impact analysis: what a change to this file reaches |
anchors failures |
The observed failures that the spec has not yet explained |
The anchors check command is the primary verification engine of the Anchors framework. It evaluates the project’s quality gates against modified, staged, or entire repository files.
1. Syntax & Common Options
Section titled “1. Syntax & Common Options”# Check modified files in working directoryanchors check
# Check staged files (used by git pre-commit hook)anchors check --staged
# Check all governed files across the entire projectanchors check --all
# Check only a specific gateanchors check --gate=unit-complete
# Run in strict mode (fails on warnings)anchors check --strictExit Codes:
Section titled “Exit Codes:”0: All gates passed cleanly (OK).1: One or more blocking gates returnedFAIL.2: Configuration or file parsing error.
2. Difference between check and verify
Section titled “2. Difference between check and verify”anchors check: Focuses on internal Anchors gates (unit completeness, identity code integrity, boundary violations, doc parity).anchors verify: The full-phase orchestrator. It runsanchors check, executes project test suites (anchors test), runs linter tools, and performs mutation checks before approving a release milestone.
3. CI/CD Usage Example
Section titled “3. CI/CD Usage Example”# In GitHub Actions or GitLab CI- name: Evaluate Anchors Pipeline run: anchors check --all