Linters that wish to make changes should emit a line and character position (or an absolute offset), "old" text (the incorrect text to replace) and "new" text (the suggested text to replace it with) -- for script-and-regex, these are original and replacement. They should tell arc what to fix; they should not mutate the working copy themselves.

arc handles making the changes, prompting the user if appropriate, letting them choose individual changes to apply if they only want to accept a subset of the changes, amending the changes into commits, and detecting potential conflicts when multiple linters wish to affect the same character range.

Beyond supporting these interactions, emitting a description of intended edits (rather than mutating the working copy directly) allows multiple linters to be run in parallel safely and allows flags like --never-apply-patches to work.

When a linter works like this, users see a workflow similar to this:

• By default, arc prompts the user and lets them accept or reject each change (this can be adjusted with --apply-patches or --never-apply-patches).
• If they accept some changes, it applies the changes they accepted to the working copy at the end, then asks them to confirm that they want to amend/commit them (this can be adjusted with --amend-all or --amend-autofixes).
• Depending on the value of history.immutable, it either amends the changes to HEAD (with mutable history) or creates a new commit containing the lint fixes (with immutable history.

(See also T10038 for a broader discussion of the status of linter integrations.)