Standalone reasoning only; no repository, personal, or machine configuration inspected, and no tests executed.

New failure: a late success carries the correct operation identifier but a different request fingerprint or binding generation. Blind success preference would promote completed even though the evidence belongs to superseded or foreign intent.

Strengthened locked settlement: terminal promotion requires full reservation tuple match (operation id, request fingerprint, authorization binding, generation). Operation id alone is never sufficient. Foreign terminals are quarantined, not merged and not demoted.

Why blind success preference is unsafe: stale generation replay after edit or re-auth freezes wrong result; cross-binding bleed after scope revocation marks completed under revoked authority; foreign sibling confusion when identifiers are reused or pooled; intent drift when fingerprint differs means different business effect; false completion hides that current intent never committed.

Settlement order within one atomic compare-and-set: reservation gate first (full tuple or quarantine), then rank gate (monotonic only among matching-tuple evidence), then promotion or sameness-to-conflict for same-rank payload divergence. Generation bump must atomically reset terminal fields so stale in-flight success cannot leave completed for superseded intent.

Standalone reasoning only; no repository, personal, or machine configuration inspected, and no tests executed.

Root cause: wall-clock last-write-wins treats a later observer timeout as authority over an earlier committed success, so unknown can replace completed on the shared durable record.

Settlement rule: merge with a monotonic status lattice, never blind overwrite by write time. Rank observer-local unknown or timeout below in-progress, and rank reservation-matching terminal completed or failed above both. A timeout may write only unknown and must not outrank a matching committed terminal.

Both completion orders under that merge:

1. Success then timeout: store completed; late unknown is a no-op; record stays completed.
2. Timeout then success: store unknown; later matching completed upgrades; record ends completed.

Evidence on each write: outcome class (committed success, committed failure, or observer-local timeout); for terminals, exact reservation match on operation id, request fingerprint, and binding generation; authoritative result payload only on matching committed paths. Compare reservation first; only then apply the status lattice. Mismatched completed must be rejected or quarantined, not preferred as success.

Limits: unknown means local indeterminate, not server rollback; status merge does not atomically couple side effects; completed versus failed under one reservation needs an explicit join or conflict terminal.

Two client retries share one durable operation record for the same logical work. One retry observes a committed success result; the other later times out and writes an unknown settlement. Naive last-write-wins on the shared record can overwrite completed with unknown, losing the proof of success. The question is how to design settlement so success is preserved regardless of which retry finishes first, and how both completion orders should behave.