Gates

A hard gate is a mechanical check performed by trkr itself, not by an agent — provider exit 0 alone never passes a gated stage. Artifact and verdict gates are postconditions checked after the session exits; checks-green is a precondition the stage refuses to run past until met. Gate outcomes are one of:

• pass — advance to the stage's to column.
• retry — undecidable right now (e.g. CI still running); leave the ticket and poll again.
• refusal — decidable failure with findings; the findings feed the turn loop and the ticket is kicked back for another turn. Findings from earlier turns are injected into the retry's stage prompt, and a stage whose failing count doesn't fall between turns blocks the ticket early — see Turns and blocking.

Artifact gates

Stages must prove their artifacts were committed before advancing: the preset spec stage requires spec.md and contract.md, diagnose requires diagnosis.md and contract.md, implement requires implementation.md, review requires review.md, and validate requires validation.md, in the ticket's artifact directory. A stage that claims success without its artifact is refused mechanically, regardless of what the session reported.

Section gates

An artifact gate's sections map names ## headings that must appear in a committed artifact. The preset implement gate requires the structured handoff sections in implementation.md: Implemented, Left undone, Commands run, Discovered issues. A missing section is a refusal naming the section.

Verdict gates

The review stage's committed review.md — and the validate stage's validation.md — must contain a VERDICT: CLEAR or VERDICT: BLOCKING line; a blocking verdict kicks the ticket back a turn. Each gate evaluation is recorded as a verification span with one criterion event per finding or check — see Telemetry.

checks-green

A CI precondition available to custom workflows via "gate": "checks-green" on a stage. No preset stage uses it — out of the box, CI state is recorded in telemetry at hand-off but doesn't gate anything. When set, it evaluates the linked PR's check rollup (gh pr view --json statusCheckRollup):

Situation	Outcome
No linked open PR	Refusal — the findings tell the implement stage to open a PR whose body closes the issue
Any check red (FAILURE, TIMED_OUT, CANCELLED, STARTUP_FAILURE, ACTION_REQUIRED)	Refusal — lists failing check names; read logs, fix, push
Any check pending	Retry — poll again later
All green, or zero checks configured	Pass

SKIPPED and NEUTRAL conclusions are not failures. Both modern CheckRuns and legacy commit statuses are understood. Red outranks pending; pending outranks green.