Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Design and implement conflict handling for [record type] edited offline on two devices. Describe the record identity, base version, changed fields, deletion representation, and accepted authority. Use two fictional fixtures that begin with the same record, make conflicting edits, and reconnect in a specified order.
Choose [reject and ask, field-level merge, or another justified policy] based on the product rules. Keep a recoverable copy of information that is not accepted. Distinguish a local pending write, a synchronized write, and a conflict that still needs a decision. State how repeated delivery and delete-versus-edit cases behave.
Verify concurrent edits, a nonconflicting edit, delayed delivery, repetition, and interruption during resolution. Check accepted stored data as well as the visible status. Report the version assumptions and any server contract that must change; do not use timestamp ordering as an unexplained substitute for policy.Make this prompt yours
Use a controlled local or test environment first. Add actual backend guarantees only after inspecting that backend’s contract.
You might also hear
- offline conflict
- sync merge
- two devices
- delete versus edit
- pending write
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Supported: Original conflict-resolution exercise. Offline synchronization can require versioning and an explicit resolution policy. The fixtures, merge choice, and retained data are instructional requirements, not backend guarantees.