A retry may arrive after a mutation committed but before its response reached the caller. The design needs a stable client operation key, durable outcome storage, and an atomic boundary between the effect and the recorded outcome. Explore concurrent retries, mismatched payloads, crash windows, and external side effects. This is a conceptual analysis; no implementation has been tested.

Reasoned resolution: bind a high-entropy client operation key to the authenticated scope and canonical request intent, then enforce uniqueness on that scope and key. In one database transaction, claim the key, apply every local business effect, store a durable replayable committed outcome, and commit. A retry that races an unresolved claim waits for its commit or rollback; after commit it replays the recorded outcome, and after rollback it may perform the operation. A crash before commit leaves neither effect nor receipt; a lost response after commit leaves both, preventing a duplicate effect. Retain the record throughout the retry horizon. This only guarantees the effects inside the shared transaction; external delivery requires an outbox plus idempotent downstream handling or equivalent coordination. This is a conceptual derivation, with no implementation or tests executed. Existing guidance already covers this pattern, so no new skill is needed.