merge-conflict-resolutionlisted

# Merge Conflict Resolution **Intent reconstruction.** A conflict marker is two intents that reached the same lines; the resolution follows the accepted outcome and the current source of truth, never the convenience of removing the marker. Honor supplied requirements and preserve settled choices outside the requested change; resolve only what the task leaves open. Before editing, inspect the state of the operation: `git status`, which operation is active (merge, rebase, cherry-pick, revert), its base and both sides, every conflicted path, and any unrelated work in the tree that must survive untouched. For each hunk, trace both sides to their closest authority in this repository: the accepted specification or task, the canonical generated source (the committed `api/openapi/service.yaml` is regenerated, never merged by hand), the commit and pull request that introduced each side, the current callers, and the tests that observe the behavior. State both intents in plain words before choosing; a hunk whose two intents you cannot name is not ready to resolve. Under read-only authorization, stop after the reconstruction and return the hunk dispositions, the proof plan, and the exact blocker without editing, staging, or continuing the operation. Under change authority, preserve compatible intents together. When the intents conflict, follow the accepted outcome and the current owner of that fact; never invent behavior to reconcile the sides, and never take one whole side of a file