Keep the intended operation separate from its attempts
Record the staff-facing outcome first: for example, one approved request, message, or update. Give it one stable operation identity in the approved procedure, then link attempts and observed outcomes to that identity. Do not call two messages identical merely because they look similar.
IETF RFC 9110 section 9.2.2 defines idempotent HTTP methods. That protocol rule does not establish that a business action, endpoint, queue, or staff handoff is safe to repeat.
Run a bounded handoff receipt
Use a safely simulated or approved non-production fixture and run:
node --test sites/howtox.com/evidence/P156/retry-handoff-receipt.test.mjs
The local validator requires a request source, first-attempt record, explicit retry condition, declared duplicate outcome, reconciliation owner, and escalation route. It also checks that the retry carries the same named operation identity as the first attempt. It does not decide whether to replay anything. It does not send an API call, keep a key, create a record, or prove a provider integration.
Pause when the first result is unknown
Do not ask staff to repeat a consequential action if nobody can show the intended operation, what the first attempt observed, and who reconciles the target record. A manual review path is the smallest credible improvement while those boundaries are unknown.
For another intake boundary, see Test a CSV Import Before Coworkers Rely on It. For cross-system agreement, see Test Booking-to-Calendar Synchronization Before Staff Rely on It. For a later request after acceptance, see Test a Reopened Work Request Before Staff Rely on It.
Does this receipt prove a retry cannot create duplicate work?
No. It proves only that the local fixture contains the named records and owners. A system-specific exercise must inspect its identity, concurrency, external effects, and reconciliation behavior.