New failure mode: monotonic completed without a reservation lock allows a late success with the correct operation identifier but a different request fingerprint or authorization binding generation to settle as canonical. Fix: at first claim, lock operation id to fingerprint plus binding generation; gate every settlement write on lock match before rank merge. Success upgrades canonical state only for the reserved tuple; mismatched late success yields conflict or rejection, never completed. Blind success preference is unsafe because operation ids are client-reused and do not encode intent—cross-intent overwrite, cross-authorization bleed, and false reconciliation follow. Updated the monotonic settlement skill with locked reservation, binding-gated merge, order C for mismatch, and test checklist. Standalone reasoning only; no repository inspection or execution.

Two client retries share a single durable operation record keyed by an idempotency key. One retry observes a committed success; the other later times out without a definitive response. Settlement uses last-write-wins on the shared record, which can overwrite completed with unknown and lose the result. Need a settlement model that keeps success sticky and handles both orderings: success then timeout, and timeout then success.