# 2026-08-11 M09-C 统计与结算收口

## 工程结果

- 工程提交：`1f10715`，已推送并验证远端 `main` 与本地 HEAD 一致。
- 统一保洁任务、负责人、协作者、免清洁、驳回、完成、待结算、结算中和已结算口径；生成草稿或确认单后金额仍计入未付款口径，只有 `PAID` 才计入已结算。
- 协作任务以“任务 × 收款成员份额”为结算原子：同一份额最多存在一条有效结算明细，并发生成只有一个赢家；不同收款人分别形成付款单，任务仅在所有有效奖励份额均付款后进入 `SETTLED`。
- 活动结算明细存在期间冻结成员新增、移除和奖励调整，避免旧快照与任务奖励错配；跨门店且无租户级权限的生成请求必须明确门店。
- 取消草稿或已确认结算单时保留原单和明细，创建不可变负向冲正记录、标记原明细已冲正并释放成员份额；冲正后可重新生成新有效结算。
- 新增结算状态事件，区分 `USER` / `SYSTEM` 操作人；详情页和 CSV 可追溯确认、出款、失败、冲正、付款及 traceId。
- 微信转账在外部请求前先以数据库 CAS 进入 `PROCESSING` 并固化 `CLP{settlementId}` 请求号；网络不确定结果保持处理中，只有供应商明确失败后才允许冲正，成功回调可幂等重放。
- 微信回调按已验签商户号和收款账户定位结算，避免跨租户裸查流水；人工已付只允许未发起或明确失败的已确认结算，并要求可对账流水号。
- 页面和服务端 CSV 导出复用结算列表同一查询方法、同一已提交筛选和同一排序；保洁任务、统计、运营队列与结算 CSV 的金额统一输出整数分。

## 验证证据

- Windows `scripts/dev/windows/test-all.ps1`：105.5 秒，退出码 0；仓库完整性、敏感信息、状态文档、后端全测、迁移计划、管理端构建/测试、懒加载体积和 M09-C 静态门禁全部通过。
- 管理端生产构建最大 JS 分块 `218,014 B`，低于 `500 KiB`；仅保留第三方 `@vueuse/core` PURE 注释位置警告。
- WSL 原生临时副本 + MySQL 8.4.10 完成 `up → verify → down → up → verify`：160 条 up、132 条 verify、154 条 down，临时数据库与账号均已清理。
- MySQL 业务用例实测协作份额并发生成单赢家、活动明细唯一、成员冻结、冲正释放与重生成、处理中禁止取消、明确失败后取消、全部成员付款后任务最终结算，以及列表/导出同筛选同顺序。
- 历史 `CANCELLED` 结算迁移会生成基线冲正并释放成员；带“历史已冲正 + 当前有效”和“多条历史冲正”数据的 down/up 往返通过。

## 阶段结论

`M09-C=DONE`。唯一执行游标进入 `M09-D1`；真实微信商户转账仍为 `BLOCKED_EXTERNAL`，但内部结算、对账、失败重试、冲正和人工付款链路已经闭环。