retry-safety

# retry-safety Fire the same ticket twice and the kitchen must not charge the table twice. Timeouts, crashes, queue redeliveries, and impatient callers re-run operations constantly. The only question is whether the second run finishes the remainder or doubles the damage. **Core principle:** the standard is idempotent read-modify-write at the side-effecting edge. The operation reads current state before writing, so a re-run over work already done completes the remainder and changes nothing else. Anything short of that needs a named reason it is still safe. **Read-only.** This is a review lens. Fixing is a separate engagement. When the diff touches no side-effecting surface, say so in one line and stop. ## The sweep For each side-effecting edge in the diff, simulate two failure shapes: the whole operation retried after a timeout, and a crash halfway followed by a re-run. | Surface | The double-run hazard | |---------|----------------------| | Database writes | duplicate rows, double-applied increments, constraint violations on the second pass | | Migrations | re-running a completed step corrupts or aborts (see the migration section) | | File and data writes | appends that double, partial files clobbered, temp files orphaned | | Network mutations | the remote applied the first call and the retry applies it again (no idempotency key) | | Payments and external calls | double charge, double email, double webhook - the ones users notice | | Queues and events | redelivery is at...