No-Mistakes Gate Types Explained: Awaiting Approval vs Fix Review

The no-mistakes framework defines exactly two gate types—awaiting_approval and fix_review—which pause pipeline execution whenever a step requires human intervention, either for initial approval or for reviewing an automatically applied fix.

The no-mistakes tool (available at kunchenguid/no-mistakes) implements a guarded execution model that pauses CI/CD runs at critical decision points. Understanding the different no-mistakes gate types is essential for operators who need to respond correctly when the pipeline surfaces findings requiring human input.

What Are No-Mistakes Gates?

In the no-mistakes architecture, a gate is a pause point where the pipeline executor stops and waits for user direction before proceeding. According to the source code in internal/pipeline/executor.go, these gates activate when a step emits findings that are not yet resolved or when an automatic fix cycle completes. The system represents these pause states using specific step-status values defined in the StepStatus type.

The Two No-Mistakes Gate Types

The gate types correspond to two distinct constants in internal/types/types.go:

type StepStatus string

const (
    StepStatusPending          StepStatus = "pending"
    StepStatusRunning          StepStatus = "running"
    StepStatusAwaitingApproval StepStatus = "awaiting_approval"
    StepStatusFixing           StepStatus = "fixing"
    StepStatusFixReview        StepStatus = "fix_review"
    // …
)

Only StepStatusAwaitingApproval and StepStatusFixReview represent actual gate states that require user interaction.

Awaiting Approval (awaiting_approval)

awaiting_approval gates appear when the pipeline encounters a step with unresolved findings that need human direction. This status surfaces on steps like review, test, document, lint, push, PR, or CI when they produce warnings or errors that haven't been addressed.

When this gate triggers, the CLI renders a gate: object (as implemented in internal/cli/axi_render.go) listing findings with their severity, file location, and suggested actions. You must respond with one of three actions:

• --action approve to accept the findings and continue
• --action fix to apply corrections to specific findings
• --action skip to bypass the current step

Fix Review (fix_review)

fix_review gates occur after the pipeline's auto-fix logic has modified code. This status indicates that a fix cycle completed and the changes now require human validation before the run continues.

Unlike the initial approval gate, fix_review specifically asks you to verify automatically applied changes. You typically respond with --action approve to accept the fixes, or --action fix to provide additional instructions for further amendments.

Which Pipeline Steps Can Hit a Gate?

Not every step in the no-mistakes pipeline creates a gate. According to the skill documentation in internal/skill/skill.go (lines 48-50), gates can appear in any step after rebase that may produce findings requiring user judgment.

The steps that can trigger no-mistakes gates include:

• review – Code review findings requiring approval
• test – Test failures needing investigation
• document – Documentation gaps or errors
• lint – Linting violations (often auto-fixable)
• push – Pre-push validation issues
• PR – Pull request check failures
• CI – Continuous integration errors

These steps enter awaiting_approval when first encountering issues, and may transition to fix_review after automatic remediation attempts.

How to Respond to Gate Types

The no-mistakes axi respond command handles both gate types. The specific --action flag you use depends on which gate status is active.

Respond to an initial approval gate:

no-mistakes axi respond --action approve

Fix specific findings by ID:

no-mistakes axi respond \
    --action fix \
    --findings r1,r3 \
    --instructions "Rename the temp variable for clarity"

Skip a noisy or irrelevant step:

no-mistakes axi respond --action skip

Accept changes after a fix review cycle:

no-mistakes axi respond --action approve

When a gate appears, the CLI displays the gate type, affected findings, and available commands, blocking execution until you provide one of these responses.

Source Code Implementation

The no-mistakes gate types are implemented across several key files:

• internal/types/types.go – Defines the StepStatus constants (awaiting_approval, fix_review)
• internal/pipeline/executor.go – Contains the logic that switches step statuses to gate states
• internal/skill/skill.go – Lines 48-50 document which pipeline steps can become gates
• internal/cli/axi_render.go – Handles rendering of the gate: object and findings list displayed to users
• internal/pipeline/steps/review.go – Example step implementation that can emit an approval gate

Summary

• Two gate types exist: awaiting_approval for initial human input, and fix_review for validating auto-applied fixes
• Defined in internal/types/types.go as StepStatus constants
• Triggering steps include review, test, document, lint, push, PR, and CI (any step that can produce findings)
• CLI response uses no-mistakes axi respond with --action flags (approve, fix, or skip) depending on gate type

Frequently Asked Questions

What is the difference between awaiting_approval and fix_review gates?

awaiting_approval gates pause the run when a step first encounters unresolved findings, requiring you to approve, fix, or skip the step. fix_review gates appear specifically after the pipeline automatically applies fixes, asking you to review and approve those changes before the run continues.

Which pipeline steps can trigger a no-mistakes gate?

According to internal/skill/skill.go, steps that occur after rebase and may produce findings can trigger gates. These include review, test, document, lint, push, PR, and CI steps.

How do I skip a gate in no-mistakes?

Use the skip action with the CLI command: no-mistakes axi respond --action skip. This tells the pipeline to bypass the current step and continue execution, which is useful for handling noisy lint warnings or intentional technical debt.

Where are the gate statuses defined in the source code?

The gate statuses (awaiting_approval and fix_review) are defined as constants in internal/types/types.go within the StepStatus type definition. The switching logic that transitions steps into these statuses is implemented in internal/pipeline/executor.go.

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