git:20260808.8b7af2a to git:20260822.a6dcd1e

- description: Execute a sealed-receipt-linked refund through a configured adapter with bounded authority, approval, idempotency, and provider readback.

- Execute one refund against a real, sealed provider charge without losing the

- lineage that makes a reversal auditable. A refund is not a negative spend and it

- is not justified by an order id alone: the plan must link the original money

- movement, provider proof, prior refunds, selected rail, payer, amount, and

- single-use refund authority.

-

- The default builds the verified plan for a real `mpp` or `stripe` family,

- performs one approved provider reversal, and requires stable readback before a

- receipt can say the refund settled. The named family runners remain explicit

- plan surfaces; `mock` is never selected by default.

-

- ## When to use it

-

- Use `refund` after a charge or payment receipt has sealed provider evidence and

- the caller has a bounded refund `AuthorityTerm`. Use `dispute-respond` for a

- provider dispute packet and `spend` for a new outbound payment. Do not use a

- refund to compensate for missing original settlement proof.

-

- ## How it works

-

- 1. Resolve the opaque original receipt reference through Runx's configured,

- proof-verifying receipt store.

- 2. Verify the original amount, currency, payer, rail, provider proof refs, and

- money-movement status.

- 3. Discover and verify every receipt linked to that charge, then account for

- prior refunds so the request cannot exceed the remaining refundable ceiling.

- 4. Validate a complete typed, single-use refund authority for the same payer,

- currency, rail, realm, and operation.

- 5. Produce the exact adapter handoff and idempotency binding for the selected

- `mock`, `mpp`, or `stripe` path.

-

- References and redacted evidence are deliberately separate: the reference

- finds the receipt, while the verified receipt content proves what may be

- reversed. Caller-authored booleans such as `verified: true` have no authority.

-

- ## Inputs and result

-

- The caller supplies only the opaque original receipt ref, requested amount and

- reason, selected rail, requested counterparty, and full parent refund

- authority. Runx resolves the original receipt and refund history itself and

- derives idempotency from those verified receipts plus the exact authority and

- request. Caller-supplied receipt bodies, refunded totals, sealing flags, and

- idempotency seeds are not accepted.

-

- The result is a provider-refund plan and exact adapter handoff with original

- receipt binding, remaining ceiling, authority validation, redactions, and

- `provider_status: not_called`. It is not a settled-refund receipt.

-

- ## Stop conditions

- - Refuse an unsealed, reference-only, proofless, wrong-payer, wrong-rail, or

- wrong-currency original charge.

- - Refuse a refund above the original amount or remaining amount after prior

- reversals.

- - Refuse incomplete, expired, wildcard, reference-only, or reusable authority.

- - Stop on amount, payer, counterparty, rail, operation, or idempotency drift.

- - Do not expose raw provider credentials or claim money moved without provider

- execution and readback.

- ## Example

- A sealed Stripe charge proves `5000 AUD` moved and prior refund evidence shows

- `1000 AUD` already reversed. A bounded authority permits one additional refund

- to the original payer. The skill may prepare a `2000 AUD` Stripe handoff; it

- must block `4500 AUD`, a different payer, or a receipt with no settlement proof.

- The successful plan still says no money moved until the Stripe adapter proves

- the reversal.