Extension: monotonic success is unsafe without reservation tuple equality. A late response can carry the correct operation identifier yet belong to a superseded payload or authorization generation. Locked settlement must extract the tuple from verified server commitment evidence and require exact match with the stored reservation before any terminal merge. Mismatch quarantines the observation; it is not a downgrade of authoritative state and must not block a later exact match.

Blind success preference attaches wrong results, replays stale authority, and makes the client believe the current intent succeeded when an abandoned attempt did.

Operational example added: cap tuplemismatchquarantined diagnostics at one per distinct observed fingerprint per record and eight total per rolling day; worker crash after effect but before settlement plus late stale success with old fingerprint is quarantined; primary continues via lease expiry and retry under current binding while share publication gate requires matching binding generation so sharing stays denied until exact-match completion.

Resolution: replace wall-clock last-write-wins with monotonic lattice settlement on a single authoritative operation record. Separate per-attempt timeout observations from authoritative state. Gate every write with reservation tuple match (operation id, request fingerprint, binding generation). Merge rule: matching completed dominates unknown regardless of arrival order; timeout then success upgrades; success then timeout stays completed; tuple mismatch is no-op on authoritative state.

Both orders: Order A (success first): retry A commits completed with result; retry B timeout writes only to attempt record or is rejected by merge gate; record stays completed. Order B (timeout first): retry B records unknown on attempt or leaves operation in_progress; retry A later commits completed; merge upgrades to completed.

Client on timeout must re-read authoritative record before retrying effect; never treat local timeout as terminal for the shared operation.

Existing skill Binding-matched monotonic operation settlement already captures this design; no new skill needed.

Two client retries share one durable operation record keyed by idempotency token. Retry A receives and commits a successful result. Retry B times out on the wire but the server-side work may have finished. A last-write-wins settlement path later writes unknown over completed, erasing the committed success.

Known: both retries target the same record; completion and timeout settlements are independent writers; naive LWW by timestamp or attempt id loses terminal success.

Unknown: whether per-attempt sub-records exist, whether the store supports conditional writes or CRDT-style merges, and what downstream consumers require (strict vs eventual visibility).