# What Are the Steps in the no-mistakes Validation Pipeline?

> Discover the nine essential steps of the no-mistakes validation pipeline, from Intent to CI. Learn how this robust process ensures code quality and streamlines your workflow.

- Repository: [Kun Chen/no-mistakes](https://github.com/kunchenguid/no-mistakes)
- Tags: how-to-guide
- Published: 2026-07-14

---

**The no-mistakes validation pipeline executes nine fixed steps—Intent, Rebase, Review, Test, Document, Lint, Push, PR, and CI—defined in [`types/types.go`](https://github.com/kunchenguid/no-mistakes/blob/main/types/types.go) and orchestrated by [`internal/pipeline/executor.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/executor.go).**

The `no-mistakes` tool from the `kunchenguid/no-mistakes` repository automates code review and validation through a rigid, ordered sequence of pipeline stages. Each step implements the `pipeline.Step` interface found in [`internal/pipeline/pipeline.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/pipeline.go) and lives in `internal/pipeline/steps/`. The order is hard-coded via `types.StepName` and enforced by the executor, ensuring every change undergoes the same validation flow regardless of the underlying LLM or CI provider.

## The Nine Steps of the no-mistakes Validation Pipeline

The pipeline runs in a strict sequence defined by `AllSteps()` in [`internal/types/types.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/types.go). Each step corresponds to a specific file in `internal/pipeline/steps/`:

### 1. Intent

Captures the author’s intent either from an explicit `--intent` flag or inferred from a transcript. Implemented in [`steps/intent.go`](https://github.com/kunchenguid/no-mistakes/blob/main/steps/intent.go), this step establishes the context for the review agent.

### 2. Rebase

Rebases the PR onto the latest target branch to ensure a clean merge base. The logic resides in [`steps/rebase.go`](https://github.com/kunchenguid/no-mistakes/blob/main/steps/rebase.go), preventing merge conflicts downstream.

### 3. Review

Runs the review-loop agent (Claude, Codex, or similar) to produce findings and suggestions. This core validation step is implemented in [`steps/review.go`](https://github.com/kunchenguid/no-mistakes/blob/main/steps/review.go) and leverages durable sessions managed by [`internal/pipeline/sessions.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/sessions.go).

### 4. Test

Executes the project’s test suite if configured. The [`steps/test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/steps/test.go) implementation handles test runner integration and result collection.

### 5. Document

Verifies documentation placement policy and optionally generates docs. Found in [`steps/document.go`](https://github.com/kunchenguid/no-mistakes/blob/main/steps/document.go), this step ensures compliance with project documentation standards.

### 6. Lint

Runs the linter, or a combined doc-plus-lint pass when `commands.lint` is empty. Implemented in [`steps/lint.go`](https://github.com/kunchenguid/no-mistakes/blob/main/steps/lint.go).

### 7. Push

Pushes the (possibly rebased) commit(s) to the remote gate repository. The [`steps/push.go`](https://github.com/kunchenguid/no-mistakes/blob/main/steps/push.go) file handles Git remote operations.

### 8. PR

Creates or updates a pull/merge request on the upstream host. Logic in [`steps/pr.go`](https://github.com/kunchenguid/no-mistakes/blob/main/steps/pr.go) manages platform-specific APIs for GitHub, GitLab, or Bitbucket.

### 9. CI

Triggers any CI checks configured for the gate, such as GitHub Actions, GitLab CI, or Bitbucket Pipelines. The final step is implemented in [`steps/ci.go`](https://github.com/kunchenguid/no-mistakes/blob/main/steps/ci.go).

## How the Pipeline Executes

The executor in [`internal/pipeline/executor.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/executor.go) coordinates the fixed sequence. It creates a `StepContext` containing database handles, repository info, the agent, and logging helpers, then iterates through `AllSteps()`.

Each step’s `Execute` method receives the context and can return:

- **`NeedsApproval=true`** to pause for user input
- **`AutoFixable=true`** to enable an automatic fix round
- **`SkipRemaining`** to halt the pipeline early

The executor records outcomes in the database and manages durable review-loop sessions via [`internal/pipeline/sessions.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/sessions.go).

## Triggering the Pipeline Programmatically

The CLI entry point in [`internal/cli/axi.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/cli/axi.go) demonstrates the standard invocation pattern. The `axi run` command builds the default step list and delegates to the executor:

```go
func runCmd(ctx *cli.Context) error {
    // 1️⃣ Load config, DB, and repo
    cfg := config.Load()
    db  := db.Open(cfg.DBPath)

    // 2️⃣ Build the pipeline steps (default order)
    steps := pipeline.AllSteps()

    // 3️⃣ Create a pipeline executor
    exec := pipeline.NewExecutor(db, cfg, steps)

    // 4️⃣ Run the pipeline for the current gate repo
    run, err := exec.Run(context.Background(), repo)
    if err != nil {
        return err
    }
    fmt.Printf("Run %s completed with status %s\n", run.ID, run.Status)
    return nil
}

```

Running `no-mistakes axi run` invokes this flow, printing the status of each step as it progresses through Intent → CI.

## Summary

- The **no-mistakes validation pipeline** consists of nine fixed steps: Intent, Rebase, Review, Test, Document, Lint, Push, PR, and CI.
- Step order is defined in [`internal/types/types.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/types.go) via `AllSteps()` and enforced by [`internal/pipeline/executor.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/executor.go).
- Each step implements the `pipeline.Step` interface and resides in `internal/pipeline/steps/`.
- The executor handles pauses for approval, automatic fixes, and database persistence via `StepContext`.
- Invoke the full pipeline using the `axi run` command from [`internal/cli/axi.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/cli/axi.go).

## Frequently Asked Questions

### Can I skip or reorder steps in the no-mistakes validation pipeline?

No. The order is hard-coded in `types.StepName.Order()` and returned by `AllSteps()` in [`internal/types/types.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/types.go). While individual steps can signal `SkipRemaining` to halt the pipeline early, you cannot customize the sequence without modifying the source code.

### What happens if a step fails or needs human approval?

The executor in [`internal/pipeline/executor.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/executor.go) checks the return values from each step’s `Execute` method. If `NeedsApproval` is true, the pipeline pauses for user input. If `AutoFixable` is true, the system can initiate an automatic fix round using the review-loop agent before retrying.

### How does the Review step interact with different LLM providers?

The Review step in [`steps/review.go`](https://github.com/kunchenguid/no-mistakes/blob/main/steps/review.go) uses the durable session manager in [`internal/pipeline/sessions.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/sessions.go) to maintain state across interactions. It abstracts the specific provider (Claude, Codex, etc.) behind the `pipeline.Step` interface, allowing the same execution flow regardless of the underlying model.

### Where is the pipeline state stored between steps?

The `StepContext` passed to each step contains database handles initialized from the configuration. The executor records outcomes and status in this database after each step completes, enabling resumable runs and audit trails across the Intent-through-CI lifecycle.