# Pipeline Steps Executed When Pushing Through the no-mistakes Gate: Complete Technical Guide

> Discover the 9 essential pipeline steps executed when pushing through the no-mistakes gate. Validate intent run reviews tests linting docs rebasing and more before the final push.

- Repository: [Kun Chen/no-mistakes](https://github.com/kunchenguid/no-mistakes)
- Tags: deep-dive
- Published: 2026-07-19

---

**When pushing through the no-mistakes gate, the system executes a deterministic 9-step pipeline that validates intent, runs reviews, tests, linting, documentation checks, rebasing, and final push operations before allowing code to reach the remote.**

The `kunchenguid/no-mistakes` repository implements a Git push interception daemon that enforces code quality through a rigid pipeline architecture. Each push triggers an ordered sequence of validation steps defined in [`internal/pipeline/executor.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/executor.go), ensuring that only reviewed, tested, and properly documented changes enter the remote repository.

## Pipeline Architecture and Execution Model

The pipeline runner in [`internal/pipeline/executor.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/executor.go) constructs an ordered slice of steps based on the static `StepOrder` constant. Each step implements the `pipeline.Step` interface and exposes an `Execute` method that the runner invokes sequentially. Steps may pause execution awaiting human approval or abort the run if auto-fixes fail, but the execution order remains fixed for standard push flows.

The architecture separates concerns into discrete, testable units where earlier steps gather intent and evidence while later steps apply transformations and validation. This deterministic ordering ensures that documentation policies apply after linting, and rebasing occurs before the final push operation.

## The 9 Pipeline Steps in Execution Order

### 1. IntentStep

**File:** [`internal/pipeline/steps/intent.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/intent.go)

The pipeline begins with **IntentStep**, which analyzes commit messages and branch names to detect the developer's intent—whether the change represents a feature, bug-fix, or refactor. This step records the detected intent for conformance checks in subsequent stages, establishing the context that drives later validation logic.

### 2. ReviewStep

**File:** [`internal/pipeline/steps/review.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/review.go)

**ReviewStep** runs the review agent against the computed diff, surfacing bugs, security vulnerabilities, and documentation gaps before any code reaches the remote. This pre-push review acts as the primary quality gate, catching issues that traditional CI might miss until after the push completes.

### 3. TestStep

**File:** [`internal/pipeline/steps/test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/test.go)

The **TestStep** executes the project's test suite and aggregates failure reports. When configured, this step can invoke the agent to generate automatic fixes for failing tests, reducing the manual intervention required to achieve a passing build state.

### 4. LintStep

**File:** [`internal/pipeline/steps/lint.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/lint.go)

**LintStep** runs the configured static analysis tools. When the lint configuration is empty, this step combines with document validation to run a consolidated doc-plus-lint check. It records style violations and static analysis findings that must be resolved before proceeding.

### 5. DocumentStep

**File:** [`internal/pipeline/steps/document.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/document.go)

The **DocumentStep** enforces the documentation placement policy, ensuring new documentation files are correctly owned and that stale duplicates are converted into pointers. This step maintains documentation integrity by preventing orphaned or conflicting doc files from entering the repository.

### 6. RebaseStep

**File:** [`internal/pipeline/steps/rebase.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/rebase.go)

**RebaseStep** rebases the local branch onto the latest upstream default branch. It detects unpushed local-default commits and explicitly refuses unsafe force-pushes, preventing history rewriting that could destabilize the shared repository. This step ensures linear history and up-to-date code before the final push.

### 7. PushStep

**File:** [`internal/pipeline/steps/push.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/push.go)

The **PushStep** performs the actual `git push` operation. When force-push is required and permitted, it uses `git push --force-with-lease` to prevent overwriting commits that may have been pushed by other developers since the last fetch. This step only executes after all preceding validation steps succeed.

### 8. PRStep

**File:** [`internal/pipeline/steps/pr.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/pr.go)

When configured to open a pull request rather than perform a direct push, **PRStep** creates the PR on the remote service (GitHub, GitLab, or others). This step bridges the gap between local validation and remote collaboration workflows, ensuring that repository-specific PR templates and policies are applied.

### 9. CIStep

**File:** [`internal/pipeline/steps/ci.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/ci.go)

The final **CIStep** triggers the configured continuous integration pipeline (GitHub Actions, GitLab CI, etc.) and monitors execution results. This post-push validation ensures that the changes integrate correctly with the broader codebase and that deployment pipelines receive verified artifacts.

## Step Execution and Failure Handling

The executor iterates through the `StepOrder` slice, calling each step's `Execute` method in sequence. A step may return a **pause** signal to await reviewer approval or an **abort** signal if it encounters unresolvable findings. The pipeline maintains strict ordering: documentation checks follow linting, rebasing precedes pushing, and CI triggers only after the push or PR creation succeeds.

This ordering guarantees that expensive operations (like CI) run only after local validation passes, while destructive operations (like rebasing) occur after the working directory has been validated but before the irreversible push.

## Summary

- The no-mistakes pipeline executes **9 deterministic steps** for every intercepted push, defined in [`internal/pipeline/executor.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/executor.go).
- **IntentStep** establishes context first, followed by **ReviewStep** and **TestStep** for quality validation.
- **LintStep** and **DocumentStep** enforce code style and documentation policies before structural changes.
- **RebaseStep** ensures safe, linear history before **PushStep** transmits changes to the remote.
- **PRStep** and **CIStep** handle remote collaboration and post-push validation when configured.
- Each step implements the `pipeline.Step` interface and operates through the `Execute` method, with execution order controlled by the static `StepOrder` constant.

## Frequently Asked Questions

### What happens if a step fails during the no-mistakes pipeline?

If a step encounters unresolvable issues, it aborts the pipeline and prevents the push from completing. Steps capable of auto-fixing (like **TestStep** with fix generation enabled) may attempt repairs first, but the pipeline stops immediately if a step returns a fatal error or if the developer chooses not to apply suggested fixes.

### Can I skip specific pipeline steps when pushing through the gate?

No, the execution order is fixed by the `StepOrder` constant in [`internal/pipeline/executor.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/executor.go). The pipeline is designed to run all nine steps for every push to maintain consistent quality guarantees. Steps may complete instantly if they have no work to perform (e.g., **PRStep** when not in PR mode), but they cannot be bypassed entirely.

### How does the rebase step prevent force-push accidents?

**RebaseStep** in [`internal/pipeline/steps/rebase.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/rebase.go) detects unpushed local-default commits and refuses unsafe force-pushes that would overwrite remote history. It uses `git push --force-with-lease` when force operations are required, ensuring the remote ref matches the expected state before rewriting history, thus preventing the accidental destruction of colleagues' work.

### Where is the pipeline step order defined?

The static execution order is defined in [`internal/pipeline/executor.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/executor.go) through the `StepOrder` constant, which constructs the ordered slice of `pipeline.Step` implementations. This constant lists steps from **IntentStep** through **CIStep**, ensuring the pipeline always runs validation, transformation, and push operations in the correct sequence.