## TL;DR

ktlint found style violations (indentation, imports, spacing). Run `ktlint --format` on the changed files to auto-fix what it can, then fix the remaining reported violations by hand.

## Error

```text
src/main/kotlin/com/acme/Api.kt:27:1: Unexpected indentation (4) (should be 8) (indent)
```

## Steps

1. Reproduce locally: run `./gradlew ktlintCheck` or `ktlint "src/**/*.kt"`. Expected: the same violation list CI shows.
2. Auto-fix: run `ktlint --format "src/**/*.kt"` (or `./gradlew ktlintFormat`). Expected: formatting violations like indentation and import order disappear.
3. Fix the rest manually: read each remaining rule message (e.g. `no-wildcard-imports`) and adjust the code. Expected: no violations remain.
4. Re-run the check. Expected: `BUILD SUCCESSFUL` / no findings, and the PR gate passes.

## When to use

- ktlint (CLI or Gradle plugin) reports style violations and fails the PR.
- The violations are formatting/style, not design.

## When not to use

- detekt reports complexity or code-smell issues  -  that is a different tool with different fixes.
- The build itself fails to compile; fix compilation first.

## Tool compatibility

- ktlint 0.50+ / Gradle ktlint plugin.
- Kotlin 1.8+.

## Variant phrasings

### ktlint fails only in CI, passes locally

Version drift: pin the same ktlint version in CI and locally.

### Too many violations to fix at once

Run the formatter first; it typically clears the majority automatically.

## Why it happens

ktlint enforces the official Kotlin code style. The check task fails the build on any violation, so unformatted code blocks the PR even when tests pass.

## Edge cases

- `--format` rewrites files; review the diff before committing  -  it occasionally reformats in surprising ways.
- Baseline files can grandfather existing violations while new code stays clean.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ldRKHLfvuwgVkxpz3LOJ8Q