# no-mistakes ask-user vs auto-fix Finding Categorization: When to Block vs Auto-Resolve

> Understand ask-user vs auto-fix finding categorization in no-mistakes. Learn when to block or auto-resolve issues for efficient code pipeline operation.

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

---

**In the no-mistakes pipeline, `auto-fix` findings are safe, mechanical issues resolved automatically without human input, while `ask-user` findings challenge user intent or product behavior and force the pipeline to pause until explicitly approved.**

The `no-mistakes` repository classifies every detected issue—whether from review, test, lint, or CI steps—as a **Finding** with an associated action string. This categorization determines whether the pipeline can proceed automatically or must stop for human review. Understanding the distinction between `ask-user` and `auto-fix` is essential for configuring safe automation boundaries.

## Where Action Constants Are Defined

The three possible finding actions are declared as string constants in **[`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go)** at lines 10-13:

```go
const (
    ActionNoOp    = "no-op"
    ActionAutoFix = "auto-fix"
    ActionAskUser = "ask-user"
)

```

User-facing descriptions of these actions reside in **[`internal/skill/skill.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/skill/skill.go)** (lines 46-53), where the CLI documentation explains that `auto-fix` represents mechanical and low-risk changes, while `ask-user` indicates the finding challenges the user's deliberate intent.

## Understanding the auto-fix Category

**`auto-fix`** findings identify problems that the pipeline can correct automatically without risking user intent or product-level behavior. These fixes are deterministic, safe, and low-risk.

Common examples include:
- Trivial style violations
- Missing imports
- Formatting inconsistencies
- Dead code removal that does not affect API surface

Because `auto-fix` findings do not alter functional behavior or intentional design choices, the executor can apply resolutions immediately when running with `--action fix` or `--action approve` flags.

## Understanding the ask-user Category

**`ask-user`** findings flag issues that touch the user's deliberate intent, product behavior, or functional requirements. These findings **must** be reviewed by a human or an explicitly authorized agent before any change is applied.

Examples of `ask-user` findings include:
- Hard-coded values that should be configurable
- Deletions of code that appear intentional
- Changes that could affect the public API
- Modifications to security-critical configurations

When the pipeline encounters even a single `ask-user` finding, it creates a gate that pauses execution and requires a response via `no-mistakes axi respond` before proceeding.

## Pipeline Execution and Gate Logic

The executor uses the helper function `HasAskUserFindings` defined in **[`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go)** (lines 203-210) to determine whether a step can proceed unattended:

```go
func HasAskUserFindings(findings Findings) bool {
    for _, item := range findings.Items {
        if item.Action == ActionAskUser {
            return true
        }
    }
    return false
}

```

The pipeline behavior follows this logic:

1. **Automatic resolution** occurs when all findings are `auto-fix` or `no-op`. The step resolves without human intervention.
2. **Gating** occurs when `HasAskUserFindings` returns `true`. The pipeline pauses, awaiting human response through the CLI.
3. **`--yes` mode** bypasses the gate by pre-approving all `ask-user` findings, treating them identically to `auto-fix` for unattended automation scenarios.

## Practical Code Examples

### Creating Findings with Different Actions

In **[`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go)**, the `Finding` struct uses the action constants to categorize issues. Here is how step implementations construct these findings:

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

func exampleFindings() types.Findings {
    return types.Findings{
        Items: []types.Finding{
            {
                ID:          "auto-1",
                Severity:    "warning",
                Description: "unused import – can be removed automatically",
                Action:      types.ActionAutoFix,
            },
            {
                ID:          "user-1",
                Severity:    "error",
                File:        "config.go",
                Line:        42,
                Description: "hard-coded API endpoint – should be configurable",
                Action:      types.ActionAskUser,
            },
        },
    }
}

```

### Checking Findings in the Executor

Step implementations in **`internal/pipeline/steps/*`** use the findings helpers to determine execution flow:

```go
func handleFindings(f types.Findings) {
    if types.HasAskUserFindings(f) {
        // Pause the run – the user must answer.
        fmt.Println("🔒 Gate: ask-user findings present")
        // Sends FINDINGS back to the CLI for `axi respond`
    } else if types.HasActionableFindings(f) {
        // Safe to auto-fix everything.
        fmt.Println("✅ Auto-fixing findings")
        // Invoke the auto-fix step
    } else {
        fmt.Println("🟢 No actionable findings")
    }
}

```

### Responding to ask-user Findings from the CLI

When the pipeline gates on an `ask-user` finding, inspect the status and respond accordingly:

```bash

# Check current gate status

no-mistakes axi status

# → gate: ... findings: [{id:"user-1",action:"ask-user",...}]

# Approve the finding as-is

no-mistakes axi respond --action approve

# Or request a fix with specific instructions

no-mistakes axi respond \
    --action fix \
    --findings user-1 \
    --instructions "Make the endpoint configurable via ENV"

```

## Summary

- **`auto-fix`** in no-mistakes represents mechanical, low-risk issues that the pipeline can resolve automatically without human review.
- **`ask-user`** protects intentional design choices by flagging findings that affect user intent, product behavior, or API compatibility.
- The **`HasAskUserFindings`** function in [`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go) determines whether a pipeline step must gate and await human response.
- **`--yes` mode** bypasses `ask-user` gates for fully automated environments where explicit pre-approval has been granted.
- Categories are defined as constants in [`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go) and documented in [`internal/skill/skill.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/skill/skill.go).

## Frequently Asked Questions

### What happens if a step contains both auto-fix and ask-user findings?

If **any** finding in a step has the `ask-user` action, the entire step gates regardless of other `auto-fix` findings present. The pipeline pauses and requires human response via `no-mistakes axi respond` before proceeding.

### Can I override ask-user blocking behavior in automation?

Yes. Running the pipeline with the **`--yes`** flag pre-approves all `ask-user` findings, allowing the executor to treat them identically to `auto-fix` findings. This is useful for unattended CI/CD environments where explicit human confirmation is not feasible.

### How do I configure which findings categories block the pipeline?

Projects can tune gate behavior through configuration settings such as `auto_fix.review: 0`, which ensures that `ask-user` findings always block the pipeline even if other parts of the step could be auto-resolved. The pipeline logic respects these settings in the step implementations located in **`internal/pipeline/steps/*`**.

### Where are the action constants defined in the source code?

The `ActionAutoFix` and `ActionAskUser` constants are defined in **[`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go)** at lines 10-13. Helper functions like `HasAskUserFindings` (lines 203-210) and user-facing documentation in **[`internal/skill/skill.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/skill/skill.go)** (lines 46-53) provide the complete implementation and description of these categorizations.