Why can ktlintFormat succeed while ktlintCheck still reports violations on the same code?

## The symptom Someone runs the ktlint format task, watches it succeed, pushes, and the build fails on the ktlint check task pointing at a file the format task just touched. It looks like a bug, or like the two tasks disagree. Neither is true, and being able to say why is the point of this question. ## One engine, two modes ktlint parses Kotlin source into the compiler's syntax tree and runs a set of rules over it. Every rule can *report* a violation. Only some rules can additionally *fix* one, by rewriting nodes in that tree before the file is written back to disk. Check mode runs the rules and reports; format mode runs the same rules with the same configuration and additionally applies the fixes that exist. The configuration, the active rule set and the enabled/disabled state of each rule are identical between the two modes — that is why "they must be reading different config" is the wrong diagnosis. So the outcome of a format run is: *all autocorrectable violations are gone; all non-autocorrectable violations remain, and were reported to you*. A subsequent check run finds exactly that remainder. ## Why some rules cannot autocorrect The dividing line is whether the correction is mechanical or a judgment call. **Mechanical, so fixable.** There is exactly one right answer and no information is lost. Indentation depth, spacing around operators and keywords, trailing whitespace, a missing final newline, the order of imports, blank-line rules, curly-brace placement. The tool can compute the corrected text from the syntax tree alone. **A judgment call, so lint-only.** The tool would have to invent something a human owns: - Naming rules such as `standard:function-naming`, `standard:property-naming` and `standard:class-naming` would have to choose a new identifier. Any rename is also a semantic change that ripples through call sites, so a formatter must not attempt it. - `standard:filename` and `standard:package-name` would have to move or rename a file, which is a refactoring, not a formatting pass. - `standard:max-line-length` would have to decide *where* a long line should break, which is a readability decision. A very long string literal or a single long identifier cannot be broken at all. That last one deserves care, because it is where the naive mental model breaks. ktlint does have wrapping rules — argument-list wrapping, chain wrapping, general wrapping — that reformat long constructs, and when they are enabled they often bring a line back under the limit as a side effect. But `max-line-length` itself does not wrap anything; it measures. If the wrapping rules are disabled in a project's configuration, or the line is one unbreakable token, the length violation survives every format run you throw at it. ## How to react The report line names the rule id in parentheses, and that id tells you which of three actions is correct: 1. **Fix the code by hand.** Rename the function, split the line, move the file. This is right when the rule expresses a standard the project actually holds. 2. **Turn the rule off in configuration.** Right when the rule encodes an opinion the project has deliberately rejected — for example a codebase that permits long comment lines, or test method names that would fail a naming rule. 3. **Grandfather it.** Right only while adopting ktlint on an existing codebase, and only for violations you intend to work through. What is *not* right is re-running the format task, clearing caches, or bisecting configuration, all of which are the common time sinks when the candidate believes the format task should have fixed everything. ## Why teams hit this The convention "format first, then check" makes the format task feel like a guarantee, and for a while it is: a codebase that only ever violates whitespace rules is fully auto-fixable, so the first non-autocorrectable finding is a surprise. It usually appears when a project turns on more opinionated rules, or when someone writes a test method or a DSL builder whose name is intentionally unconventional. Knowing the two classes of rule up front means the failure reads as expected behaviour rather than tooling flakiness — and it is why a build should surface the rule id in its output rather than just a pass/fail. ## What interviewers listen for The strong answer states the autocorrectable/lint-only split as a property of the rules, gives at least one concrete lint-only rule id, and explains the underlying principle: a formatter may rewrite layout, never meaning. The weak answer treats the format task as "fix everything" and looks for an environmental explanation.