Extension resolved: monotonic completed is sticky only when success evidence matches the live reservation triple of operation id, request fingerprint, and binding generation. Correct operation id with wrong fingerprint or generation is staleorforeign_success, quarantined without status or result promotion.

Blind success preference equates coordination handle with semantic and authorization identity, letting zombie workers publish wrong outcomes, hiding active conflicts under one key, and opening sharing before the live reservation has an authoritative terminal.

Concrete rule named Stale-Binding Warning Cap: at most one auditable warning per operation id and mismatch class per rolling hour; further drops increment a silent counter only.

Operational walkthrough: primary reserves generation 4 fingerprint v2, dispatches worker, deadline revokes generation 4 and continues locally under generation 5 fingerprint v3 while primary task completes. Crashed worker later reports success for generation 4. Settlement quarantines it, emits one capped warning, sharing stays denied until generation 5 reaches matching terminal. Primary delivery unaffected.

Published skill Monotonic settlement for optional publication retries at revision 2 already encodes reservation match, bounded warnings, and primary isolation; no further skill change needed from this turn.

Resolution: naive last-write-wins by wall clock or write timestamp treats all settlements as equally authoritative, so a later observer-local timeout can regress a committed success to unknown. Fix by merging on evidence strength via a monotonic status lattice, not arrival order.

Evidence classes: (1) observer-local timeout means the client lost the response channel, not that execution failed; (2) committed terminal means durable proof the effect happened for this operation identity and request fingerprint.

Lattice low to high: unknown or pending, in_progress, reservation-matching terminal (completed or failed). Rule: matching terminal always outranks unknown. Unknown may never downgrade a matching terminal.

Order success then timeout: completed with result is written first; late unknown merge is rejected; record stays completed; timed-out retry re-reads and replays stored result.

Order timeout then success: unknown may land first as provisional; later matching completed upgrades and freezes; unknown writers become no-ops once terminal is set.

Required record fields: operation id, request fingerprint, binding generation or lease epoch, status, result payload on terminal success, settledat or monotonic version. Conditional writes: allow unknown only if current rank is below terminal; allow completed only with reservation match and rank upgrade from unknown or inprogress.

Client after timeout must poll or re-fetch durable record before re-executing side effects. Server should single-flight execution per operation key so parallel retries do not duplicate work.

Existing skill Monotonic settlement for concurrent durable-op retries already documents this pattern; no new skill warranted.

Two concurrent retries share one durable operation record keyed by idempotency token. Retry A commits success and writes status completed with result payload. Retry B times out on the client but the server may still be running or may later write a settlement of unknown or failed due to ambiguous outcome. If settlement uses naive last-write-wins by wall clock or write time, B's later unknown write can overwrite A's completed state, causing duplicate work, lost results, or incorrect client behavior on replay.

Known: shared durable record is the coordination surface; one path observed committed success; another path ends in timeout and may emit weaker terminal state; LWW without guards causes regression from terminal success to unknown.

Unknowns: whether reads are linearizable, whether server-side execution is single-flight or parallel, whether unknown is client-only vs persisted, and what replay semantics the API guarantees.

Goal: design record fields, write rules, and read/reconcile behavior so success is preserved regardless of whether success settles before or after the timeout path.