[ctfbruce]

Behaviour

Tests only: internal/dispatcher/payments/rehearsal_test.go rehearses the composed chain settlement path (settlement ledger, receipts, transfers, adapter, payout and refund lifecycle) on real SQLite through the real PaymentHandler in enabled mode, with the scripted chain the transfer tests already use. No production code changes; no wallet, network, chain endpoint or enablement.

Proof

Eight drills, each asserting the final rows of transactions, debuglet_order, order_settlements, earnings, chain_transfers and payment_receipts and the backend call counts:

1. A USDC intent paid by its receipt, admitted, finished with exit 0, credited once, paid out (reserved, sent, confirmed); a second receipt for the nonce is duplicate, a differing one mismatch; earnings arriving during the payout survive.
2. A lost response leaves the payout unknown; a verified lookup confirms it without a second broadcast; an unverified success stays unknown.
3. Stopped after the reservation and before the submission: after a restart the stale reservation is resubmitted once from the stored bytes with the same digest, then confirmed.
4. Stopped after the submission and before the outcome write: resolved by lookup after a restart; one transfer in total.
5. A failed refund (not broadcast) keeps the order Refunded and the settlement row and is never sent again; a refund owed but never attempted is sent exactly once by the settlement pass, from its reserved row.
6. The inline credit refused by a trigger is delivered once by the settlement pass; duplicate terminal reports change nothing.
7. Every drill again with the database closed and reopened after each step: every state is read back identically (7 to 13 reopenings per drill).
8. Disabled mode: every chain action refuses with payments_disabled, no receipt or transfer row is written, leftover chain orders stay as they are, TEST flows are unchanged.

Deliberate faults in a throwaway copy (an unverified lookup recorded confirmed; a lost response recorded failed; resubmission only from sent) each fail the drills that guard them. The payments, Sui, HTTP API and dispatcher packages pass under -race with the drills.

Upgrade

None. Stacked on #381, whose commits show in the diff against main until it merges.

Limits

The drills run against the scripted chain and local fixtures only; no live-network test has been run, and enabling chain payments remains the operator's explicit step described in docs/operations/payments.md. The drills established three product limits, recorded on #381: a transfer whose stored bytes the chain no longer knows is resubmitted on every reconciliation pass without a bound; an invalid refund address is detected at the refund, not at intent creation; a failed refund has no re-attempt path.

GitHub issue #87.

Candidate CI

The branch then took the corrected payout branch by merge (ed84410) and asserts the refund outcome it now reports (f558a5a); Run 37310404192 on f558a5a: 16 of 16 lanes and required succeeded. Run 37294915212 on c649c42: 16 of 16 lanes and required succeeded.