Pipeline stages explained

Every Zapat job moves through a defined sequence of stages. Understanding the pipeline helps you interpret job progress in the dashboard and diagnose issues when something goes wrong.

Stage 1: Triage

A triage agent reads the issue title, body, and labels. It classifies the issue type (bug, feature, refactor, research), estimates complexity (solo, duo, or full team), and produces a structured plan. The triage summary is posted as a comment on the GitHub issue. If the agent decides the issue is ready to implement, it automatically chains into Stage 2.

Stage 2: Implementation

An implementation agent reads the triage plan and the relevant source files, writes the code changes, commits to a new branch, and opens a pull request. The PR includes a description of what changed and why.

Stage 3: Test

Immediately after the PR is opened, a test agent runs the test suite against the branch. If tests pass, the pipeline proceeds to visual verification (if enabled) and then review. If tests fail and CI autofix is enabled, the pipeline dispatches a ci-fix job (up to 2 attempts by default). If CI fix is exhausted, the pipeline escalates to a rework job.

Stage 4: Visual Verify (optional)

If "visualVerifyEnabled" is true in your configuration, a visual verification agent inspects the PR after tests pass. This stage is disabled by default and is intended for frontend changes. If tests pass and visual verify is not enabled, the pipeline goes directly to review.

Stage 5: Review

A review agent reads the PR diff, checks for code quality issues, security concerns, and correctness, then posts a formal GitHub review — either APPROVED or CHANGES_REQUESTED. If approved, the PR becomes eligible for auto-merge. If changes are requested and under the rework cycle limit, the pipeline dispatches a rework job.

Stage 6: Rework (if needed)

If the review requests changes, a rework agent reads the review comments, implements the changes, and pushes a new commit. After rework succeeds, the pipeline always returns to Stage 3 (Test) — it never skips testing to go directly to review. The pipeline supports up to 3 rework cycles by default (configurable up to 10).

Stage 7: Merge Gate

When auto-merge is enabled and the PR is approved, Zapat scores the PR's risk across five factors (files changed, tests present, approval count, security-sensitive paths, lines changed) and classifies it as low (0–2 pts), medium (3–5 pts), or high (6+ pts). Low-risk PRs merge immediately. Medium-risk PRs are scheduled with a delay (default 4 hours). High-risk PRs always hold for human review.