frontend-patterns/research/candidates/ConflictCopy.md

title	status	maturity	families	scales	admission	reviewed
Conflict Copy	draft	hypothesis	synchronization	L2 L6	research-candidate-only	2026-09-25

Conflict Copy

A research candidate, not a canonical pattern or a completed PatternSchema record. No FEP identity or admitted graph edges. Editorial synthesis by codex; live artifacts remain unchanged. Merges Joplin joplin-conflicts-01/P01 and Obsidian obsidian-conflicts-01/P01 (Conflict File Preservation).

Context and problem

A system detects divergent edits to one document. It can select a working version, but cannot infer which combination expresses the user's intended result. How can it retain the alternate edits for a later decision without treating selection of the working version as semantic resolution?

Competing forces

• recoverability favors retaining divergence; cognitive-load and storage costs favor avoiding an expanding collection of unresolved copies.
• freshness favors applying received changes; reconciliation-complexity favors postponing a merge whose meaning is uncertain.
• discoverability and accessibility require a perceivable conflict state; silent duplication can preserve bytes while still failing the user.

Proposed solution and dynamics

On a detected conflict, preserve the alternate content under a distinct identity and associate it with the working item. Select a working version according to an explicit policy. Keep resolution pending until a person or separately justified merge mechanism decides what to retain. In the two documented uses, the preserved copy is local content and the working item holds remote content; that selection is not a general claim of server authority.

Durably preserving before destructive replacement, labeling provenance, notifying the user accessibly, and making resolution restartable are proposed design requirements. They are not verified implementation guarantees from these sources.

Resulting context and consequences

The working item is usable, but divergent intent remains unresolved. A copy may support recovery and comparison; it does not prove convergence, preserve every historic edit, or protect against failure of the device holding both versions. Manual reconciliation creates effort, clutter and opportunities for mistakes.

Located uses and limits

Evidence review:

• SRC-0005 / E07: Joplin's documented detected-note-conflict handling.
• SRC-0006 / E08: Obsidian Sync's optional conflict-file mode, not its default mode.

These are two named documented uses from separate application publishers, not two fault-tested deployments. Recurrence has limited documentary support; retain hypothesis maturity. The applications' shared code lineage was not investigated. Obsidian's alternative merge mode and creation-time exception (E09/E10) prevent an unconditional claim that this mechanism is always used or never loses data.

Failure cases and alternatives

• A crash during preservation/replacement needs an atomicity or recovery argument.
• Missed conflict detection bypasses this mechanism entirely.
• An unnoticed copy can leave the user believing work disappeared.
• Concurrent resolution on two devices can itself conflict.
• Replicated deletion or local corruption can affect both versions; use separate recovery protection (E11), not a claim that synchronization is a backup.
• Alternatives: halt for immediate review; domain-aware automatic merge; explicit rejection of stale writes. Compare semantic correctness and user effort.

Relations to investigate

Potentially complements Local Authority and may create context for Explicit Reconciliation. These names refer to research candidates, not admitted endpoints. Conflict detection is a contextual prerequisite, not a fabricated pattern edge. The mechanism may preserve rejected edits in VC-01 but cannot validate a reservation, approval or other globally constrained transaction.

Next test

For VC-02, edit one note on two disconnected devices, persist both, restart, then reconnect. Trace local-save acknowledgement, working-version selection, conflict notification, resolution and separate backup recovery. Compare with a plain architecture narrative and with immediate manual merge. A first synthetic walkthrough now traces this sequence. No runtime execution or proven generativity benefit is claimed.