Pipeline

The pipeline has a fixed, opinionated sequence of nine core steps. Their order is not configurable. What each core step runs is.

intent → rebase → review → test → document → lint → push → pr → ci

flowchart LR
  intent["Intent"] --> rebase["Rebase"] --> review["Review"] --> test["Test"] --> document["Document"] --> lint["Lint"] --> push["Push"] --> pr["PR"] --> ci["CI"]
  review -. findings .-> action["Approve / fix / skip / abort"]
  test -. findings .-> action
  document -. findings .-> action
  lint -. findings .-> action
  ci -. failures .-> action

This page is the overview. For each step’s exact behavior, defaults, skip rules, and fix-commit format, see Pipeline Steps.

A repository can add to this sequence but never subtract from it: gates declares extra checks that run immediately after a core step, and nothing there can skip, reorder, or replace one.

What a passed gate means

The pipeline is opinionated so that “passed the gate” has a stable meaning:

• the branch was checked against fresh remote upstream and the pushed-branch target first
• review, tests, user-facing test evidence when available, docs, and lint happened before any branch push to the configured target
• every repository-declared gate ran at its configured point before Push, unless the operator explicitly skipped it after a failure
• the human stayed in control when a step needed judgment
• the final branch update was guarded against discarding unincorporated commits already on the push target
• push, PR creation, and CI monitoring only happened after the local gate was satisfied

The nine steps

#	Step	What it does	Default auto-fix limit
1	Intent	Use supplied intent or infer it from recent local agent transcripts	n/a
2	Rebase	Fetch fresh remote upstream and the configured branch target, then rebase your branch onto them	3
3	Review	AI code review of your diff	0 (requires approval)
4	Test	Targeted local validation of the change and intent (not a full CI suite), plus evidence when intent is available	3
5	Document	Update docs when needed and report unresolved gaps	initial pass
6	Lint	Run lint/static analysis; shares the document step’s initial housekeeping pass when no lint command is configured	3
7	Push	Safely push the validated branch to the configured target	n/a
8	PR	Create or update the pull request	n/a
9	CI	Watch CI + mergeability, auto-fix failures	3

Why these steps, in this order

• Intent first so downstream agent prompts and generated PR descriptions can include author intent supplied by the agent or inferred from transcripts.
• Rebase next so everything else runs against the latest upstream and pushed-branch target. It also stops when the branch would silently bundle commits from a local default branch that were never pushed to origin/<default_branch>. If there’s no diff left after the rebase, the pipeline skips the rest.
• Review before test so the agent reads fresh code, not code it may have touched during fixes. A later run’s initial review also receives fix-round provenance for any uncertified pipeline-authored commits left on the branch when a previous run’s re-review did not complete.
• Document after test so docs are updated against code that’s known to work.
• Lint last among local checks so it doesn’t churn over code that may still change.
• Push → PR → CI happens after all local checks pass. CI publishes a repair through the Push step’s guarded path and keeps monitoring only when it can prove the repair descends from the reviewed head; otherwise the repair revalidates from Review before Push republishes it, which is what a merge-conflict repair always does. ci.revalidate_repairs sets that intent: false (default) publishes when it is provable, true revalidates every repair. CI owns remote validation after publication. A repository gate command still runs before Push, although the command itself may contact an external service.

What core steps can do

Core steps use these outcomes as applicable:

• Complete cleanly and advance the pipeline.
• Return findings with severity (error, warning, info) and an action (auto-fix, ask-user, no-op).
• Trigger auto-fix if the step’s auto_fix limit is above 0, the step result is auto-fixable, and any finding is auto-fix-eligible. The document step applies safe documentation fixes during its initial pass and, when commands.lint is empty, combines that pass with initial safe lint fixes before the lint step consumes its findings.
• Pause for approval if blocking findings remain after auto-fix, or if any finding is ask-user.
• Skip when there’s nothing to do (e.g., no diff, unsupported host).
• Fail on fatal errors and stop the pipeline.

See Auto-Fix Loop for how the fix cycle works, and Using the TUI for what the approval UI looks like.

What you can configure

You can’t reorder steps. You can:

• Swap the agent, or configure an ordered fallback list, globally or per-repo.
• Set explicit commands.lint, commands.format, and an optional targeted commands.test (local intent validation only; not a full CI suite), with commands.prepare when their dependencies must be materialized once in the isolated worktree.
• Store test evidence locally, upload GitHub.com/GHEC image/video attachments at PR time, and optionally publish an orphan evidence branch with test.evidence.
• Control auto-fix limits per step.
• Ignore paths during review and documentation checks.
• Disable or tune transcript-based intent extraction when intent is not supplied directly.
• Add repository gates after selected core steps.
• Skip steps for one run with no-mistakes --skip <steps>, git push -o no-mistakes.skip=<steps>, no-mistakes axi run --skip <steps>, or from the TUI.

See Configuration.

What you can’t configure

• The step order.
• Skipping specific steps permanently - per-run skips are allowed, but the pipeline itself always has all nine.
• Removing or replacing a core step. A repository can add extra gates after one, which only ever adds to what a pass means.

This is intentional. A pass has the same core guarantees across repositories, and repository gates can add guarantees without removing any of them.