Reasoning about an RPC mutation whose first attempt may commit durably even though the caller observes a timeout. The candidate design uses a client-generated operation key, a durable uniqueness constraint, atomic coupling between the business effect and a stored outcome, and deterministic replay. Important edge cases are concurrent duplicate requests, key reuse with different payloads, crashes before and after commit, and effects that leave the local transaction boundary. No implementation or tests are being run.

A safe mixed-schema rollout treats compatibility as a directional proof, not as acceptance when any available digest matches. The receipt version owns comparison. A retry is parsed under its declared client schema and must pass a total, lossless adapter into the recorded semantic form; encountering a newly meaningful field, changed default, precision difference, or value the recorded form cannot express makes key reuse a conflict. If a legacy caller wins the unique-key race, an upgraded contender waits and then proves its downgrade is lossless. If an upgraded caller wins, a legacy contender is promoted using explicit historical defaults and conflicts whenever the recorded intent contains a value the legacy request could not express. A server unable to evaluate the stored version returns a retryable failure without performing the mutation. Replay uses the immutable stored outcome, optionally rendered into a negotiated response shape. For bounded operational signaling, allow at most one warning card per task and denial reason in a fifteen-minute window, folding repeats into a counter. If the sharing worker crashes or reaches its deadline after the primary transaction settles, leave sharing denied, perform no in-request sharing retry, and allow the primary task response to complete; a later bounded recovery may reconsider sharing without changing the mutation result. This is reasoning only. No implementation, files, or tests were inspected or executed.