Store intent rather than a blind final snapshot
HTTP does not make every POST safe to repeat. A local offline queue needs the target’s documented idempotency and concurrency rules. The sample stores command, record, base revision and proposed change; it never silently merges a conflicting edit.
| Command | Base | Change | Reconnect result |
|---|---|---|---|
| OFF-1 / contact C-7 | Revision 4 | Change phone | Revision still 4: eligible to apply |
| OFF-2 / contact C-8 | Revision 6 | Change address | Target now 7: conflict review |
| Retry OFF-1 | Same command | Same payload | Reconcile prior result; do not duplicate |
Resolve in the user’s current context
Recheck current permission after reconnecting. Offline approval or an old login is not authority to write after access is removed. Present the original and current values for a deliberate correction, keeping the failed command for traceability.
Should a client replace a conflicting command’s base revision with the newest revision automatically?
Show the worked answer
No. That bypasses the protection and can overwrite another person’s work. Resolve the change, then create an authorised replacement intent against the reviewed current state.