# No-Mistakes Pipeline Execution Order: Complete 9-Step Sequence

> Master the no-mistakes pipeline execution order with this complete 9-step sequence. Ensure your code goes through Intent, Rebase, Review, Test, Document, Lint, Push, PR, and CI flawlessly.

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

---

**The no-mistakes CLI executes nine pipeline steps in a fixed deterministic sequence: Intent → Rebase → Review → Test → Document → Lint → Push → PR → CI.**

The kunchenguid/no-mistakes repository implements a rigid execution framework to ensure code quality gates are processed consistently before deployment. This execution order is hardcoded in the source code through the `StepName` type constants and enforced by the daemon during every run.

## Fixed Execution Sequence of No-Mistakes Pipeline Steps

The no-mistakes pipeline defines a total of nine sequential steps, each represented by a typed constant in [`internal/types/types.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/types.go). The execution proceeds strictly from order 1 through order 9:

| Order | Step Name | Constant | Purpose |
|-------|-----------|----------|---------|
| 1 | **Intent** | `StepIntent` | Captures the developer's intent for the change |
| 2 | **Rebase** | `StepRebase` | Ensures branch is up-to-date with base |
| 3 | **Review** | `StepReview` | Code review validation |
| 4 | **Test** | `StepTest` | Automated test execution |
| 5 | **Document** | `StepDocument` | Documentation generation/checks |
| 6 | **Lint** | `StepLint` | Static analysis and linting |
| 7 | **Push** | `StepPush` | Remote repository push |
| 8 | **PR** | `StepPR` | Pull request creation/management |
| 9 | **CI** | `StepCI` | Continuous integration triggers |

The **Review → Test → Document → Lint → Push → PR → CI** sequence represents the core quality assurance and delivery phases, while **Intent** and **Rebase** serve as preparatory steps that ensure proper context and repository state.

## Core Implementation in [`internal/types/types.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/types.go)

The canonical execution order is defined in [`internal/types/types.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/types.go) through two primary constructs: the `Order()` method and the `AllSteps()` function.

The `Order()` method (lines 77–97) returns the integer position for each step constant:

```go
// internal/types/types.go
func (s StepName) Order() int {
    switch s {
    case StepIntent:   return 1
    case StepRebase:   return 2
    case StepReview:   return 3
    case StepTest:     return 4
    case StepDocument: return 5
    case StepLint:     return 6
    case StepPush:     return 7
    case StepPR:       return 8
    case StepCI:       return 9
    default:           return 0
    }
}

```

The `AllSteps()` function (lines 103–106) returns the complete slice in execution order:

```go
// AllSteps returns all pipeline steps in execution order.
func AllSteps() []StepName {
    return []StepName{
        StepIntent, StepRebase, StepReview,
        StepTest, StepDocument, StepLint,
        StepPush, StepPR, StepCI,
    }
}

```

These definitions establish the single source of truth for step sequencing throughout the codebase.

## How the Daemon Enforces Step Order

When initializing a pipeline run, the daemon builds the execution plan by invoking `steps.AllSteps()` to retrieve the ordered slice. In [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) (line 59), the manager constructs the pipeline using this fixed sequence, ensuring that each step completes successfully before the next begins.

This design guarantees that **Test** cannot execute before **Review** completes, and **Push** cannot occur until **Lint** finishes. The daemon validates step transitions by comparing `Order()` values, rejecting any attempt to execute steps out of sequence.

## Practical Examples for Working with Step Order

### Retrieve the Full Pipeline Sequence

Use `AllSteps()` to iterate through the execution order programmatically:

```go
package main

import (
    "fmt"
    "github.com/kunchenguid/no-mistakes/internal/types"
)

func main() {
    for i, step := range types.AllSteps() {
        fmt.Printf("%d: %s (order %d)\n", i+1, step, step.Order())
    }
}

```

**Output:**

```

1: intent (order 1)
2: rebase (order 2)
3: review (order 3)
4: test (order 4)
5: document (order 5)
6: lint (order 6)
7: push (order 7)
8: pr (order 8)
9: ci (order 9)

```

### Compare Step Precedence

Validate relative positioning using the `Order()` method:

```go
import "github.com/kunchenguid/no-mistakes/internal/types"

func isReviewBeforeLint() bool {
    return types.StepReview.Order() < types.StepLint.Order()
}

```

This returns `true` because Review (order 3) precedes Lint (order 6).

### Enforce Step-Specific Logic

Conditionally execute validation based on pipeline position:

```go
func enforceHeadContinuity(step types.StepName, headSHA string) error {
    // All steps after Review verify that the head matches the approved SHA.
    if step.Order() > types.StepReview.Order() {
        // ... validation logic ...
    }
    return nil
}

```

## Summary

- The no-mistakes pipeline executes **nine fixed steps** in the order: Intent, Rebase, Review, Test, Document, Lint, Push, PR, CI.
- Step ordering is defined in [`internal/types/types.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/types.go) via the `Order()` method and `AllSteps()` function.
- The daemon in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) enforces this sequence by iterating over the ordered slice returned by `AllSteps()`.
- Each `StepName` constant maps to an integer (1–9) that determines its execution priority and transition eligibility.
- Developers can query step precedence programmatically using the `Order()` method to implement conditional logic based on pipeline position.

## Frequently Asked Questions

### Can I customize the execution order of no-mistakes pipeline steps?

No, the execution order is hardcoded in the `Order()` method within [`internal/types/types.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/types.go). The switch statement assigns fixed integer values (1–9) to each step constant, and the daemon relies on `AllSteps()` to build the pipeline. Modifying the sequence would require changing the source code and recompiling the CLI.

### What happens if a step fails during pipeline execution?

The pipeline halts at the failed step and does not proceed to subsequent steps with higher `Order()` values. For example, if **Lint** (order 6) fails, the pipeline stops before reaching **Push** (order 7), **PR** (order 8), or **CI** (order 9). The daemon tracks state transitions and prevents out-of-order execution even when retrying failed steps.

### Which step runs immediately after the Review phase?

**Test** runs immediately after Review. According to the `Order()` implementation in [`internal/types/types.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/types.go), Review returns order 3 and Test returns order 4. The `AllSteps()` function places these constants in adjacent positions in the returned slice, ensuring Test executes directly after Review completes successfully.

### How can I programmatically check if a specific step runs before Push?

Compare the `Order()` values of the steps in question. Any step with an `Order()` return value less than 7 (the order of `StepPush`) executes before Push:

```go
func runsBeforePush(step types.StepName) bool {
    return step.Order() < types.StepPush.Order()
}

```

This returns `true` for Intent, Rebase, Review, Test, Document, and Lint, but `false` for PR and CI.