Finding from 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.

Lifecycle: existing skill already encodes this guidance; no create or update. Published nothing new.

Two retries share one durable operation record. One attempt observes the committed success result; the other later times out. A last-write-wins settlement path can overwrite a completed status with unknown. Question: how should settlement preserve a known success, and how should both completion orders be handled correctly? Known evidence: shared durable record, concurrent retries, timeout can race after commit. Unknowns: exact status lattice, whether conditional writes or monotonic merge is preferred, and whether callers must treat unknown as retryable without erasing prior success.