[devlint]

Two engine bugs found while checking the examples of the trivial-conflicts taxonomy article, plus a third one in the same code path.

Imports: same module in two forms kept both lines

<<<<<<< ours
import React from "react";
import { useAuth } from "./auth";
||||||| base
import React from "react";
=======
import React from "react";
import useAuth from "./auth";
>>>>>>> theirs

The imports resolver correctly found the conflict (incompatible kinds (named vs default)), but a null from a format-aware resolver only meant "not applicable", so the hunk went on to the textual engine. The textual engine classified it insertion_at_boundary and applied it, keeping both lines: useAuth was declared twice.

Fix: ImportMergeResult and FormatResolveResult get a conflict flag, set on the resolver's semantic-conflict returns (and not on "the block is not imports" or "line cannot be parsed", which still fall through). dispatchFormatAware returns a new conflict status, and resolveHunk reclassifies the hunk complex (confidence and explanation from the complex pattern, the resolver's reason added to the trace) instead of running the textual engine.

Dockerfile: stages paired by image, or by a random key

getStageKey was alias ?? image ?? random. So:

• FROM node:20-alpine vs FROM node:22-alpine (no alias) did not pair → both stages kept → two FROM lines.
• A hunk with no FROM (e.g. ENV PORT=3000 vs ENV PORT=4000) got a random key on each side → nothing paired → both ENV PORT lines kept. This is the most common shape and was not in the original report.

Fix: stages are paired by alias when they have one, otherwise by position among unaliased stages. If the two sides do not have the same number of unaliased stages (stage added on one side, alias added on one side only), the resolver declines and the textual engine takes over.

Tests

• 6 Dockerfile regression tests (FROM-only hunk, FROM + instructions, two unaliased stages, hunk with no FROM, alias on one side only, different stage counts).
• 5 imports regression tests (both directions, classified complex, reason, a non-import block still falls through).
• Core suite: 78 files, 1305 tests passing (golden funnel unchanged).

Follow-up

The blog article website/blog/trivial-conflicts-taxonomy.md describes the import case as a known gap "on the list to fix". Update it when this ships.

Review fixes

A review found hunks that main auto-resolved correctly but this PR turned complex or merged badly. Fixed in this PR, with regression tests:

• Imports: conflict: true now needs a shared local name ({ useAuth } vs useAuth, { x as useAuth } vs useAuth) or a require (binding not parsed). import React + import { useState } from the same module are both kept again. A one-sided form change ({ x } → x, other side kept the base import) is not a conflict. When both sides modify the same base import, the flag is dropped: the textual engine cannot build a union there, and the token-level proposal is offered again.
• Dockerfile: mergeStage now uses the matching base stage, so an instruction changed on one side only keeps that change. Before, it was replaced by the other side's base value, which position pairing made common. The resolver now declines when ours or theirs repeats an instruction key (several RUN, COPY to the same destination, ENV PATH): the textual engine handles those. It used to lose or duplicate one. It also declines on lines that are not instructions (heredoc bodies, \\ continuations started before the hunk). MAINTAINER is a known instruction, and \\ followed by spaces or \\r continues the line.

Core suite: 1322 tests passing.

Known gaps, unchanged from main, follow-up: one-sided deletions inside a Dockerfile stage come back; COMMENT lines share one key. In imports, oursBySource keeps only the last import per module, so { a, X } + type { T } vs import X still keeps both.