## Context

退款和代理充值已经接入企微审批，但部分历史记录在审批流程上线前创建，列表中的 `approval_status` 为空。这些记录需要由运营人员手动触发一次审批补发，才能进入企微审批链路。

## Goals / Non-Goals

- Goals: 提供代理充值和退款的历史审批补发入口。
- Goals: 通过路径参数指定目标记录，并复用后端返回的完整记录与审批状态。
- Goals: 由明确的状态规则控制入口展示，后端做最终资格校验。
- Non-Goals: 不在前端实现审批提交、审批回调或审批引擎。
- Non-Goals: 不修改历史记录的业务字段、金额或支付/退款结果。
- Non-Goals: 不提供批量自动补发。

## Decisions

- Decision: 两个模块分别新增 `triggerApproval(id)` 服务方法，返回完整业务记录并保留审批字段。
- Rationale: 两个接口契约一致，成功后页面需要立即展示最新审批状态，完整记录可直接用于刷新。

- Decision: 代理充值仅在 `approval_status` 为空且 `status` 不属于已完成、已驳回、已关闭时显示补发入口；退款仅在 `status=待审批` 且 `approval_status` 为空时显示补发入口。
- Rationale: 与业务规则一致，避免对已进入审批或已终结的记录重复补发；后端仍做最终资格校验。

- Decision: 引入独立按钮权限 `agent_recharge:trigger_approval` 和 `refund:trigger_approval`。
- Rationale: 补发审批是财务相关敏感操作，需与现有确认支付、拒绝、重新申请权限区分。

- Decision: 补发审批与现有“确认支付/拒绝”和“重新申请”操作共存。
- Rationale: 它们承担不同职责；补发审批只是把历史记录推进企微审批，不改变后续人工确认或重新申请的流程。

## Risks / Trade-offs

- Risk: 代理充值中 `status=已支付`、`已退款` 等非终态记录是否允许补发，需要后端最终确认。
- Mitigation: 前端按约定的审批状态与状态排除规则展示入口，后端对不允许的记录返回错误并稳定展示。

- Risk: 接口可能对部分状态返回拒绝。
- Mitigation: 前端处理后端错误信息，不将失败记录标记为已补发。

- Risk: 重复点击可能触发多次审批提交。
- Mitigation: 提交期间锁定按钮并禁用重复触发；后端应保证幂等或返回明确的已存在审批提示。

## Migration Plan

1. 确认两个 `trigger-approval` 接口的响应字段与现有 `AgentRecharge`、`Refund` 类型一致。
2. 新增服务方法和按钮权限。
3. 在列表接入补发审批入口及资格判断。
4. 联调补发成功、接口拒绝、权限缺失、审批状态为空与状态不符合条件等场景。
5. 验证与现有确认支付、拒绝、重新申请操作不冲突。

## Open Questions

- 后端对可补发记录的最终状态校验以及幂等性需确认。
- 两个接口是否都需要独立权限码，还是复用现有审批/财务权限，需与后端权限配置对齐。