Conflict resolution

Problem Context

• A conflict state already exists because two or more valid edits overlap in the same field, paragraph, row, file, branch hunk, draft, or synchronized object.
• More than one conflict may need to be resolved before the user can submit, publish, sync, import, save, or merge.
• The product must preserve local, remote, collaborator, source-branch, target-branch, existing-row, or incoming-row values until a decision is committed.
• Some conflicts are simple choose-one-side decisions, while others require manual merge, save-copy, skip, owner assistance, or a different tool.

Selection Rules

• Choose conflict resolution when users need a workflow for deciding, merging, skipping, or committing one or more conflicts after they have been detected.
• Use conflict state for the persistent status surface that says a conflict exists; conflict resolution is the active review and decision workflow that follows.
• Use autosave recovery when the main issue is preserving local work after failed or uncertain saving and no explicit side-by-side decision has started.
• Use draft state when the main task is managing unpublished work, not deciding between overlapping valid versions.
• Use review-before-submit when users are checking their own captured answers before final submission; use conflict resolution when another source, version, branch, or system has a competing value.
• Resolve at the smallest unit the user can judge: field, row, line, paragraph, file, branch hunk, setting, or record.
• Offer only decisions that are true for the data type: keep local, keep server, accept incoming, keep existing, merge both, save copy, skip, discard, or open manual tool.
• Block final commit when required conflicts remain unresolved, when a resolved preview is invalid, or when unsupported files require a manual route.
• Show a final review summary before destructive commit, including counts resolved, skipped, copied, discarded, and sent to manual resolution.
• After commit, update the source object, clear the conflict badge, and leave a retrievable history or export of decisions where the domain requires it.

Required States

• Conflict list state with unresolved count and current conflict position.
• Side-by-side or inline comparison state for the current conflict.
• Choose local, choose remote, choose existing, or choose incoming state.
• Manual merge edit state with unresolved markers.
• Save copy or keep both state for preserving a rejected version.
• Skip or defer state for conflicts that cannot be decided now.
• Unsupported or manual-tool-required state.
• Resolved preview state showing the value that will be committed.
• Review all decisions state with kept, discarded, copied, skipped, and unresolved counts.
• Committed state with audit trail, version history, or exported resolution report.

Interaction Contract

• The resolver opens from a known conflict and keeps users oriented to the affected object, conflict number, and total unresolved count.
• Each decision records which source value survives, which value is copied or discarded, and whether the resolved value is complete.
• Next and Previous conflict controls move through unresolved items without losing decisions already made.
• Manual merge preserves both source values until the merged value passes validation or the user explicitly cancels.
• Save copy or keep both creates a findable artifact and does not claim the conflict is solved unless the primary object has a committed value.
• Final commit is disabled or intercepted while required conflicts remain unresolved, while previews are invalid, or while manual-tool items are open.
• The committed result clears conflict indicators only after the server, repository, import job, or document accepts the resolved version.
• The workflow exposes undo, history, or exported decisions when data loss, collaboration, compliance, publication, or code review risk is high.

Implementation Checklist

• Model conflicts as a list of units with base value, local or incoming value, remote or existing value, owner, timestamp, field or file path, decision, preview, validation, and commit state.
• Keep conflict-state detection separate from the resolver route so users can reopen unfinished decisions.
• Persist in-progress decisions through reload, route changes, reauthentication, and reconnect when policy permits.
• Implement choose-one-side, merge, save-copy, skip, cancel, next, previous, review, and commit controls with explicit labels.
• Validate merged values before commit and keep unresolved markers visible until every required choice is made.
• Handle bulk conflict sets with filters, progress, keyboard navigation, and item-level review rather than only a global accept action.
• Record resolution metadata for collaborative documents, regulated records, imports, source control, and published content.
• Test multi-conflict navigation, partial decisions, reload recovery, unsupported file types, permission changes, validation failure after merge, skipped items, final commit failure, keyboard access, and screen reader status updates.

Common Generated-UI Mistakes

• Marking conflicts resolved before the user reviews the surviving value.
• Using a single Accept all button without showing affected fields or discarded values.
• Letting users commit with required conflicts still unresolved.
• Using ambiguous Ours and Theirs labels without branch, owner, device, or timestamp context.
• Hiding skipped or save-copy artifacts after commit.
• Treating conflict resolution as retry, reload, or last-write-wins.
• Clearing the conflict badge before the resolved version is accepted by the server, repository, or document.

Critique Questions

• How many conflicts remain, and where is the user in the resolution sequence?
• What exact value will be committed if the user chooses each action?
• Which rejected values are copied, exported, discarded, or still recoverable?
• Can users resolve some conflicts and safely defer or export the rest?
• What prevents commit while conflicts remain unresolved or previews are invalid?
• What history, audit trail, or undo path remains after the resolved version is accepted?