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

The no-mistakes validation pipeline executes nine fixed steps—Intent, Rebase, Review, Test, Document, Lint, Push, PR, and CI—defined in types/types.go and orchestrated by 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 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. 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, 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, 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 and leverages durable sessions managed by internal/pipeline/sessions.go.

4. Test

Executes the project’s test suite if configured. The 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, 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.

7. Push

Pushes the (possibly rebased) commit(s) to the remote gate repository. The 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 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.

How the Pipeline Executes

The executor in 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.

Triggering the Pipeline Programmatically

The CLI entry point in internal/cli/axi.go demonstrates the standard invocation pattern. The axi run command builds the default step list and delegates to the executor:

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 via AllSteps() and enforced by 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.

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. 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 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 uses the durable session manager in 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}