# How Findings Are Classified with Action Types in no-mistakes: auto-fix, ask-user, and no-op

> Discover how the no-mistakes repository classifies findings using action types auto-fix ask-user and no-op to manage review issues and prevent accidental changes.

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

---

**The no-mistakes pipeline represents every review issue, lint error, or test failure as a Finding struct with an Action field set to `auto-fix`, `ask-user`, or `no-op`, where empty values default to `ask-user` to prevent accidental automated modifications.**

In the `kunchenguid/no-mistakes` repository, understanding how findings are classified with action types is critical for configuring CI workflows that balance automation with human oversight. Each finding carries an explicit classification that tells the pipeline whether to apply changes automatically, pause for user approval, or ignore the issue entirely. This classification system is implemented in [`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go) and drives decision-making throughout the review, lint, and document pipeline steps.

## Action Type Constants Defined in internal/types/findings.go

The three action constants are defined at lines 9–14 of [`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go) and determine the pipeline behavior for each finding:

- **`no-op`** – The finding is purely informational; no changes are required.
- **`auto-fix`** – The finding can be resolved automatically without human intervention, typically used for safe formatting changes.
- **`ask-user`** – The finding requires explicit human approval before proceeding.

These constants provide the vocabulary used throughout the codebase to express remediation intent.

## Default Action Handling with actionOrDefault

When a finding is created without an explicit action, the system applies a defensive default to prevent accidental auto-fixes. The `actionOrDefault` method at lines 33–45 implements this logic:

```go
func (f Finding) actionOrDefault() string {
    if f.Action == "" {
        return ActionAskUser          // default = ask‑user
    }
    return f.Action
}

```

If the `Action` field is empty, the system treats the finding as `ask-user`, ensuring that unknown issues always route to human review rather than automated modification.

## Filtering Findings by Action Type

The codebase provides three helper functions in [`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go) to query finding collections based on their effective action:

**`AutoFixableFindings`** (lines 53–61) returns a filtered collection containing only findings whose effective action is `auto-fix`, allowing the pipeline to batch automated fixes.

**`HasAskUserFindings`** (lines 15–24) reports whether any finding in a collection resolves to `ask-user`, including those with empty action fields that default to asking the user.

**`HasActionableFindings`** (lines 29–40) returns true if any finding requires actual work—meaning its effective action is either `auto-fix` or `ask-user`—effectively filtering out purely informational `no-op` findings.

These utilities enable pipeline steps to determine whether a batch of findings can be auto-resolved, requires human input, or can be skipped entirely.

## Creating and Overriding Findings with Default Actions

When users manually create findings or supply overrides through the configuration, the system assigns a default action of `auto-fix` unless an explicit `Action` value is provided. This logic appears at lines 96–100 of [`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go), reflecting the assumption that user-supplied findings indicate explicit intent for automatic remediation.

## Practical Code Examples for Action Classification

The following patterns demonstrate how to leverage the action type system in pipeline code:

**Selecting only auto-fixable findings:**

```go
// findings is a types.Findings value obtained from a pipeline step.
autoFixes := types.AutoFixableFindings(findings)

if len(autoFixes.Items) > 0 {
    // Pass these to the auto‑fix executor.
}

```

**Checking if a step requires human review:**

```go
if types.HasAskUserFindings(findings) {
    // The pipeline will park the run and wait for the user.
}

```

**Determining whether any work is needed:**

```go
if !types.HasActionableFindings(findings) {
    // All findings are no‑op → the step can be marked successful immediately.
}

```

## Summary

- **Findings are classified** using the `Action` field with three possible values: `no-op`, `auto-fix`, and `ask-user`.
- **Empty actions default to `ask-user`** via the `actionOrDefault` method in [`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go), preventing accidental automated changes.
- **Helper functions** `AutoFixableFindings`, `HasAskUserFindings`, and `HasActionableFindings` provide efficient filtering based on action types.
- **Manual overrides** default to `auto-fix` when no explicit action is specified, reflecting user intent for automatic remediation.
- The classification system drives the pipeline decision to auto-fix, pause for input, or skip issues entirely.

## Frequently Asked Questions

### What happens if a finding has no action specified?

If the `Action` field is empty, the `actionOrDefault` method treats the finding as `ask-user`, forcing the pipeline to wait for human approval before proceeding. This defensive default prevents the system from automatically modifying code when the safety of a fix is unknown.

### How does the pipeline determine if human review is required?

The pipeline calls `HasAskUserFindings` (defined at lines 15–24 of [`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go)) to check whether any finding in the current batch resolves to the `ask-user` action. This includes findings that explicitly set `Action` to `ask-user` and those with empty action fields that default to requiring human input.

### What is the difference between no-op and ask-user actions?

A `no-op` finding is purely informational and requires no changes to the codebase, allowing the pipeline to mark the step as successful immediately. An `ask-user` finding indicates that a change is needed but requires explicit human confirmation before the system modifies any files.

### Can manual findings be automatically fixed?

Yes, when users manually create findings or supply overrides without specifying an action, the system defaults to `auto-fix` (as implemented at lines 96–100 of [`internal/types/findings.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/types/findings.go)). This reflects the assumption that explicit user creation of a finding indicates desire for automatic remediation unless otherwise specified.