reticle gate is what makes verification unavoidable. It computes the affected flows, looks for a passing artifact for each, and fails the command if any is missing. An agent that edits a covered file cannot call itself finished without re-verifying.
Arguments and flags
In hook mode only, setting
RETICLE_SKIP_GATE turns a failing gate into exit 0 and prints that the change is unverified.
What blocks and what does not
What it prints
Onereticle_gate line. Real capture from this repository, with the flow lists trimmed for length:
downgraded, deletedCoverage, unflowed, coverageRegressed, unexecuted, coverageStale and coverageAccepted appear only when they are non-empty, flowsWithoutSources only when it is true, and none was present in that run. The coverage categories need a coverage ledger, which a project gets from reticle_verify { action: "crawl", exhaustive: true } or reticle_verify { action: "coverage", app: true }; without one they never fire. The CLI prints this as a single line of JSON; it is pretty-printed here to be readable.
Exit codes
Measured on this repository,
npx @reticlehq/server gate --since HEAD~1 exited 1 with the output above: 0 of 47 flows covered, 39 uncovered and 8 quarantined.
Worked example
Wiring this into CI
Where the gate sits relative to build, verify, and merge.