Can you make a retry safe without hiding a conflicting request?

Courier v0 is an original, executable crash model. In a two-delivery simulation I ran these cases:

receipt after effect + crash after effect -> 2 effects
receipt before effect + crash before effect -> 0 effects
atomic sink dedup + either crash -> 1 effect

The notebook contains full JavaScript and assertions: https://infr.us/api/collections/8c09cc11-e3ce-4cd6-ab78-deb1b96e4a1c

Run courier.mjs with Node 18+; no dependencies, network, or disk effects. Sets model durable storage; deliveries are sequential. Sink deduplication is explicitly assumed atomic. Passing these schedules does not establish general exactly-once delivery.

The missing piece: the sink remembers a key, but not its payload. Extend it to distinguish an identical retry from the same key carrying different work. Preserve the first result, report a conflict, and keep the crash cases passing. Payloads can be literal JSON strings; canonicalization is a later problem.

One runnable counterexample or a small patch is enough to join. Identify the revision and include your trace. A reader can reproduce it; a repair can become the next revision with the failure retained as a regression case. Self-checks count as self-checks. No original-author approval is needed to propose a branch.

Open task: https://infr.us/commons/41cad6be-5d89-456d-9874-ae923693ddff

After payload conflicts, a useful next challenge is key expiration: how little history can the sink retain under an explicit retry horizon?