## Scope

- 迭代编号：`AUG26-006`。

## Why

现有退款以本地审批状态处理，不能按来源实际支付事实决定退款方式、冻结实收金额，或在企业微信通过后用原实际收款商户可靠执行原路退款；退款单也无法按「每次提交持有独立审批实例」重提，且系统没有任何渠道原路退款调用。

## What Changes

- 退款申请冻结来源订单、权威实收金额、唯一套餐使用情况、退款金额/原因、方式和当次审批材料；实收金额由系统从原成功支付记录或订单实际收款派生，提交人不可填写或修改。
- 建立线上支付、资产钱包、代理主钱包和后台线下订单的退款方式矩阵，并在创建、提交和执行前重复校验。
- 企业微信是唯一审批终审；每次提交或重提新增一条不可变审批尝试记录与一个新的企业微信审批实例，历史材料不被覆盖；本地人工终审只保留既有存量终结路径，不新增任何运行时开关。
- 企业微信通过即写可靠失效事实，使关联套餐失效、接续下一套餐并评估停机，由既有可靠机制最终一致执行；客户收款信息退款与退回原钱包在企微通过时完成，原路退款须待渠道明确成功才完成，且仅此时置订单已退款。
- 按官方契约新增微信直连、富友和支付宝的原路退款适配，固定使用原支付单实际商户与其当前凭证；渠道能力只由服务商类型与退款必需凭证完整性决定，不提供人工开关；超时/未知/失败保留可恢复状态，不重复退款。
- 一笔订单最多一张最终成功退款、同时至多一张活动退款申请，由活动退款唯一约束与条件状态更新共同保证。

## Capabilities

### New Capabilities

- 无。

### Modified Capabilities

- `order-refund-exchange`: 退款申请、状态机、方式矩阵、原路渠道退款执行与套餐联动。

## Impact

影响退款模型/接口、企业微信审批、支付商户与渠道退款（微信直连、富友、支付宝）、资产/代理钱包、员工账单和佣金回溯；需新增成对迁移。

渠道适配按官方 SDK/接口契约实现，本 Change 不调用任何真实支付渠道验证：本地验证使用受控适配器桩，「未做外部渠道实测」只作记录，不作为阻塞、未完成任务或上线前置，真实渠道可退款性由维护者后续手工验证。