docs(accounting): record split fixed fee evidence

1. AGENTS.md 更新
   - water-docs: 新增 specs/ 与 docs/design/ 生命周期规则章节
   - water-backend: 更新协作引用（建设期/建成后、evidence 模块化）

2. specs/ 重复合并
   - 006-reminder-event-design 合并入 003-rev006-reminder-event-design
   - 001-rev004-accounting 删除冗余 data-model.md + contracts/
   - 002-rev005-invoice-flow 删除冗余 data-model.md + contracts/

3. evidence 按模块归档
   - 35 个 REV-004 文件归入 evidence/rev004-accounting/
   - 7 个通用 bugfix 文件归入 evidence/bugfix/ 和 bugfix/frontend/
   - 新建 rev005-invoice/、rev006-reminder/、rev007-statistics/ 目录

4. guides/ 清理
   - 14 个 REV004_*.md 移入 evidence/rev004-accounting/

5. 遗留文件处理
   - docs/research/ 归档到 Archive/06_Migration_Plans/
   - backend-check detached worktrees 清理

6. 交叉引用修复
   - 006-reminder-event-design → 003-rev006-reminder-event-design
   - docs/guides/REV004_ → docs/evidence/rev004-accounting/REV004_

7. DB 设计文档修正（01_Database_Design.md）
   - biz_invoice 明确为开票配置表，非发票记录表
   - 新增 biz_invoice_record 为发票申请/结果主表
   - 新增 biz_charge_invoice_rel 账单-发票关联说明
   - REV-005 承接口径表名全部修正

8. 发票审计证据
   - 新增 evidence/rev005-invoice/2026-06-16-invoice-document-audit.md

AGENTS.md

@@ -36,6 +36,55 @@
 - frontend lane 只改 `water-frontend`
 - verify lane 负责样本、日志、验收结论和基线固定
 
+## specs/ 与 docs/design/ 生命周期
+
+本仓库维护两套文档体系，有明确的「一次性 ↔ 持续维护」分工。
+
+### specs/ — 过程工件（建设期蓝图，建成后封存）
+
+`specs/<编号>-<feature>/` 是 feature 建设阶段的工作台，每个目录包含：
+
+- `spec.md`：功能规格（一次性，建成后不维护）
+- `plan.md`：实施计划（一次性）
+- `tasks.md`：任务拆分（一次性）
+- `research.md`：调研记录（一次性）
+- `verification.md`：验收记录（建成后封存）
+- `data-model.md`：建设期数据模型草稿。建成后正式维护口已移交 `docs/design/03_Technical_Design/01_Database_Design.md`
+- `contracts/`：建设期接口契约草稿。建成后正式维护口已移交 `docs/design/03_Technical_Design/03_Interface_Design.md`
+
+**规则**：
+- `spec.md` / `plan.md` / `tasks.md` / `research.md` / `verification.md` 在 feature 建设期间活跃编辑，建成后封存不再修改。
+- `data-model.md` 和 `contracts/` 是临时草稿，feature 建成后数据模型和接口的唯一真源是 `docs/design/` 下的主文档。
+- 禁止在两个体系里并行维护同一份数据模型或接口定义。
+- 禁止创建同一个 feature 的多个 spec 目录（如 `003` 和 `006` 都是 REV-006），发现重复必须合并。
+
+### docs/design/ — 正式交付文档（唯一真源，持续维护）
+
+`docs/design/` 是正式交付的「建成物」描述，所有模块的最终定义收敛在此：
+
+- `02_Detailed_Design/12_REV_Detailed.md`：REV 模块的功能描述唯一真源
+- `03_Technical_Design/01_Database_Design.md`：表结构的唯一真源
+- `03_Technical_Design/03_Interface_Design.md`：接口定义的唯一真源
+
+**规则**：feature 建成后，所有后续维护、修订、查阅原则上以 `docs/design/` 为准，`specs/` 只作为历史追溯参考。
+
+### docs/evidence/ — 验证证据（按模块组织）
+
+证据文件按模块分子目录存放：
+
+- `docs/evidence/rev004-accounting/`
+- `docs/evidence/rev005-invoice/`
+- `docs/evidence/rev006-reminder/`
+- `docs/evidence/rev007-statistics/`
+
+禁止在 `docs/evidence/` 根目录平铺散文件。新证据必须归入对应模块子目录。
+
+### docs/guides/ — 系统级指南
+
+`docs/guides/` 只保留系统级指南（如 Speckit 工作流、系统能力地图、后端现状等）。模块专项操作指南归入 `docs/evidence/<模块>/`。
+
+---
+
 本文件用于指导通用代码代理（包括 Codex 类代理）在本仓库中的工作方式。
 
 ## 项目定位
@@ -55,18 +104,19 @@
 
 ```text
 /
-├── docs/design/00_Management/          # 项目管理、进度跟踪、交付规范、编写指南
-├── docs/design/01_Overview/          # 总体设计：系统概述、系统架构、概要设计、系统图谱
-├── docs/design/02_Detailed_Design/            # 详细设计：主详设、模块设计、CA 安装设计
-├── docs/design/03_Technical_Design/           # 技术专项：数据库、表结构、接口、安全、部署、加密
-├── docs/design/04_Appendix/            # 附录与归档资料
-├── .claude/                # Claude Code 相关配置
-├── .omc/                   # 项目记忆与代理状态
-├── .zed/                   # Zed 项目配置
-├── assets/                 # 图片、模板等静态资源
-├── docs/                   # 研究资料、映射文档、使用指南
-├── scripts/                # 文档处理与导出脚本
-└── infra/                  # 辅助基础设施
+├── specs/                             # 过程工件：feature 建设期蓝图，建成后封存
+├── docs/design/00_Management/         # 项目管理、进度跟踪、交付规范、编写指南
+├── docs/design/01_Overview/           # 总体设计：系统概述、系统架构、概要设计、系统图谱
+├── docs/design/02_Detailed_Design/    # 详细设计：主详设、模块设计（功能描述唯一真源）
+├── docs/design/03_Technical_Design/   # 技术专项：数据库、接口、安全、部署（表结构/接口定义唯一真源）
+├── docs/design/04_Appendix/           # 附录与归档资料
+├── docs/evidence/                     # 验证证据（按模块分子目录）
+├── docs/guides/                       # 系统级指南
+├── .claude/                           # Claude Code 相关配置
+├── .codex/                            # Codex 相关配置
+├── assets/                            # 图片、模板等静态资源
+├── scripts/                           # 文档处理与导出脚本
+└── infra/                             # 辅助基础设施
 ```
 
 ## 当前文档组织原则
@@ -82,7 +132,7 @@
 - `docs/design/03_Technical_Design/04_Security_Design.md`：安全设计主文档
 - `docs/design/03_Technical_Design/05_Deployment_Design.md`：部署设计主文档
 
-如果已有主文档可以承载内容，**优先编辑现有文件，而不是新增“新-xxx”“最终版”“修订版”之类文件**。
+如果已有主文档可以承载内容，**优先编辑现有文件，而不是新增"新-xxx""最终版""修订版"之类文件**。
 
 ### Archive 仅作归档
 
@@ -124,7 +174,7 @@
 - 风格要求专业、克制、可交付，避免口语化和宣传化表述
 - 不写与当前项目无关的泛化模板内容
 
-### 以“对齐现状”为第一原则
+### 以"对齐现状"为第一原则
 
 所有修改必须优先对齐以下事实来源：
 
@@ -146,7 +196,7 @@
 ### 不要过度发挥
 
 - 不要凭空补充不存在的子系统、模块、接口、表
-- 不要为了“显得完整”加入大量无依据的实现细节
+- 不要为了"显得完整"加入大量无依据的实现细节
 - 不要默认加入大段代码示例、部署脚本、DDL、伪代码，除非用户明确要求
 - 不要创建多余术语体系；优先沿用仓库现有命名
 
@@ -168,7 +218,7 @@
 
 **福建水务营收系统**
 
-除引用原始资料外，不要混用“营业收费系统”“数智营收管理系统”“客户服务平台”等作为正式系统名称。
+除引用原始资料外，不要混用"营业收费系统""数智营收管理系统""客户服务平台"等作为正式系统名称。
 
 ### 数据库口径
 
@@ -186,7 +236,7 @@
 ### 图表规范
 
 - 所有正式图表优先使用 Mermaid
-- 图表必须与正文一致，不能“图一套、文一套”
+- 图表必须与正文一致，不能"图一套、文一套"
 - Mermaid 节点命名尽量避免容易导致解析异常的写法
 - 调整图表时，同时检查导出可用性和可读性
 
@@ -302,7 +352,7 @@ npm run marksman:server
 
 - 擅自扩展需求的产品经理
 - 无依据发明实现细节的方案生成器
-- 动辄新建文件的“版本制造机”
+- 动辄新建文件的"版本制造机"
 
 ## 最终目标
 

docs/design/00_Management/01_Project_Progress.md

@@ -118,15 +118,15 @@
 
 | 2026-03-26 | 方案二整体部署方案独立成文 | 1）新增 `docs/design/03_Technical_Design/08_Integrated_Deployment_Design_PlanB.md`，将已采纳 PostgreSQL 16 方案二后的整体部署方案独立成文；2）结合当前前后端分层部署形态，补齐应用、数据库、中间件、静态存储的一体化部署结构；3）新增软件拓扑图、网络拓扑图、主机角色划分、资源配置建议、网络需求和端口访问建议；4）在 `07_PostgreSQL16_DR_Resource_Application.md` 增加独立文档引用说明，在技术专项目录增加入口。 | 用户明确要求不要仅在 `07` 文档内保留方案二内容，而是需要形成独立文件，并作为已采纳数据库方案后的整体部署方案提交评审。 | 正面影响，数据库资源申请专题与整体部署方案实现职责分离；后续甲方可分别评审“数据库容灾资源申请”和“系统整体部署方案”，减少口径混杂并提升部署审批的可读性。 |
 | 2026-04-02 | 方案二整体部署文档按网络图口径对齐 | 1）将 `docs/design/03_Technical_Design/08_Integrated_Deployment_Design_PlanB.md` 的网络分区口径统一为“办公区 / 公网区域 / 互联网区DMZ / 内网区”；2）将 `Nginx` 入口、业务应用节点、`SFTP/FTP` 文件交换服务器的部署区域说明统一调整为与评审图一致；3）同步修正网络拓扑图、访问链路、带宽/端口、资源角色及结论段落中的命名与边界表述。 | 用户提供最新部署图，要求正式文档向图片口径靠拢，消除 `内网 Nginx`、应用区/DMZ、办公区等描述不一致问题。 | 正面影响，整体部署方案的图文一致性显著提升，便于甲方按统一网络边界和主机分区口径开展安全评审与资源审批。 |
-| 2026-04-03 | REV-004 全量账务领域设计骨架落地 | 1）新增 `docs/guides/REV004_FULL_ACCOUNTING_DOMAIN_DESIGN.md`，将“完整承载旧系统账务业务”的目标建模路线落为单一设计底稿；2）统一旧系统账务对象、目标分层、正式业务实体、关系图、目标表设计骨架、迁移与兼容策略、逐步细化计划；3）明确该文档作为后续正式主文档回写前的统一骨架，不与现有 `REV-004` 一期 spec 冲突。 | 用户提出当前目标不是“一期最小闭环”，而是“新系统完整承载旧系统账务业务”，需要先搭建设计骨架再逐步细化并统一口径。 | 正面影响，后续关于账务实体、台账迁移、查询兼容、审批流和数据库设计的讨论有了统一底稿，可显著降低“继续沿用一期口径”和“直接机械平移旧表”之间的反复摇摆。 |
+| 2026-04-03 | REV-004 全量账务领域设计骨架落地 | 1）新增 `docs/evidence/rev004-accounting/REV004_FULL_ACCOUNTING_DOMAIN_DESIGN.md`，将“完整承载旧系统账务业务”的目标建模路线落为单一设计底稿；2）统一旧系统账务对象、目标分层、正式业务实体、关系图、目标表设计骨架、迁移与兼容策略、逐步细化计划；3）明确该文档作为后续正式主文档回写前的统一骨架，不与现有 `REV-004` 一期 spec 冲突。 | 用户提出当前目标不是“一期最小闭环”，而是“新系统完整承载旧系统账务业务”，需要先搭建设计骨架再逐步细化并统一口径。 | 正面影响，后续关于账务实体、台账迁移、查询兼容、审批流和数据库设计的讨论有了统一底稿，可显著降低“继续沿用一期口径”和“直接机械平移旧表”之间的反复摇摆。 |
 | 2026-04-03 | REV-004 详设正式回写首批收口（RWB-01） | 1）按 `RWB-01` 规则生成正式详设快照 `docs/design/04_Appendix/Archive/08_Formal_Doc_Snapshots/RWB-01/2026-04-03-RWB-01-12_REV_Detailed.md`，基线对应 docs 仓 commit `9d2ecf1`；2）重写 `docs/design/02_Detailed_Design/12_REV_Detailed.md` 的 `REV-004 账务处理` 章节，改为“当前正式边界 + 全量目标边界”双层写法，并纳入全量账务对象、审批分层、迁移承接和现状/目标边界；3）保持 `IF-REV-007` 当前统一入口事实，不将目标态误写为已全部落地实现。 | 用户同意从回写准备进入 `RWB-01`，要求先把 `12_REV_Detailed.md` 中 `REV-004` 正式详设改写为可承接全量账务领域的正式入口。 | 正面影响，`REV-004` 正式详设已从“一期五类场景”提升为“可承接全量账务对象的正式入口”，为后续数据库设计、接口设计与迁移专题回写建立了稳定锚点，同时保留了现状/目标分层表达，降低将目标态误判为当前实现的风险。 |
 | 2026-04-03 | REV-004 数据库专项正式回写首批收口（RWB-02） | 1）按 `RWB-02` 规则生成数据库专项快照 `docs/design/04_Appendix/Archive/08_Formal_Doc_Snapshots/RWB-02/2026-04-03-RWB-02-01_Database_Design.md`，基线对应 docs 仓 commit `9d2ecf1`；2）更新 `docs/design/03_Technical_Design/01_Database_Design.md` 中 `SYS-002 开账、收费与票据表`、`biz_operat_log*`、历史台账迁移口径、索引关注点与归档补充，将 `REV-004` 从“一期不新增细表”扩展为“统一骨架 + 目标对象 + 查询投影 / 历史映射”的数据库专项口径；3）正式命名 `AccountingWorkflowRef` 与 `AccountingLegacyMapping` 为目标数据库承接对象，但仍保持“待补字段关注点”写法，不误写成已落地真实表。 | 用户同意进入 `RWB-02` 正式回写，要求先把数据库专项调整为能够承接全量账务领域的正式数据库设计入口。 | 正面影响，数据库专项已从“只描述现有骨架表”提升为“同时约束统一骨架、目标对象、历史映射和查询投影”的正式口径，为后续接口设计回写和实现落表讨论建立了稳定边界，同时避免把目标对象误判为已全部物理落地。 |
 | 2026-04-03 | REV-004 接口专项正式回写首批收口（RWB-03） | 1）按 `RWB-03` 规则生成接口专项快照 `docs/design/04_Appendix/Archive/08_Formal_Doc_Snapshots/RWB-03/2026-04-03-RWB-03-03_Interface_Design.md`，基线对应 docs 仓 commit `9d2ecf1`；2）更新 `docs/design/03_Technical_Design/03_Interface_Design.md` 中 `IF-REV-007`、其请求/响应参数、数据对象与表口径、历史查询与迁移校验接口口径、实现状态说明，将 `REV-004` 从“一期五类场景统一入口”扩展为“当前统一入口 + 全量账务对象承接边界 + 历史查询分层”的正式接口口径；3）保持专属接口仍为后续方向，不误写成当前 backend 已完整落地能力。 | 用户同意进入 `RWB-03` 正式回写，要求先把接口专项调整为能够承接全量账务领域的正式接口设计入口。 | 正面影响，接口专项已从“一期统一处理接口说明”提升为“统一入口、对象承接边界、历史查询出口、实现状态分层”并存的正式口径，为后续总体设计回写和实现拆接口讨论建立了稳定约束，同时避免把目标专属接口误判为当前既成事实。 |
 | 2026-04-03 | REV-004 总体摘要正式回写收口（RWB-04） | 1）按 `RWB-04` 规则生成总体摘要快照 `docs/design/04_Appendix/Archive/08_Formal_Doc_Snapshots/RWB-04/2026-04-03-RWB-04-03_Summary_Design.md`，基线对应 docs 仓 commit `9d2ecf1`；2）更新 `docs/design/01_Overview/03_Summary_Design.md` 中总体接口定义、营收业务系统外部接口、营收核心模块群概述、模块列表与 `REV-004` 模块摘要，使 REV-004 从“一期五类处理摘要”收敛为“当前统一入口 + 全量账务对象目标边界”的概要口径；3）继续保留当前已落地事实与目标设计边界分层表达，不将专属接口或独立对象实现写成已全部落地。 | 用户同意进入 `RWB-04`，要求完成 REV-004 全量账务领域在总体摘要层的正式收口。 | 正面影响，概要、详设、数据库、接口四层文档现已围绕 REV-004 形成一致口径；后续再讨论实现拆分、迁移验收与对象落表时，可直接基于统一的正式文档体系推进，显著降低跨层级表述不一致风险。 |
-| 2026-04-03 | REV-004 实现分发清单与 Agent 交接模板落地 | 1）新增 `docs/guides/REV004_IMPLEMENTATION_HANDOFF.md`，将 REV-004 全量账务领域的后端、前端、联调任务拆分为可直接分发的实现清单；2）同步整理对象范围、统一入口约束、历史只读/映射层边界、建议任务包与给其他 Agent 的提示模板；3）保持该文档定位为实现交接指南，不替代正式设计真源。 | 用户需要一份可直接分发给前后端实现 Agent 的功能清单和对应需求，用于后续协作执行。 | 正面影响，后续多 Agent 协作不再需要重复从正式文档中人工提炼任务；实现范围、分工边界与交接提示可直接复用，降低理解偏差和重复沟通成本。 |
-| 2026-04-07 | REV-004 前端实现正式 handoff 落地 | 1）新增 `docs/guides/REV004_FRONTEND_IMPLEMENTATION_HANDOFF.md`，将已批准的 REV-004 前端实现方案转为正式交接文档；2）明确本轮仅覆盖管理后台，不纳入微网厅/客户端实现；3）补齐四张正式执行表：页面清单、路由清单、通用组件清单、lane ownership 清单，并固化 `../water-frontend` 目录下的 `omx team` 执行边界。 | 用户要求把已达成共识的 REV-004 前端实现计划转为正式 handoff Markdown，并细化为可直接执行的正式表格。 | 正面影响，前端实现协作从“计划草案”升级为“执行交接文档”；后续在 `water-frontend` 中可直接按页面清单、路由清单、组件清单和 lane ownership 推进，降低前端实现阶段的范围漂移和分工冲突。 |
-| 2026-04-07 | REV-004 前端 team prompts 落地 | 1）新增 `docs/guides/REV004_FRONTEND_OMX_TEAM_PROMPTS.md`，将 leader 启动提示与 Lane A~F 执行 prompt 固化为可直接用于 `../water-frontend` 的 `omx team` 文本；2）保持本轮范围仅覆盖管理后台，不纳入微网厅/客户端实现；3）同步固化启动顺序、lane 职责边界与最终统一输出要求。 | 用户要求直接生成可在前端目录执行的 `omx team` prompts，用于下一步正式启动多 lane 实现。 | 正面影响，前端执行已从“交接文档阶段”进入“可直接开干的 prompt 阶段”；leader 与各 lane 不再需要临时编写任务说明，可直接按固定文本启动团队执行，降低启动成本与分工歧义。 |
-| 2026-04-07 | REV-004 前端 team prompts 落地 | 1）新增 `docs/guides/REV004_FRONTEND_TEAM_PROMPTS.md`，将 leader 启动提示与 Lane A~F 执行 prompt 固化为可直接用于 `../water-frontend` 的 `omx team` 文本；2）保持本轮范围仅覆盖管理后台，不纳入微网厅/客户端实现；3）同步固化启动顺序、lane 职责边界与最终统一输出要求。 | 用户要求直接生成可在前端目录执行的 `omx team` prompts，用于下一步正式启动多 lane 实现。 | 正面影响，前端执行已从“交接文档阶段”进入“可直接开干的 prompt 阶段”；leader 与各 lane 不再需要临时编写任务说明，可直接按固定文本启动团队执行，降低启动成本与分工歧义。 |
+| 2026-04-03 | REV-004 实现分发清单与 Agent 交接模板落地 | 1）新增 `docs/evidence/rev004-accounting/REV004_IMPLEMENTATION_HANDOFF.md`，将 REV-004 全量账务领域的后端、前端、联调任务拆分为可直接分发的实现清单；2）同步整理对象范围、统一入口约束、历史只读/映射层边界、建议任务包与给其他 Agent 的提示模板；3）保持该文档定位为实现交接指南，不替代正式设计真源。 | 用户需要一份可直接分发给前后端实现 Agent 的功能清单和对应需求，用于后续协作执行。 | 正面影响，后续多 Agent 协作不再需要重复从正式文档中人工提炼任务；实现范围、分工边界与交接提示可直接复用，降低理解偏差和重复沟通成本。 |
+| 2026-04-07 | REV-004 前端实现正式 handoff 落地 | 1）新增 `docs/evidence/rev004-accounting/REV004_FRONTEND_IMPLEMENTATION_HANDOFF.md`，将已批准的 REV-004 前端实现方案转为正式交接文档；2）明确本轮仅覆盖管理后台，不纳入微网厅/客户端实现；3）补齐四张正式执行表：页面清单、路由清单、通用组件清单、lane ownership 清单，并固化 `../water-frontend` 目录下的 `omx team` 执行边界。 | 用户要求把已达成共识的 REV-004 前端实现计划转为正式 handoff Markdown，并细化为可直接执行的正式表格。 | 正面影响，前端实现协作从“计划草案”升级为“执行交接文档”；后续在 `water-frontend` 中可直接按页面清单、路由清单、组件清单和 lane ownership 推进，降低前端实现阶段的范围漂移和分工冲突。 |
+| 2026-04-07 | REV-004 前端 team prompts 落地 | 1）新增 `docs/evidence/rev004-accounting/REV004_FRONTEND_OMX_TEAM_PROMPTS.md`，将 leader 启动提示与 Lane A~F 执行 prompt 固化为可直接用于 `../water-frontend` 的 `omx team` 文本；2）保持本轮范围仅覆盖管理后台，不纳入微网厅/客户端实现；3）同步固化启动顺序、lane 职责边界与最终统一输出要求。 | 用户要求直接生成可在前端目录执行的 `omx team` prompts，用于下一步正式启动多 lane 实现。 | 正面影响，前端执行已从“交接文档阶段”进入“可直接开干的 prompt 阶段”；leader 与各 lane 不再需要临时编写任务说明，可直接按固定文本启动团队执行，降低启动成本与分工歧义。 |
+| 2026-04-07 | REV-004 前端 team prompts 落地 | 1）新增 `docs/evidence/rev004-accounting/REV004_FRONTEND_TEAM_PROMPTS.md`，将 leader 启动提示与 Lane A~F 执行 prompt 固化为可直接用于 `../water-frontend` 的 `omx team` 文本；2）保持本轮范围仅覆盖管理后台，不纳入微网厅/客户端实现；3）同步固化启动顺序、lane 职责边界与最终统一输出要求。 | 用户要求直接生成可在前端目录执行的 `omx team` prompts，用于下一步正式启动多 lane 实现。 | 正面影响，前端执行已从“交接文档阶段”进入“可直接开干的 prompt 阶段”；leader 与各 lane 不再需要临时编写任务说明，可直接按固定文本启动团队执行，降低启动成本与分工歧义。 |
 
 | 2026-03-18 | REV-005 统计模板补齐 | 1）在 `specs/002-rev005-invoice-flow/verification.md` 为 `T055`、`T060`、`T061`、`T062`、`T063` 新增可直接填写的样本记录模板；2）将 SC-001 ~ SC-004 的建议统计口径细化为表格字段与待补说明，避免后续只剩抽象待办；3）保持“模板已补齐但实际统计结果仍待联调/测试环境补录”的真实状态，不虚构样本结果。 | 用户继续推进 REV-005，希望把剩余统计类待办进一步收敛成可执行模板，便于后续直接补录真实样本而不是重新设计统计格式。 | 正面影响，REV-005 当前已具备统一的统计与日志抽样记录模板；后续补 `T055`、`T060 ~ T063` 时可直接按模板填充真实环境数据，减少再次整理验证文档结构的成本。 |
 | 2026-03-18 | REV-005 verify 执行入口补齐 | 1）在 `specs/002-rev005-invoice-flow/verification.md` 补齐 `/business/invoice/apply`、`/query`、`/query/compensate`、`/write-back`、`/customer/query`、`/customer/download`、`/customer/push`、`/invalidate`、`/red-ink` 的最小请求模板；2）继续补齐 `T055`、`T060 ~ T063` 的执行命令草稿与样本采集顺序，明确仅作为测试/联调环境占位模板，真实地址、鉴权信息、业务主键与统计结果均待后续替换和回填；3）同步 `03_Task_Checklist.md`，将 verify 阶段推进到“替换真实环境参数即可执行”的状态。 | 用户继续推进 REV-005，希望不要停留在抽象验证建议，而是把剩余 verify 工作推进到可直接执行、可直接补样本的程度。 | 正面影响，REV-005 当前已具备统一的验证入口、请求模板、命令草稿与采样顺序；后续在测试或联调环境中可直接替换参数发起请求并回填 `T055`、`T060 ~ T063` 的真实结果，减少重复梳理接口和命令的成本。 |
@@ -146,8 +146,8 @@
 | 2026-03-16 | REV-005 后台发票申请与校验闭环（US1） | 1）在 `backend/sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/controller/admin/invoice/InvoiceController.java` 增加后台发票申请入口；2）在 `service/invoice/InvoiceServiceImpl.java` 实现客户、客户开票信息、账单与税率校验，确保仅已收费未开票账单允许申请；3）补齐 `applicationNo` 或 `custId + chargeIds` 幂等控制、申请单号生成与申请记录落库；4）执行 `mvn -f backend/sw-business/pom.xml -pl sw-business-server -am -DskipTests compile` 最小编译验证并通过。 | 用户要求继续推进 REV-005 implement，优先完成后台发票申请、开票校验与 US1 收尾，不中断当前实现链路。 | 正面影响，REV-005 已形成“后台申请入口 + 关键校验 + 幂等受理 + 最小编译验证”闭环，后续可在此基础上继续推进 SYS-008 调用、开票结果回写、账单状态联动与电子发票推送下载能力。 |
 | 2026-03-12 | OMX 任务路由样例落地 | 1）新增 `docs/design/00_Management/17_OMX_Task_Routing_Examples.md`，给出 `REV-004`、`REV-003` 与正式文档修订三类任务的 leader / explorer / executor / verifier 分工模板；2）补充各 lane 的提示词模板、推荐执行顺序与不建议的并行方式；3）更新 `00_Management/README.md` 收录该文档入口。 | 用户希望在治理层之外，再拿到针对当前项目可以直接复用的多 Agent 分工模板，而不是只看抽象原则。 | 正面影响，OMX 从“有规则”变成“可直接照着分工执行”；后续在 `REV-004`、`REV-003` 等闭环中可直接套用 lane 拆分，减少 leader 临时编排成本。 |
 | 2026-03-12 | OMX 多 Agent 治理层落地 | 1）在根 `AGENTS.md` 中新增 OMX 多 Agent 协作补充，明确分层 AGENTS、任务路由矩阵、写冲突规则、范围控制基线与 worktree/tmux 约定；2）新增 `backend/AGENTS.md`，固化 backend 开发边界、最小实现策略与 BPM 接入规则；3）新增 `docs/design/04_Appendix/Archive/AGENTS.md`，明确 Archive 默认只读与来源回写规则；4）新增 `docs/design/00_Management/16_OMX_Multi_Agent_Guide.md`，统一 leader / writer / executor / verifier 分工与协作拓扑；5）更新 `00_Management/README.md` 收录新指南入口。 | 用户明确准备采用 `oh-my-codex` 进行多 Agent 开发，需要对现有 AGENTS 体系做分层化和路由化改造，避免现有规则在 Team Mode 下失效。 | 正面影响，当前项目从“单 agent 规则完备”提升为“多 agent 可控协作”；后续接入 OMX 时，目录级职责、写权限边界、范围基线与会话约定已经成型，可显著降低并发改稿和多 worker 写冲突风险。 |
-| 2026-03-12 | REV-004 一期执行手册与 worktree/tmux 启动脚本落地 | 1）新增 `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`，将 `REV-004` 一期的范围、现状差距、最小改动方案、任务拆解、Codex Prompt 与验收清单固化为可执行手册；2）新增 `scripts/start-backend-codex-session.sh`，支持在 `backend/` 上创建或复用 worktree，并拉起 `tmux + codex` 三窗口开发会话；3）更新 `scripts/README.md` 记录脚本用途。 | 用户要求不仅给建议，还要把“如何规划执行、如何进入 worktree、如何在 tmux 场景下协作”落成可直接使用的资产。 | 正面影响，开发启动动作从“口头建议”变为“可复制执行”；后续围绕 `REV-004/REV-003/REV-008` 的闭环开发可直接复用该脚本和手册，降低 worktree、tmux、Codex 协作的起步成本与操作偏差。 |
-| 2026-03-13 | REV-004 一期范围正式文档收敛（US1） | 1）更新 `docs/design/02_Detailed_Design/12_REV_Detailed.md`，将 REV-004 一期范围收敛为水量调整、金额调整、退款、冲正、坏账申请五类场景，并明确共性能力优先顺序、排除项与审批边界；2）重写 `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`，将其从 backend 执行导向收敛为正式文档修订执行手册；3）同步 `docs/design/01_Overview/03_Summary_Design.md` 与 `specs/001-rev004-accounting/contracts/rev004-traceability-matrix.md` 的范围摘要与追溯说明；4）执行目标文档 `make validate-file` 与 `make check-links` 校验并通过。 | 用户要求在 implement 阶段先完成 REV-004 一期正式文档范围收敛，不把 backend 代码实现写成本轮已完成内容。 | 正面影响，REV-004 一期边界、验收入口与追溯关系已在正式文档体系内闭环，后续 US2/US3 可直接在稳定范围上继续对齐接口、数据库与台账，不再受早期执行手册偏代码导向表述干扰。 |
+| 2026-03-12 | REV-004 一期执行手册与 worktree/tmux 启动脚本落地 | 1）新增 `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`，将 `REV-004` 一期的范围、现状差距、最小改动方案、任务拆解、Codex Prompt 与验收清单固化为可执行手册；2）新增 `scripts/start-backend-codex-session.sh`，支持在 `backend/` 上创建或复用 worktree，并拉起 `tmux + codex` 三窗口开发会话；3）更新 `scripts/README.md` 记录脚本用途。 | 用户要求不仅给建议，还要把“如何规划执行、如何进入 worktree、如何在 tmux 场景下协作”落成可直接使用的资产。 | 正面影响，开发启动动作从“口头建议”变为“可复制执行”；后续围绕 `REV-004/REV-003/REV-008` 的闭环开发可直接复用该脚本和手册，降低 worktree、tmux、Codex 协作的起步成本与操作偏差。 |
+| 2026-03-13 | REV-004 一期范围正式文档收敛（US1） | 1）更新 `docs/design/02_Detailed_Design/12_REV_Detailed.md`，将 REV-004 一期范围收敛为水量调整、金额调整、退款、冲正、坏账申请五类场景，并明确共性能力优先顺序、排除项与审批边界；2）重写 `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`，将其从 backend 执行导向收敛为正式文档修订执行手册；3）同步 `docs/design/01_Overview/03_Summary_Design.md` 与 `specs/001-rev004-accounting/contracts/rev004-traceability-matrix.md` 的范围摘要与追溯说明；4）执行目标文档 `make validate-file` 与 `make check-links` 校验并通过。 | 用户要求在 implement 阶段先完成 REV-004 一期正式文档范围收敛，不把 backend 代码实现写成本轮已完成内容。 | 正面影响，REV-004 一期边界、验收入口与追溯关系已在正式文档体系内闭环，后续 US2/US3 可直接在稳定范围上继续对齐接口、数据库与台账，不再受早期执行手册偏代码导向表述干扰。 |
 | 2026-03-18 | 完成全仓旧模块编号残留审计 | 1）新增 `docs/design/00_Management/18_Old_Module_Number_Audit.md`，对 `docs/design`、`docs/guides`、`specs` 中的 `METER-004`、`INST-004`、`INST-005` 及相关旧模块语义进行全仓审计；2）将命中项分为“必须修”“可保留历史描述”“Archive 原始资料”“合法保留的接口编号/子能力表达”四类；3）更新 `docs/design/00_Management/README.md` 收录审计清单入口。 | 用户要求执行全仓旧编号残留审计，明确哪些需要继续修、哪些应作为历史资料保留。 | 正面影响，后续旧编号治理从“按检索临时判断”转为“按清单分类处理”；正式文档、管理台账与 Archive 的处理边界更加清晰。 |
 | 2026-03-18 | 旧模块编号残留收口与追溯链接修正 | 1）更新 `docs/design/02_Detailed_Design/03_CA_Esignature_Supplement.md`，将文档定位从旧 `INST-004` 修正为 `INST-002 工程管理` 下的“合同签署与电子签章能力”专项补充；2）修正 `docs/design/02_Detailed_Design/02_Module_Traceability_Index.md` 中 `INST-002`、`INST-003` 的章节锚点，确保跳转与当前三段式模块结构一致；3）复核 `docs/design/01_Overview/03_Summary_Design.md` 的主口径章节，确认残留 `IF-METER-004`、`IF-INST-004/005` 均为接口编号而非旧模块编号。 | 用户要求继续收口“旧编号视为错误”的相关正式文档，并区分必须修项与可保留历史描述。 | 正面影响，正式文档层的模块编号、追溯入口与专项补充挂接关系进一步统一，评审和检索时不会再因旧 `INST-004/005` 模块语义误跳转。 |
 | 2026-03-18 | 基于整体架构图补齐模块清单并对齐详细设计承接关系 | 1）新增 `docs/design/01_Overview/05_Module_Inventory.md`，将整体架构图中的分层、子系统、模块与当前详设承接关系整理为统一清单；2）更新 `docs/design/01_Overview/README.md` 与 `docs/design/02_Detailed_Design/README.md`，明确该清单作为模块枚举与承接核对入口；3）更新 `docs/design/02_Detailed_Design/01_Detailed_Design.md` 与 `docs/design/02_Detailed_Design/02_Module_Traceability_Index.md`，补充架构图模块清单与当前详设之间的映射说明，明确 `WECHAT-*`、`MOBILE-*`、`WORK-*` 等模块当前按业务域正文或协同能力承接。 | 用户要求根据 `output/preview/福建水务营收系统整体架构图.html` 形成模块清单，并以此为基线对齐 `02_Detailed_Design` 目录。 | 正面影响，架构图中的模块枚举与详细设计现状之间建立了稳定映射，后续评审时可直接判断“哪些模块已有正文、哪些是协同承接、哪些仍停留在架构层列示”，减少按图追文时的歧义。 |
@@ -340,7 +340,7 @@
 
 ### 2026-03-18 更新
 
-- 完成 `REV-006` Speckit feature `006-reminder-event-design` 的 implement 阶段文档收口，统一 `12_REV_Detailed.md`、`03_Interface_Design.md` 与治理台账口径。
+- 完成 `REV-006` Speckit feature `003-rev006-reminder-event-design` 的 implement 阶段文档收口，统一 `12_REV_Detailed.md`、`03_Interface_Design.md` 与治理台账口径。
 - `REV-006` 正式业务接口编号确定为 `IF-REV-013`，不再复用 `IF-REV-009`；催缴结果状态统一为 `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED` 四态。
 - 明确旧“催缴记录 / 停水记录 / 预存短信记录”按历史只读口径承接，不新增同名在线主表；停复水在本轮仅保留联动边界、处置引用和追溯关系。
 - 启动并完成 `REV-007` Speckit feature `004-rev007-revenue-statistics-design` 的 `specify -> plan -> tasks` 工件链，形成统计主题、维度、指标、`IF-REV-010` 与数据库承接口径的正式设计基线。
@@ -353,7 +353,7 @@
 
 ### 2026-03-19 更新
 
-- 完成 `REV-006` 当前轮次治理文档二次对齐：在 `15_SYS002_Requirement_Breakdown.md` 明确 `SYS002-REQ-011` 继续维持“未见实现”判断，并补记 `specs/006-reminder-event-design/` 工件基线与后续研发切入建议。
+- 完成 `REV-006` 当前轮次治理文档二次对齐：在 `15_SYS002_Requirement_Breakdown.md` 明确 `SYS002-REQ-011` 继续维持“未见实现”判断，并补记 `specs/003-rev006-reminder-event-design/` 工件基线与后续研发切入建议。
 - 同步回写 `03_Task_Checklist.md` 与本进度文档，补充本轮 implement 阶段的治理动作、验证动作与台账一致性说明，避免将文档收口误写为 backend 已实现。
 
 ### 2026-03-24 更新

docs/design/00_Management/03_Task_Checklist.md

@@ -196,7 +196,7 @@
 ### 📋 REV-004 执行资产落地
 
 - [x] **完成 REV-004 一期执行手册与启动脚本落地** ✅ (2026-03-12)
-  - [x] 新增 `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`，固化范围、最小改动方案、任务拆解与验收清单 ✅
+  - [x] 新增 `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`，固化范围、最小改动方案、任务拆解与验收清单 ✅
   - [x] 新增 `scripts/start-backend-codex-session.sh`，支持 backend worktree + tmux + Codex 启动 ✅
   - [x] 在 `scripts/README.md` 登记启动脚本用途 ✅
   - [x] 在 `01_Project_Progress.md` 记录本次执行资产落地 ✅
@@ -571,7 +571,7 @@
   - [x] 更新 `docs/design/03_Technical_Design/01_Database_Design.md`，明确历史只读保留策略、最小查询字段与处置引用边界 ✅
   - [x] 更新 `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`、`01_Project_Progress.md` 与本任务清单，完成 implement 阶段治理回写 ✅
 - [x] **完成 REV-006 implement 阶段治理文档二次对齐** ✅ (2026-03-19)
-  - [x] 在 `15_SYS002_Requirement_Breakdown.md` 明确 `SYS002-REQ-011` 继续维持“未见实现”，并补记 `specs/006-reminder-event-design/` 工件基线 ✅
+  - [x] 在 `15_SYS002_Requirement_Breakdown.md` 明确 `SYS002-REQ-011` 继续维持“未见实现”，并补记 `specs/003-rev006-reminder-event-design/` 工件基线 ✅
   - [x] 在 `01_Project_Progress.md` 更正 REV-006 feature 编号与本轮治理回写记录，避免误导为 backend 已实现 ✅
   - [x] 在治理任务建议中补充 `make validate-file`、`make check-links`、`make validate-mermaid` 与台账同步动作 ✅
 

docs/design/00_Management/15_SYS002_Requirement_Breakdown.md

@@ -130,7 +130,7 @@
 | `REV-003` 营业收费 | 部分实现 | 建议围绕“柜台班结”“红冲历史查询”等缺口拆小 feature |
 | `REV-004` 账务处理 | 已实现 | 以规则收口、二期扩展或历史台账映射为主 |
 | `REV-005` 发票与税务处理 | 已实现 | 以验收归档和细粒度对象补证为主 |
-| `REV-006` 催缴与通知 | 未见实现 | 已完成 Speckit `specify -> plan -> tasks` 工件并形成 `specs/006-reminder-event-design/` 基线；当前进入 `implement` 阶段文档收口与台账同步，backend 仍未见明确催缴/通知业务实现骨架。 |
+| `REV-006` 催缴与通知 | 未见实现 | 已完成 Speckit `specify -> plan -> tasks` 工件并形成 `specs/003-rev006-reminder-event-design/` 基线；当前进入 `implement` 阶段文档收口与台账同步，backend 仍未见明确催缴/通知业务实现骨架。 |
 | `REV-007` 统计分析 | 未见实现 | 已完成 Speckit `specify -> plan -> tasks`，当前进入 `implement` 阶段的正式文档收口与治理同步。 |
 | `REV-008` 代收与银行业务 | 已实现 | 以跨系统口径收口和扩展台账补证为主 |
 | `REV-009` 业务参数配置 | 已实现 | 以参数边界收口和治理能力补充为主 |
@@ -152,7 +152,7 @@
 | `REV-003` | 是 | `rev003-redflush-history-query` | 中 | 聚焦红冲历史查询与台账承接 |
 | `REV-004` | 否 | `rev004-adjustment-followup` | 中 | 仅在补二期或精细对象时使用 |
 | `REV-005` | 否 | `rev005-detail-reconciliation` | 中 | 仅在补发票细表/批次缺口时使用 |
-| `REV-006` | 是 | `rev006-reminder-event-design` | 最高 | 已完成 `spec/plan/research/data-model/contracts/quickstart/tasks` 工件链，当前重点为按 `IF-REV-013` 四态口径推进正式文档 implement 收口并形成后续研发切入点。 |
+| `REV-006` | 是 | `rev003-rev006-reminder-event-design` | 最高 | 已完成 `spec/plan/research/data-model/contracts/quickstart/tasks` 工件链，当前重点为按 `IF-REV-013` 四态口径推进正式文档 implement 收口并形成后续研发切入点。 |
 | `REV-006` | 是 | `rev006-notice-result-writeback` | 高 | 可作为 `REV-006` 拆分子 feature |
 | `REV-007` | 是 | `rev007-revenue-statistics-design` | 高 | 已启动并完成第一轮设计工件，当前建议继续收口正式文档并形成后续研发切入点 |
 | `REV-007` | 是 | `rev007-channel-analysis-query` | 中 | 适合作为统计分析子 feature |
@@ -233,13 +233,13 @@
 
 - 标题：`SYS-002：补齐催缴事件与通知协同设计`
 - 对应需求：`SYS002-REQ-011`
-- feature：`rev006-reminder-event-design`（治理映射名：`sys002-reminder-event-design`）
+- feature：`rev003-rev006-reminder-event-design`（治理映射名：`sys002-reminder-event-design`）
 - 优先级：`高`
 - 当前实现状态：`未见实现`
 - Story 描述：
   - 目标：补齐欠费催缴对象生成、通知触发、通知结果回写与催缴追踪闭环。
   - 事实来源：`12_REV_Detailed.md` 中 REV-006、`03_Interface_Design.md` 中 `IF-EXT-008`。
-  - 当前判断：当前代码检索范围内未见明确的催缴、通知、消息协同控制器或服务骨架；但本轮已完成 `specs/006-reminder-event-design/` 工件链，并在正式文档中统一 `IF-REV-013`、四态状态集、历史只读查询口径和停复水联动边界。
+  - 当前判断：当前代码检索范围内未见明确的催缴、通知、消息协同控制器或服务骨架；但本轮已完成 `specs/003-rev006-reminder-event-design/` 工件链，并在正式文档中统一 `IF-REV-013`、四态状态集、历史只读查询口径和停复水联动边界。
   - 验收要点：明确催缴触发时机、催缴对象筛选条件、通知方式、回写字段、四态状态语义与失败重试机制。
 - 推荐 Task：
   - `T-011-01` 对齐催缴业务场景、触发条件与对象筛选规则

docs/design/03_Technical_Design/01_Database_Design.md

@@ -1144,17 +1144,18 @@ retrieval_priority: P0
 | `biz_collection` | `code`, `cust_id`, `charge_id`, `collection_status` | 托收主表 |
 | `biz_withholding` | `code`, `cust_id`, `charge_id`, `withholding_status` | 代扣主表 |
 
-### biz_invoice / biz_invoice_taxrate (发票主表与税率表)
+### biz_invoice / biz_invoice_record / biz_invoice_taxrate（开票配置表 / 发票记录表 / 税率表）
 | 表名 | 关键字段 | 说明 |
 | :--- | :--- | :--- |
-| `biz_invoice` | `code`, `cust_id`, `charge_id`, `invoice_status`, `invoice_amount` | 发票主表，统一承接申请单号、账单关联、受理号、开票结果与电子票地址等核心状态 |
+| `biz_invoice` | `supplier`, `limit`, `auto_invoice`, `invoice_type`, `status` | 开票配置表（供应商、限额、自动开票开关）|
+| `biz_invoice_record` | `application_no`, `cust_id`, `invoice_status`, `invoice_amount` | 发票申请/记录主表，统一承接申请单号、账单关联、受理号、开票结果与电子票地址等核心状态 |
 | `biz_invoice_taxrate` | `tax_code`, `tax_name`, `tax_rate`, `status` | 税率基础配置 |
 
 #### REV-005 发票承接口径
 
 | 对象 | 已有字段 | 待补字段 | 仅快照/历史只读字段 |
 | :--- | :--- | :--- | :--- |
-| `biz_invoice` 发票申请/结果主对象 | `code`、`cust_id`、`charge_id`、`invoice_status`、`invoice_amount` | `application_no`、`sys_request_no`、`invoice_type`、`invoice_title`、`tax_no`、`email`、`mobile`、`source_channel`、`fail_reason`、`invoice_code`、`invoice_number`、`file_url`、`last_try_time`、`next_try_time`、`try_count`、`push_status`、`charge_ids_snapshot`、`charge_bind_status`、作废原因/备注、红冲原因/备注、原票/红票关联标识、作废/红冲申请来源、补偿查询/结果回写上下文 | 旧开票批次号、旧配置版本号、旧平台扩展回执 |
+| `biz_invoice_record` 发票申请/结果主对象 | `code`、`cust_id`、`charge_id`、`invoice_status`、`invoice_amount` | `application_no`、`sys_request_no`、`invoice_type`、`invoice_title`、`tax_no`、`email`、`mobile`、`source_channel`、`fail_reason`、`invoice_code`、`invoice_number`、`file_url`、`last_try_time`、`next_try_time`、`try_count`、`push_status`、`charge_ids_snapshot`、`charge_bind_status`、作废原因/备注、红冲原因/备注、原票/红票关联标识、作废/红冲申请来源、补偿查询/结果回写上下文 | 旧开票批次号、旧配置版本号、旧平台扩展回执 |
 | `biz_cust_invoice` 客户开票信息 | `cust_id`、`invoice_title`、`tax_no`、`email`、`mobile` | 企业/个人抬头类型、默认推送方式等扩展属性按后续实现补齐 | 旧抬头版本、历史修改快照 |
 | `biz_invoice_taxrate` 税率配置 | `tax_code`、`tax_name`、`tax_rate`、`status` | 税率生效区间、适用票种范围等扩展控制字段 | 旧税率版本快照 |
 | 账单-发票关系快照 | 当前主模型通过 `biz_invoice` 与 `biz_charge*` 关联承接 | `charge_ids_snapshot`、账单集合来源、客户侧身份匹配结果、操作留痕标识 | 旧营业账开票关系表、旧发票明细表 |
@@ -1180,7 +1181,7 @@ retrieval_priority: P0
 | 开账记录、特殊开账 | `biz_charge`、`biz_charge_detail`、`biz_operat_log*` | 统一纳入营业账主表与明细表，特殊开账按来源类型、业务类型、依据说明留痕，不单设平行“特殊开账表” | 在线保留 |
 | 预存退款、已销调整、价差调整、分账调整、违约金减免、呆坏账新发生业务 | `biz_charge*` + 留痕骨架 + 目标对象语义 | 新发生业务优先走统一骨架承接，数据库文档保留目标对象命名和待补字段组，但不误写为已全部落地物理表 | 在线保留 |
 | 柜台收费、实时收费、代收代扣 | `biz_collection`、`biz_withholding`、`bk_transaction*`、`bk_withholding_*` | 统一纳入收费主模型与渠道交易模型，柜台班结/实时收费日志按交易结果和操作留痕归并 | 在线保留 |
-| 发票申请、开票结果、票据税率 | `biz_invoice`、`biz_invoice_taxrate`、`biz_cust_invoice` | 统一纳入发票主表、税率表和客户开票信息，不为旧“营业账开票表”机械复制新在线表 | 在线保留 |
+| 发票申请、开票结果、票据税率 | `biz_invoice_record`（业务记录）、`biz_invoice`（开票配置）、`biz_invoice_taxrate`、`biz_cust_invoice` | 统一纳入发票主表、税率表和客户开票信息，不为旧“营业账开票表”机械复制新在线表 | 在线保留 |
 | 微网厅业务字段、页面配置、微信参数 | `biz_business_types`、`biz_business_datas`、`biz_page_settings*`、`biz_parameter_settings`、`sys_wechat_app_settings` | 统一归并为业务类型、页面配置和渠道参数模型 | 在线保留 |
 | 办理附件、电子档案 | `biz_content`、`biz_content_attach` | 当前新增与迁移后新增资料统一按资料主表与附件表承接 | 在线保留 |
 

docs/evidence/bugfix/frontend/frontend-expect-cli-test-framework-2026-06-08.md

@@ -0,0 +1,354 @@
+# 前端 Expect CLI 测试框架接入记录
+
+日期：2026-06-08
+
+## 范围
+
+本记录对应 `water-frontend` 仓库新增 `expect-cli` 浏览器测试框架入口，用于在现有 Playwright 与 `node:test` 测试之外，提供 agent 驱动的浏览器测试能力。
+
+## 前端基线
+
+- 仓库：`water-frontend`
+- 工作目录：`/Volumes/Dpan/github/water-workspace/water-frontend`
+- 分支：`develop`
+- 基础提交：`35fb598c9059b0ea933de533892a0473512ad662`
+- 状态：测试框架接入已在工作区实现，尚未提交
+
+## 实现内容
+
+- 新增开发依赖：`expect-cli@^0.1.3`
+- 新增脚本：
+  - `pnpm test:expect`
+  - `pnpm test:expect:smoke`
+  - `pnpm test:expect:watch`
+  - `pnpm test:expect:acceptance`
+- 新增 runner：`tools/expect/run-expect.mjs`
+  - 默认目标地址为 `http://localhost:18080`
+  - 支持 `EXPECT_BASE_URL` 覆盖目标地址
+  - 本地服务不可达时自动启动 `pnpm dev`
+  - 复用已有本地服务时不接管其生命周期
+  - 支持 `--no-dev-server` 禁止自动启动
+- 新增验收场景库：`tests/expect/revenue-bugfix-clear-scope/scenarios.json`
+  - 覆盖 `#78`、`#39`、`#50`、`#53`、`#58/#59`、`#69/#76` 和基础回归。
+  - 场景来源为 `docs/superpowers/plans/2026-06-08-revenue-bugfix-clear-scope-acceptance-test.md`。
+  - 使用环境占位符表达测试账号、客户和业务数据，不在前端仓硬编码 live 数据。
+- 新增验收场景加载模块：`tools/expect/acceptance-scenarios.mjs`
+  - 验收指令默认使用严格黑盒规约：正式验收计划为 oracle，不以源码、路由、store、API 封装或既有自动化测试作为通过依据。
+  - 通过标准固定为 `PASS / FAIL / BLOCKED`，缺数据、缺权限或业务状态不足时必须标记 `BLOCKED`。
+- 新增验收数据预检：
+  - `acceptance` 运行前检查场景所需环境变量。
+  - 缺少测试账号、客户或业务记录时直接输出 `BLOCKED` 并以退出码 `2` 结束，不启动浏览器，不使用占位符继续测试。
+- 新增 runner/场景单元测试：
+  - `tests/expect/revenueBugfixAcceptanceScenarios.test.mjs`
+  - `tests/expect/runExpectRunnerArgs.test.mjs`
+- 新增使用说明：`tests/expect/README.md`
+
+## 验证命令
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+node --check tools/expect/run-expect.mjs
+node --check tools/expect/acceptance-scenarios.mjs
+node tools/expect/run-expect.mjs --help
+pnpm exec expect tui --help
+node -e "const pkg=require('./package.json'); console.log(pkg.scripts['test:expect']); console.log(pkg.scripts['test:expect:smoke']); console.log(pkg.scripts['test:expect:watch']); console.log(pkg.devDependencies['expect-cli'])"
+node --test tests/expect/revenueBugfixAcceptanceScenarios.test.mjs tests/expect/runExpectRunnerArgs.test.mjs
+pnpm test:expect:acceptance -- --list
+pnpm test:expect:acceptance -- rev-bugfix-39-counter-prepay-settlement
+```
+
+## 验证结果
+
+- runner 语法检查：通过。
+- 验收场景加载模块语法检查：通过。
+- runner 帮助输出：通过，显示 `test:expect`、`test:expect:smoke`、`test:expect:watch` 用法及 `EXPECT_BASE_URL` 等环境变量。
+- `expect-cli` 本地可执行性：通过，`pnpm exec expect tui --help` 成功输出 CLI 参数说明。
+- `package.json` 脚本解析：通过，`test:expect`、`test:expect:smoke`、`test:expect:watch`、`test:expect:acceptance` 均指向 `tools/expect/run-expect.mjs`，开发依赖版本为 `^0.1.3`。
+- 验收场景单元测试：通过，8 项通过、0 项失败。
+- 验收场景列表命令：通过，列出 7 个场景及各自 requiredData。
+- 严格数据预检：通过。执行 `pnpm test:expect:acceptance -- rev-bugfix-39-counter-prepay-settlement` 时，由于未提供 `EXPECT_TEST_CASHIER_A_USERNAME` 和 `EXPECT_TEST_CUSTOMER_C4`，命令输出 `BLOCKED` 并以退出码 `2` 结束，未启动浏览器。
+- `typecheck/vue-tsc`：按用户要求未继续执行，后续本项不作为该接入任务的默认验证。
+- 浏览器实际 smoke：未执行。本次完成框架接入、验收场景库和 CLI 可用性验证；真实业务验收需要测试环境提供 C1-C5、收费员 A/B、审批账号、水价模板、未结账/已结账记录等数据后运行。
+
+## 使用入口
+
+```bash
+pnpm test:expect
+pnpm test:expect:smoke
+pnpm test:expect:watch -- -m "test the flow you changed"
+pnpm test:expect:acceptance -- --list
+pnpm test:expect:acceptance -- rev-bugfix-53-prepaid-deduction
+pnpm test:expect:acceptance -- all
+EXPECT_BASE_URL=http://localhost:18081 pnpm test:expect
+```
+
+## 重新测试记录：2026-06-08 严格验收重跑
+
+### 触发背景
+
+前端工作区新增了红冲记录页面的时间范围默认时间处理：
+
+- `src/views/operatingCharges/redReversalRecord/index.vue`
+- `tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs`
+
+### 执行命令
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+pnpm test:expect:acceptance -- all
+pnpm test:expect:acceptance -- rev-bugfix-58-59-red-reversal-record
+node --test tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs
+node --test tests/expect/revenueBugfixAcceptanceScenarios.test.mjs tests/expect/runExpectRunnerArgs.test.mjs
+```
+
+### 结果
+
+- 严格全量验收：`BLOCKED`。当前 shell 未提供 `EXPECT_TEST_*` 测试账号、客户和业务记录数据，runner 未启动浏览器，未使用占位符继续测试。
+- `#58/#59` 红冲记录严格验收：`BLOCKED`。缺少：
+  - `EXPECT_TEST_CASHIER_A_USERNAME`
+  - `EXPECT_TEST_SETTLED_COUNTER_RECORD`
+- 代码契约验证：通过，`tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs` 共 5 项通过、0 项失败。
+- Expect 场景/runner 单元测试：通过，8 项通过、0 项失败。
+- `typecheck/vue-tsc`：未执行。
+
+### 结论
+
+本次只确认了红冲记录代码契约和 Expect 严格验收框架本身仍可用。正式黑盒业务验收未通过也未失败，状态为 `BLOCKED`，需要提供测试账号、客户和已结账可红冲记录后重新执行。
+
+## 收费与账务闭环场景库接入：2026-06-08
+
+### 范围
+
+基于 `/Volumes/Dpan/github/water-workspace/docs` 中收费、结账、预存抵扣业务资料，以及 `../water-docs/specs/001-rev004-accounting/` 中账务处理一期口径，新增前端 `expect-cli` 可执行场景 suite：
+
+- `tests/expect/revenue-accounting-closures/scenarios.json`
+- `tests/expect/revenue-accounting-closures/README.md`
+
+### 场景
+
+初版纳入 12 条场景：
+
+- P0 小闭环：
+  - `revenue-charge-normal-payment`
+  - `revenue-charge-no-arrears-topup`
+  - `revenue-charge-prepay-zero-confirm`
+  - `revenue-charge-prepay-partial-deduction`
+  - `revenue-charge-prepay-full-deduction`
+- P0 跨页面大闭环：
+  - `closure-charge-to-settlement`
+  - `closure-prepay-charge-to-settlement`
+  - `closure-settlement-to-red-reversal-record`
+- P1 账务处理小闭环：
+  - `accounting-unsold-split-submit`
+  - `accounting-unsold-bad-debt-submit`
+  - `accounting-unsold-price-diff-submit`
+  - `accounting-unsold-penalty-remission-submit`
+
+### 工具调整
+
+- `tools/expect/acceptance-scenarios.mjs` 支持多 suite 加载。
+- 场景引用支持：
+  - `revenue-accounting-closures:all`
+  - `revenue-accounting-closures:<scenario-id>`
+  - 全局唯一场景可直接使用 `<scenario-id>`
+- `requiredData` 扩展到账务和收费闭环数据键，例如 `customerArrears`、`customerNoArrears`、`unsoldBillCustomer` 等。
+
+### 验证命令
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+node --test tests/expect/revenueAccountingClosureScenarios.test.mjs tests/expect/revenueBugfixAcceptanceScenarios.test.mjs tests/expect/runExpectRunnerArgs.test.mjs
+node --check tools/expect/acceptance-scenarios.mjs
+node --check tools/expect/run-expect.mjs
+pnpm test:expect:acceptance -- --list
+pnpm test:expect:acceptance -- revenue-accounting-closures:closure-charge-to-settlement
+```
+
+### 结果
+
+- 多 suite 场景加载、schema、requiredData 映射、prompt 生成测试：通过，15 项通过、0 项失败。
+- runner 语法检查：通过。
+- 场景列表命令：通过，可列出 bugfix suite 和 `revenue-accounting-closures` suite。
+- 严格业务执行：`pnpm test:expect:acceptance -- revenue-accounting-closures:closure-charge-to-settlement` 返回 `BLOCKED`，缺少 `EXPECT_TEST_CASHIER_A_USERNAME` 与 `EXPECT_TEST_CUSTOMER_ARREARS`，未启动浏览器，不作为失败或通过。
+- `typecheck/vue-tsc`：未执行。
+
+## 验证记录：2026-06-08 收费与账务闭环 suite
+
+### 执行命令
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+node --check tools/expect/acceptance-scenarios.mjs
+node --check tools/expect/run-expect.mjs
+node --test tests/expect/revenueAccountingClosureScenarios.test.mjs tests/expect/revenueBugfixAcceptanceScenarios.test.mjs tests/expect/runExpectRunnerArgs.test.mjs
+node --test tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs
+pnpm test:expect:acceptance -- --list
+pnpm test:expect:acceptance -- revenue-accounting-closures:all
+pnpm test:expect:acceptance -- revenue-accounting-closures:closure-charge-to-settlement
+```
+
+### 结果
+
+- runner 语法检查：通过。
+- Expect 场景/runner 单元测试：通过，15 项通过、0 项失败。
+- 营收缺陷代码契约测试：通过，5 项通过、0 项失败。
+- 场景列表：通过，列出 `revenue-bugfix-clear-scope` 与 `revenue-accounting-closures` 两个 suite。
+- `revenue-accounting-closures:all`：`BLOCKED`。缺少收费员、欠费客户、无欠费客户、预存余额客户、已结账红冲记录、管理员和未销账单客户等测试数据。
+- `revenue-accounting-closures:closure-charge-to-settlement`：`BLOCKED`。缺少：
+  - `EXPECT_TEST_CASHIER_A_USERNAME`
+  - `EXPECT_TEST_CUSTOMER_ARREARS`
+- 浏览器黑盒业务执行：未启动。阻塞发生在 requiredData 预检阶段，符合严格验收规则。
+- `typecheck/vue-tsc`：未执行。
+
+## 验证记录：2026-06-08 Expect runner 与页面 smoke 重跑
+
+### 触发背景
+
+前端工作区继续调整了 Expect runner 可执行性，并对红冲记录页的红冲时间范围默认时间进行了补充：
+
+- `tools/expect/run-expect.mjs`
+- `tests/expect/runExpectRunnerArgs.test.mjs`
+- `src/views/operatingCharges/redReversalRecord/index.vue`
+- `tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs`
+
+### 工具调整
+
+- `tools/expect/run-expect.mjs` 改为优先调用本地 `node_modules/.bin/expect`，避免 `pnpm exec expect` 在当前工作区触发隐式 `pnpm install`。
+- runner 增加 `EXPECT_BIN` 覆盖入口，便于特殊环境指定 Expect 可执行文件。
+- runner 过滤 npm/pnpm 转发参数中的独立 `--` 分隔符，修复 `pnpm test:expect:acceptance -- <scenario-id>` 被 Expect 识别为多余位置参数的问题。
+
+### 执行命令
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+node --test tests/expect/runExpectRunnerArgs.test.mjs
+node --test tests/expect/revenueBugfixAcceptanceScenarios.test.mjs tests/expect/revenueAccountingClosureScenarios.test.mjs
+node --test tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs
+corepack pnpm@9.15.9 test:expect:acceptance -- --list
+source /tmp/revenue-acceptance-env.sh
+corepack pnpm@9.15.9 test:expect:acceptance -- rev-bugfix-50-cashier-filter --target unstaged --timeout 120000 --verbose
+./node_modules/.bin/eslint tools/expect/run-expect.mjs tests/expect/runExpectRunnerArgs.test.mjs tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs src/views/operatingCharges/redReversalRecord/index.vue
+corepack pnpm@9.15.9 ts:check
+NODE_OPTIONS=--max-old-space-size=16384 corepack pnpm@9.15.9 ts:check
+corepack pnpm@9.15.9 build:dev
+```
+
+### 结果
+
+- runner 单元测试：通过，5 项通过、0 项失败。
+- Expect 场景加载测试：通过，12 项通过、0 项失败。
+- 营收缺陷代码契约测试：通过，5 项通过、0 项失败。
+- 场景列表命令：通过。需使用 `corepack pnpm@9.15.9`；当前 shell 的全局 `pnpm@11.5.1` 会在脚本执行前尝试清理并重装 `node_modules`，无 TTY 时退出。
+- `rev-bugfix-50-cashier-filter` 严格黑盒验收：`BLOCKED`。requiredData 环境变量已提供，但 Expect 启动 Codex ACP 后返回 `401 Unauthorized`，提示当前 Codex agent 未认证或 API key 无效；未进入浏览器业务步骤，不可判定 `PASS` 或 `FAIL`。
+- 页面 smoke（Playwright fallback）：通过登录默认租户 `福建水投集团`、用户 `admin` 后访问真实菜单路由：
+  - `/operatingCharges/counterCheckout`：页面标题为 `营业收费管理系统 - 柜台结账`，未出现 404，无 failed network request；截图在 `water-frontend/test-results/counter-checkout-smoke.png`。
+  - `/operatingCharges/redReversalRecord`：页面标题为 `营业收费管理系统 - 红冲记录`，查询区显示 `红冲时间`，表格显示柜台红冲记录字段，无 failed network request；截图在 `water-frontend/test-results/red-reversal-record-smoke.png`。
+- 页面 smoke 备注：运行时存在既有 Vue/router warning，包括未解析菜单组件 `system/userformconfig/index`、`pay/demo/transfer/index`，以及 `inject() can only be used inside setup()` 等；未在本次范围内修复。
+- focused ESLint：通过。
+- `ts:check`：失败。默认堆内存运行先 OOM；增大到 16G 后完成但暴露 repo-wide 既有 TypeScript 错误，涉及 mall statistics、BPM designer、pay views、system views、settings 等大量非本次修改文件。本结果不作为本次改动通过项。
+- `build:dev`：通过，输出 `Build successful. Please see dist directory`。构建期间仍有既有 Vite CJS deprecation warning、SVG symbolId warning、Rollup PURE annotation warning。
+
+### 结论
+
+Expect runner 的本地执行入口和 pnpm 参数转发问题已修复并由单元测试覆盖。`rev-bugfix-50-cashier-filter` 严格黑盒验收当前阻塞于 Codex ACP 认证，状态为 `BLOCKED`；页面级 fallback smoke 只证明页面可登录访问和基础渲染，不替代正式黑盒业务验收。
+
+## 修复记录：2026-06-08 Expect runner 完整收敛
+
+### 触发背景
+
+上一轮验证后仍有三个仓库内可控问题：
+
+- 当前 shell 的全局 `pnpm@11.5.1` 与 `node_modules/.modules.yaml` 中的 `pnpm@9.15.9` 布局不一致，未 pin 时会触发脚本前置安装/清理风险。
+- runner 自动启动 dev server 时仍通过 `pnpm dev`，在 pnpm 版本不一致时可能复现同类问题。
+- `tests/expect` 场景中存在 `/operating-charges/...` 旧路由元数据，而当前真实菜单路由为 `/operatingCharges/...`。
+- Expect 调用 Codex ACP 认证失败时输出原始栈，不够符合严格验收的 `BLOCKED` 语义。
+
+### 实现内容
+
+- `package.json` 新增 `packageManager: pnpm@9.15.9`。
+- `tools/expect/run-expect.mjs`：
+  - dev server 启动改为直接调用本地 `node_modules/vite/bin/vite.js --mode dev`。
+  - 保留 `EXPECT_DEV_SERVER_BIN` 用于特殊环境覆盖。
+  - 捕获 Expect 输出并识别 Codex ACP `401 Unauthorized` / `AcpProviderUnauthenticatedError`，转为清晰 `BLOCKED` 输出和退出码 `2`。
+- `tests/expect/revenue-bugfix-clear-scope/scenarios.json`：
+  - 为 bugfix 场景补充真实页面路由元数据。
+- `tests/expect/revenue-accounting-closures/scenarios.json`：
+  - 将收费、结账、红冲场景的旧路由更新为 `/operatingCharges/counterCharging`、`/operatingCharges/counterCheckout`、`/operatingCharges/redReversalRecord`。
+- `tests/expect/runExpectRunnerArgs.test.mjs`、`tests/expect/revenueBugfixAcceptanceScenarios.test.mjs`、`tests/expect/revenueAccountingClosureScenarios.test.mjs` 补充回归测试覆盖上述行为。
+
+### 执行命令
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+node --test tests/expect/runExpectRunnerArgs.test.mjs
+node --test tests/expect/revenueBugfixAcceptanceScenarios.test.mjs tests/expect/revenueAccountingClosureScenarios.test.mjs
+node --test tests/expect/runExpectRunnerArgs.test.mjs tests/expect/revenueBugfixAcceptanceScenarios.test.mjs tests/expect/revenueAccountingClosureScenarios.test.mjs
+node --test tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs
+./node_modules/.bin/eslint tools/expect/run-expect.mjs tools/expect/acceptance-scenarios.mjs tests/expect/runExpectRunnerArgs.test.mjs tests/expect/revenueBugfixAcceptanceScenarios.test.mjs tests/expect/revenueAccountingClosureScenarios.test.mjs tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs src/views/operatingCharges/redReversalRecord/index.vue
+pnpm test:expect:acceptance -- --list
+pnpm test:expect:acceptance -- revenue-accounting-closures:closure-charge-to-settlement
+source /tmp/revenue-acceptance-env.sh
+pnpm test:expect:acceptance -- rev-bugfix-50-cashier-filter --target unstaged --timeout 120000 --verbose
+pnpm build:dev
+```
+
+### 结果
+
+- runner 单测：通过，9 项通过、0 项失败。
+- Expect 场景测试：通过，14 项通过、0 项失败。
+- 合并执行 Expect runner/场景测试：通过，23 项通过、0 项失败。
+- 营收缺陷契约测试：通过，5 项通过、0 项失败。
+- focused ESLint：通过。
+- `pnpm test:expect:acceptance -- --list`：通过，可在 plain `pnpm` 下列出两个 suite 的场景。
+- `pnpm test:expect:acceptance -- revenue-accounting-closures:closure-charge-to-settlement`：按 requiredData 预检返回 `BLOCKED`，缺少 `EXPECT_TEST_CASHIER_A_USERNAME` 与 `EXPECT_TEST_CUSTOMER_ARREARS`，退出码 `2`。
+- `pnpm test:expect:acceptance -- rev-bugfix-50-cashier-filter --target unstaged --timeout 120000 --verbose`：requiredData 已提供，但 Codex ACP 认证失败，runner 输出清晰 `BLOCKED: Codex ACP authentication failed before browser acceptance steps ran...`，退出码 `2`，未再输出原始 ACP 栈。
+- `pnpm build:dev`：通过，输出 `Build successful. Please see dist directory`。构建期间仍存在既有 Vite CJS deprecation warning、SVG symbolId warning、Rollup PURE annotation warning。
+
+### 结论
+
+本次已将仓库内可控问题收敛：pnpm 版本、runner 启动路径、场景路由元数据、Codex ACP 认证失败语义均已有自动化测试覆盖。严格黑盒业务验收仍取决于外部 Codex ACP 认证状态；认证未完成时应按 `BLOCKED` 处理，不应判定业务 `PASS` 或 `FAIL`。
+
+## 本地 Playwright smoke 入口：2026-06-08 无 ACP 场景
+
+### 触发背景
+
+用户本机没有 Codex ACP 认证，`pnpm test:expect:acceptance -- rev-bugfix-50-cashier-filter` 只能得到 `BLOCKED`，无法进入浏览器业务步骤。为保证前端页面链路仍可在本地验证，本次新增不依赖 ACP 的 Playwright smoke runner。
+
+### 实现内容
+
+- `package.json` 新增 `test:revenue:smoke`，执行 `node tools/revenue/run-local-smoke.mjs`。
+- `tools/revenue/run-local-smoke.mjs`：
+  - 默认读取 `/tmp/revenue-acceptance-env.sh`，支持 `REVENUE_SMOKE_ENV_FILE` 覆盖。
+  - 使用 `EXPECT_BASE_URL`、`EXPECT_TEST_ADMIN_USERNAME`、`EXPECT_TEST_ADMIN_PASSWORD` 等本机环境变量登录本地前端代理 `/admin-api/system/auth/login`。
+  - 自动复用或启动本地 Vite dev server。
+  - 访问 `/operatingCharges/counterCheckout` 与 `/operatingCharges/redReversalRecord`，检查页面标题/关键文案、登录状态、not-found 状态，并输出截图。
+  - 对登录不可达、认证被拒等数据/环境问题输出 `BLOCKED`，退出码 `2`。
+  - 修复两个 runner 稳定性问题：`SmokeBlockedError` TDZ、业务流水号包含 `404` 时误判为 404 页。
+- `tests/revenue-bugs/revenueLocalSmokeRunner.test.mjs` 覆盖 env 解析、默认配置、页面清单、BLOCKED 输出、404 误判和超时 helper。
+
+### 执行命令
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+node --test tests/revenue-bugs/revenueLocalSmokeRunner.test.mjs
+pnpm test:revenue:smoke
+node --test tests/revenue-bugs/revenueLocalSmokeRunner.test.mjs tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs
+node --test tests/expect/runExpectRunnerArgs.test.mjs tests/expect/revenueBugfixAcceptanceScenarios.test.mjs tests/expect/revenueAccountingClosureScenarios.test.mjs
+pnpm exec eslint tools/revenue/run-local-smoke.mjs tests/revenue-bugs/revenueLocalSmokeRunner.test.mjs
+pnpm build:dev
+```
+
+### 结果
+
+- 本地 smoke runner 单测：通过，9 项通过、0 项失败。
+- 本地页面 smoke：通过。
+  - `/operatingCharges/counterCheckout`：登录用户 `admin`，页面显示 `未结账`、`已结账`、`收费员`；截图为 `water-frontend/test-results/counter-checkout-local-smoke.png`。
+  - `/operatingCharges/redReversalRecord`：页面显示 `红冲记录`、`红冲时间`、`收费员`；截图为 `water-frontend/test-results/red-reversal-record-local-smoke.png`。
+- 营收缺陷契约测试 + 本地 runner 单测：通过，14 项通过、0 项失败。
+- Expect runner/场景测试：通过，23 项通过、0 项失败。
+- focused ESLint：通过。
+- `pnpm build:dev`：通过，输出 `Build successful. Please see dist directory`。构建期间仍存在既有 Vite CJS deprecation warning、SVG symbolId warning、Rollup PURE annotation warning。
+
+### 结论
+
+本地前端页面链路现在可以通过 `pnpm test:revenue:smoke` 在无 ACP 的机器上执行。该入口证明登录、动态菜单路由、页面基础渲染和截图可用；它不替代 `expect-cli` 严格黑盒验收，也不验证 #50 收费员 A/B 业务数据筛选结果。严格业务验收仍需 ACP、其他可用 agent，或人工按正式验收计划执行。

docs/evidence/bugfix/frontend/frontend-payment-method-account-address-required-2026-06-09.md

@@ -0,0 +1,56 @@
+# 客户缴费方式开户地址前端必填校验修复验证记录
+
+日期：2026-06-09
+
+## 问题现象
+
+客户资料页面修改缴费方式时，前端代扣/托收表单展示了“开户地址”字段，但未做必填校验；提交到后端后，后端在保存代扣或托收资料时返回“开户地址不能为空”。
+
+## 结论
+
+本问题应由前端补齐校验。原因是后端代扣、托收资料保存对象均将 `accountAddress` 定义为必填字段，客户缴费方式修改链路会复用这两个保存对象。
+
+## 修复范围
+
+仓库：`../water-frontend`
+
+基线：`35aa0fbb`
+
+修改文件：
+
+- `src/views/custData/custInfo/components/PayMethodForm.vue`
+- `src/views/custData/custCreate/components/WithHold.vue`
+- `src/views/custData/custInfo/components/PayMethodForm.contract.test.mjs`
+
+## 修复内容
+
+- 客户详情“缴费方式”弹窗：
+  - 托收资料 `collectionFormRules` 增加 `accountAddress` 必填。
+  - 代扣资料 `withHoldingFormRules` 增加 `accountAddress` 必填。
+- 新户建档代扣弹窗：
+  - `formRules` 增加 `accountAddress` 必填。
+- 补充 node:test 契约测试，锁定上述规则。
+
+## 验证命令与结果
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+node --test src/views/custData/custInfo/components/PayMethodForm.contract.test.mjs
+```
+
+结果：通过。
+
+- `tests 2`
+- `pass 2`
+- `fail 0`
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+git diff --check -- src/views/custData/custInfo/components/PayMethodForm.vue src/views/custData/custCreate/components/WithHold.vue src/views/custData/custInfo/components/PayMethodForm.contract.test.mjs
+```
+
+结果：通过，无空白错误。
+
+## 备注
+
+当前前端仓库存在其他未提交的 expect 相关改动，本次未触碰。

docs/evidence/bugfix/frontend/yw-business-flows-expect-cases-2026-06-09.md

@@ -0,0 +1,115 @@
+# YW 业务流程 Expect 验收用例编制记录（2026-06-09）
+
+## 背景
+
+根据用户在 2026-06-09 提供的 5 条业务测试用例，前端仓新增 Expect 黑盒验收场景 suite：
+
+- `yw-business-flows:yw-01`：手工建档
+- `yw-business-flows:yw-02`：册本调整
+- `yw-business-flows:yw-03`：抄表录入
+- `yw-business-flows:yw-04`：复核开账
+- `yw-business-flows:yw-05`：柜台收费
+
+前端实现位置：
+
+- `../water-frontend/tests/expect/yw-business-flows/scenarios.json`
+- `../water-frontend/tests/expect/ywBusinessFlowsScenarios.test.mjs`
+- `../water-frontend/tools/expect/acceptance-scenarios.mjs`
+- `../water-frontend/tests/expect/README.md`
+
+## 执行入口
+
+```bash
+pnpm test:expect:acceptance -- yw-business-flows:all
+pnpm test:expect:acceptance -- yw-business-flows:yw-01
+pnpm test:expect:acceptance -- yw-05
+```
+
+## 测试数据要求
+
+新增场景使用以下测试数据环境变量：
+
+- `EXPECT_TEST_NEW_CUSTOMER_ARCHIVE`
+- `EXPECT_TEST_AVAILABLE_METER`
+- `EXPECT_TEST_INVOICE_PROFILE`
+- `EXPECT_TEST_ARCHIVED_CUSTOMER`
+- `EXPECT_TEST_TARGET_METER_BOOK`
+- `EXPECT_TEST_METER_READ_CUSTOMER`
+- `EXPECT_TEST_METER_READING_VALUE`
+- `EXPECT_TEST_REVIEWABLE_METER_READ_RECORD`
+- `EXPECT_TEST_BILLABLE_METER_READ_RECORD`
+- `EXPECT_TEST_CHARGED_CUSTOMER`
+
+并复用：
+
+- `EXPECT_TEST_ADMIN_USERNAME`
+- `EXPECT_TEST_CASHIER_A_USERNAME`
+
+缺少上述数据时，runner 必须在启动浏览器前返回 `BLOCKED`，不得使用占位符或编造业务记录继续执行。
+
+## 验证结果
+
+已执行目录契约与 runner 数据门禁验证：
+
+```bash
+node --test tests/expect/ywBusinessFlowsScenarios.test.mjs
+```
+
+结果：`pass 6 / fail 0`。
+
+```bash
+pnpm test:expect:acceptance -- --list
+```
+
+结果：命令退出码 `0`，`yw-business-flows:yw-01` 至 `yw-business-flows:yw-05` 均已列出。
+
+```bash
+pnpm test:expect:acceptance -- yw-05 --no-dev-server
+```
+
+结果：命令退出码 `2`，按预期返回：
+
+- `BLOCKED: missing required acceptance test data for yw-05.`
+- 缺少 `EXPECT_TEST_CASHIER_A_USERNAME`
+- 缺少 `EXPECT_TEST_CHARGED_CUSTOMER`
+
+```bash
+pnpm test:expect:acceptance -- yw-business-flows:all --no-dev-server
+```
+
+结果：命令退出码 `2`，按预期返回 `BLOCKED`，缺少全部 5 条 YW 用例所需的账号、客户、册本、水表、抄表、复核开账与柜台收费测试数据。
+
+```bash
+node --test tests/expect/*.test.mjs
+```
+
+结果：`pass 30 / fail 0`。
+
+### 真实浏览器验收尝试（2026-06-09 12:00 CST）
+
+```bash
+pnpm test:expect:acceptance -- yw-business-flows:all --no-dev-server --timeout 1800000
+```
+
+结果：命令退出码 `1`，未形成 `PASS` 业务验收结论。
+
+- 已启动真实浏览器并进入 `yw-business-flows:yw-01` 手工建档场景。
+- 浏览器侧可见记录显示已登录并访问 `http://localhost:18080/custData/custCreate`。
+- 运行过程中产生的主要证据：
+  - `/tmp/expect-artifacts/playwright/page@8c120c0eebb660ecda33437a218d685a.webm`
+  - `/tmp/expect-artifacts/playwright-results/result-*.json`
+  - `.expect/logs.md`
+- ACP rollout 日志显示：用例在 `yw-01` 内部反复处理 Element Plus 下拉选择器，后续浏览器 transport 关闭。
+- Expect 最终报错：
+  - `ACP stream inactivity timeout`
+  - `Streaming failed: Agent produced no output for 180s.`
+- 本次运行未进入 `yw-02` 至 `yw-05` 的业务执行阶段。
+- 本次运行中测试数据环境变量虽然已设置，但部分值存在乱码；agent 曾使用自行构造的可读测试数据继续填写。按黑盒验收规则，这不能作为有效 `PASS` 证据。
+
+本次真实浏览器验收结论：`BLOCKED` / `FAIL-RUNNER`。阻断原因为 Expect ACP/browser transport 超时，且测试数据可读性不足；业务功能本身尚不能据此判定通过或失败。
+
+## 当前结论
+
+测试用例已编制为可执行 Expect 黑盒验收场景，目录加载、提示词生成和数据缺失拦截均通过。
+
+截至本记录，真实浏览器业务验收已尝试执行，但未形成有效业务通过结论；当前阻断点为测试数据可读性不足与 Expect ACP/browser transport 超时。真实业务场景结论当前仍为 `BLOCKED`，不是 `PASS`。

docs/evidence/bugfix/revenue-bugfix-clear-scope-2026-06-08.md

@@ -0,0 +1,178 @@
+# 营收明确缺陷第一批修复验证记录
+
+日期：2026-06-08
+
+## 修复范围
+
+- #78 水价调整失败后重试闭环
+- #39 柜台预存缴费进入结账
+- #50 柜台结账收费员筛选
+- #53 预存抵扣校验
+- #58/#59 柜台红冲记录查询
+- #69/#76 待审批账务调整文案
+
+## 后端基线
+
+- 仓库：water-backend
+- Worktree：backend-revenue-bugfix-clear-scope
+- 提交：`ba136759b1925789cb0adc18105d00d6928add59`
+
+## 前端基线
+
+- 仓库：water-frontend
+- Worktree：frontend-revenue-bugfix-clear-scope
+- 提交：`5f7ad7754473541483b26efa324419eb7a5d1a3b`
+
+## 验证命令与结果
+
+### 后端 targeted tests
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/worktrees/backend-revenue-bugfix-clear-scope
+mvn -pl sw-business/sw-business-server -Dtest=PriceTemplateServiceImplTest,PriceTemplateAdjustmentLockRedisDAOTest,CounterSettleApplicationServiceImplTest,ChargeServiceImplCounterPrepayTest test
+```
+
+结果：通过。
+
+- Surefire 汇总：`Tests run: 26, Failures: 0, Errors: 0, Skipped: 0`
+- Maven 结果：`BUILD SUCCESS`
+- 备注：执行期间存在既有 Maven model warning、Mockito dynamic-agent warning；`PriceTemplateServiceImplTest` 中有一段业务代码捕获后记录的 NPE 栈日志，但测试结果为 0 failures / 0 errors。
+
+### 后端 compile
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/worktrees/backend-revenue-bugfix-clear-scope
+mvn -pl sw-business/sw-business-server -DskipTests compile
+```
+
+结果：通过。
+
+- Maven 结果：`BUILD SUCCESS`
+
+### 前端 contract test
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/worktrees/frontend-revenue-bugfix-clear-scope
+node --test tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs
+```
+
+结果：通过。
+
+- Node test 汇总：`tests 5`, `pass 5`, `fail 0`
+
+### 前端 settings contract regression
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/worktrees/frontend-revenue-bugfix-clear-scope
+node --test tests/settings/priceTemplateAdjustmentErrorHandling.test.mjs
+```
+
+结果：通过。
+
+- Node test 汇总：`tests 3`, `pass 3`, `fail 0`
+
+### 前端 type check
+
+```bash
+pnpm ts:check
+```
+
+结果：未完成，不作为通过项。
+
+- 首次执行长时间无诊断输出后以 `[ELIFECYCLE] Command failed.` 退出。
+- 随后按用户明确指令停止继续运行 `vue-tsc` / `pnpm ts:check`。
+- 已终止残留 `vue-tsc` 进程。
+
+### 前端 build
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/worktrees/frontend-revenue-bugfix-clear-scope
+pnpm build:dev
+```
+
+结果：通过。
+
+- 输出：`Build successful. Please see dist directory`
+- 备注：构建期间存在既有 Vite CJS deprecation warning、SVG icon symbolId warning、Rollup PURE annotation warning。
+
+## 备注
+
+- 前端 worktree 中存在未跟踪 `test-results/*.png` 截图产物，本次未提交。
+- 本轮未处理 #70 和 #9。#70 需抓包确认提交字段；#9 需产品确认抄表状态规则。
+
+## Jenkins 构建修复补充记录（2026-06-09）
+
+### 问题定位
+
+- Jenkins `sw-system-cloud-dev-pipeline` 在 `sw-business-server` 编译阶段报出 `*DORef` 缺失、Lombok getter/setter/log 缺失以及 `CounterSettleApplicationServiceImpl.isChargePaymentRecord(...)` 重复定义。
+- 本地复现确认：`PrestorageBpmCallbackService` 已存在 `@Slf4j`，`log` 缺失不是独立代码问题，而是编译异常导致注解处理未完成后的级联报错。
+- 修复 `CounterSettleApplicationServiceImpl` 中重复的 `isChargePaymentRecord(PaymentRecordDO)` 后，`target/generated-sources/annotations` 重新生成 `*DORef.java`，Lombok 相关报错消失。
+- 同一提交引入的 `Collection::stream` 代码缺少 `java.util.Collection` 导入，补齐后编译闭环通过。
+
+### 后端修复范围
+
+- 仓库：`../water-backend`
+- 分支：`develop`
+- 基线：`8e42a5123`
+- 修改文件：`sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/service/countersettle/CounterSettleApplicationServiceImpl.java`
+
+### 验证命令与结果
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend
+mvn -pl sw-business/sw-business-server -am -DskipTests compile
+```
+
+结果：通过。
+
+- Maven 结果：`BUILD SUCCESS`
+- 说明：用于确认注解处理恢复，`*DORef` 生成文件重新出现。
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend
+mvn clean package -DskipTests -T 1C -pl sw-dependencies,sw-framework,sw-gateway,sw-server,sw-module-system,sw-module-infra,sw-module-bpm,sw-module-pay,sw-module-report,sw-business,sw-business-bank,sw-module-member -am
+```
+
+结果：通过。
+
+- Maven 结果：`BUILD SUCCESS`
+- 耗时：`01:13 min (Wall Clock)`
+- 备注：执行期间仍存在既有 Maven model warning、MapStruct unmapped target warning、Mockito `MockBean` deprecation warning；均未导致构建失败。
+
+## Jenkins 构建修复收敛记录（2026-06-09 10:35）
+
+### 修复收敛结论
+
+- 已确认 `8e42a5123 fix: configure sw-common annotation processors` 不是本次 Jenkins 编译失败的根因修复。
+- 已将 `sw-framework/sw-common/pom.xml` 恢复到 `8e42a5123` 之前的注解处理器版本配置，避免保留错误方向的 POM 改动。
+- 最终保留的真实修复为：
+  - 删除 `CounterSettleApplicationServiceImpl` 中重复定义的 `isChargePaymentRecord(PaymentRecordDO)`。
+  - 补齐同文件中 `Collection::stream` 所需的 `java.util.Collection` import。
+
+### 后端最终修复范围
+
+- 仓库：`../water-backend`
+- 分支：`develop`
+- 修复前基线：`8e42a5123`
+- 后端修复提交：`86203127eeb27fcb1ff8228a89a77eb3a3325c57`
+- 修改文件：
+  - `sw-framework/sw-common/pom.xml`
+  - `sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/service/countersettle/CounterSettleApplicationServiceImpl.java`
+
+### 最终验证命令与结果
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend
+mvn clean package -DskipTests -T 1C -pl sw-dependencies,sw-framework,sw-gateway,sw-server,sw-module-system,sw-module-infra,sw-module-bpm,sw-module-pay,sw-module-report,sw-business,sw-business-bank,sw-module-member -am
+```
+
+结果：通过。
+
+- Maven 结果：`BUILD SUCCESS`
+- 耗时：`01:15 min (Wall Clock)`
+- 完成时间：`2026-06-09T10:35:31+08:00`
+- 关键模块结果：
+  - `sw-common`: `SUCCESS`
+  - `sw-business-server`: `SUCCESS`
+  - `sw-server`: `SUCCESS`
+- 备注：验证命令使用 `-DskipTests`，本次结论覆盖编译与打包；测试执行被跳过。

docs/evidence/rev004-accounting/rev004-accountprocess-integration-testing-bootstrap-2026-04-13.md

@@ -198,6 +198,49 @@
 - `soldSubmit_shouldWritePendingOperatLog`
 - `soldBatchRevoke_shouldWriteRevokeLogForPendingSyntheticRecord`
 - `logPrestorage_shouldClearChargePaymentAndIncreaseTargetDeposit`
+
+## 2026-06-05 sw-business-server 启动循环修复验证
+
+### 问题现象
+- 环境：`root@192.168.10.130`，容器 `sw-business-server`
+- 现象：容器反复重启，Docker healthcheck 一度显示 healthy，但应用日志持续出现 `Application run failed`
+- 关键异常：
+  - `Error creating bean with name 'prestorageAdjustBpmApiImpl'`
+  - `Error creating bean with name 'prestorageBpmCallbackService'`
+  - `BeanCurrentlyInCreationException: Error creating bean with name 'custServiceImpl'`
+  - `custServiceImpl` 已以 raw version 注入 `chargeServiceImpl`、`waterUseSchemeServiceImpl`、`exceedWaterUseSchemeServiceImpl`、`custWaterSchemeRelServiceImpl`，随后又被 AOP 包装，Spring 拒绝混用 raw bean 与 proxy bean
+
+### 修复策略
+- 保留既有 `spring.main.allow-circular-references=true` 配置；该配置只能允许普通循环依赖，不能解决 raw bean 被代理包装后的不一致问题。
+- 对异常中明确点名的 4 个 `CustService` 注入点增加 `@Lazy`：
+  - `ChargeServiceImpl.custService`
+  - `WaterUseSchemeServiceImpl.custService`
+  - `ExceedWaterUseSchemeServiceImpl.custService`
+  - `CustWaterSchemeRelServiceImpl.custService`
+- 新增回归测试 `CustServiceCircularDependencyContractTest`，约束上述 4 个注入点必须使用 lazy proxy。
+
+### 本次验证
+- RED 验证：
+  - 命令：`mvn -pl sw-business/sw-business-server -am -Dtest=CustServiceCircularDependencyContractTest -Dsurefire.failIfNoSpecifiedTests=false test`
+  - 结果：测试按预期失败，失败点为 `ChargeServiceImpl.custService must be @Lazy`
+- GREEN 验证：
+  - 命令：`mvn -pl sw-business/sw-business-server -am -Dtest=CustServiceCircularDependencyContractTest -Dsurefire.failIfNoSpecifiedTests=false test`
+  - 结果：BUILD SUCCESS，`1 tests / 0 failures / 0 errors / 0 skipped`
+- 打包验证：
+  - 命令：`mvn -pl sw-business/sw-business-server -am -DskipTests package`
+  - 结果：BUILD SUCCESS，生成 `sw-business/sw-business-server/target/sw-business-server.jar`
+- 远端部署验证：
+  - 上传 jar 到 `/projects/sw-cloud/sw-business-server/target/sw-business-server.jar`
+  - 远端执行：`cd /projects/sw-cloud && docker compose build sw-business-server && docker compose up -d sw-business-server`
+  - 结果：镜像 `sw-cloud-sw-business-server` 重建成功，容器 `sw-business-server` 重新创建并启动
+- 远端运行验证：
+  - 日志出现：`Tomcat started on port 48090`、`nacos registry, DEFAULT_GROUP business-server 192.168.10.130:48090 register finished`、`Started BusinessApplication in 42.77 seconds`
+  - 最近启动日志未再出现 `Application run failed`、`BeanCurrentlyInCreationException`、`Error creating bean with name`
+  - HTTP 验证：`curl http://127.0.0.1:48090/actuator/health` 返回 `{"status":"UP"}`，HTTP 200
+
+### 遗留风险
+- `docker-compose.yml` 中 `sw-business-server` healthcheck 当前检查 `http://localhost:48080`，而业务应用实际监听 `48090`；该 healthcheck 会把其他服务返回的 HTTP 200 / 404 JSON 误判为业务健康。建议后续改为 `http://localhost:48090/actuator/health`。
+- 当前修复是最小断环修复；长期更优方向是拆分 `CustServiceImpl` 的查询能力与写能力，减少跨业务 service 之间的双向依赖。
 - `logRevoke_shouldRestoreChargePaymentAndRollbackTransferredDeposit`
 - `logProcess_shouldReturnUpdatedProcessSummary`
 - `logAttachments_shouldReturnUnresolvedAttachmentRef`
@@ -420,3 +463,112 @@
 ### 影响
 - `prestorage` 查询/提交流程/撤销/流程查看/附件查看 这一组链路现在都已有真实库证据
 - 剩余缺口进一步收敛到：字典 label / UI 文案一致性、边角筛选条件穷尽、UI 编排级验证
+
+## 2026-06-05 远端启动修复后真实 HTTP/BPM 闭环验证
+
+### 环境
+- 后端：`192.168.10.130`，`sw-business-server` 端口 `48090`，gateway 端口 `48080`
+- 前端代理：本地 Vite `http://127.0.0.1:18080/admin-api` -> gateway
+- 数据库：`192.168.10.130:5436/sw_system`
+- 测试数据：`00_reset.sql` + `01_dict_seed.sql` + `10_prestorage_seed.sql`
+
+### 启动与健康检查
+- `sw-business-server` 重新构建部署后日志出现 `Started BusinessApplication`
+- `curl http://192.168.10.130:48090/actuator/health` 返回 `{"status":"UP"}`
+- `curl http://192.168.10.130:48080/actuator/health` 返回 `{"status":"UP"}`
+
+### 真实接口链路
+1. 登录
+- `POST /admin-api/system/auth/login`
+- `tenant-id: 1`
+- 返回 `code=0`，获得 `accessToken`
+
+2. 预存退款：保存 -> BPM 审批 -> 自动执行 -> 查询回看
+- `POST /admin-api/business/accounting-adjust/prestorage-save`
+- 请求核心字段：
+  - `custCode=REV004_IT_SRC`
+  - `refundAmount=10.00`
+  - `applicant=接口闭环测试人`
+  - `attachmentRefs=[real-api-proof-1]`
+- 保存返回：
+  - `adjustmentNo=REV004-PRF-900001-20260605101623`
+  - `resultStatus=PENDING_APPROVAL`
+  - `approvalStatus=PENDING_APPROVAL`
+  - `writeBackStatus=PENDING`
+  - `resultObjectNo=8d8af605-6084-11f1-8df9-5ad978d7f8ab`
+- BPM 待办：
+  - `GET /admin-api/bpm/task/list-by-process-instance-id?processInstanceId=8d8af605-6084-11f1-8df9-5ad978d7f8ab`
+  - taskId=`8da3600e-6084-11f1-8df9-5ad978d7f8ab`
+- 审批：
+  - `PUT /admin-api/bpm/task/approve`
+  - 返回 `code=0,data=true`
+- 回看：
+  - `GET /admin-api/business/accounting-adjust/prestorage-process`
+  - `resultStatus=SUCCESS`
+  - `approvalStatus=APPROVED`
+  - `writeBackStatus=UPDATED`
+  - `processState=UPDATED`
+  - `latestMessage=BPM审批通过后自动执行预存退款`
+- DB 断言：
+  - `biz_account(900001).deposit=90.00`
+  - `biz_prestorage_adjust.business_status=COMPLETED`
+  - `biz_prestorage_payment_relation` 写入 `payment_record_id=159`
+
+3. 预存转账：保存 -> BPM 审批 -> 自动执行 -> 查询回看
+- `POST /admin-api/business/accounting-adjust/prestorage-save`
+- 请求核心字段：
+  - `custCode=REV004_IT_SRC`
+  - `targetCustCode=REV004_IT_TGT`
+  - `transferAmount=30.00`
+  - `applicant=接口闭环转账人`
+  - `attachmentRefs=[real-api-transfer-proof]`
+- 保存返回：
+  - `adjustmentNo=REV004-PTR-900001-20260605102121`
+  - `resultStatus=PENDING_APPROVAL`
+  - `approvalStatus=PENDING_APPROVAL`
+  - `writeBackStatus=PENDING`
+  - `resultObjectNo=3e231762-6085-11f1-8df9-5ad978d7f8ab`
+- BPM 审批：
+  - taskId=`3e2401cb-6085-11f1-8df9-5ad978d7f8ab`
+  - `PUT /admin-api/bpm/task/approve` 返回 `code=0,data=true`
+- 回看：
+  - `GET /admin-api/business/accounting-adjust/prestorage-process`
+  - `resultStatus=SUCCESS`
+  - `approvalStatus=APPROVED`
+  - `writeBackStatus=UPDATED`
+  - `latestMessage=BPM审批通过后自动执行预存转账`
+  - `prestorage-page` 中 `workOrderStatus=2 / adjustmentType=2 / targetCustCode=REV004_IT_TGT / remainingAmount=60.00`
+- DB 断言：
+  - `biz_account(900001).deposit=60.00`
+  - `biz_account(900004).deposit=30.00`
+
+### 本次联调发现并处理的问题
+- 首次 BPM 审批退款失败，`/admin-api/bpm/task/approve` 返回 `code=500`
+- 服务端根因：
+  - `ERROR: relation "biz_prestorage_payment_relation_seq" does not exist`
+  - 表 DDL 使用 `BIGSERIAL`，实际 sequence 为 `biz_prestorage_payment_relation_id_seq`
+  - Java 实体 `PrestoragePaymentRelationDO` 原标注 `@KeySequence("biz_prestorage_payment_relation_seq")`
+- 临时环境修复：
+  - 远端库补齐兼容 sequence：`biz_prestorage_payment_relation_seq`
+- 代码修复：
+  - `PrestoragePaymentRelationDO` 改为 `@KeySequence("biz_prestorage_payment_relation_id_seq")`
+  - 新增 `PrestoragePaymentRelationSequenceContractTest` 锁定注解与 DDL sequence 名一致
+
+### 本次本地验证
+- `mvn -pl sw-business/sw-business-server -am -DskipTests compile`
+  - 结果：BUILD SUCCESS
+- `javap` 反射核验：
+  - `PrestoragePaymentRelationDO` 当前产物中的 `@KeySequence` 为 `biz_prestorage_payment_relation_id_seq`
+- 受既有测试编译问题影响，单测命令 `mvn -pl sw-business/sw-business-server -Dtest=PrestoragePaymentRelationSequenceContractTest test` 未能进入目标测试：
+  - 阻塞点：`MeterInOutServiceImplTest` 引用缺失的 `METER_IN_MODEL_CALIBER_MISMATCH` 与 `METER_IMPORT_MODEL_CALIBER_MISMATCH_MSG`
+
+### 2026-06-05 本地 targeted contract test 复核
+- 命令：
+  - `mvn -pl sw-business/sw-business-server -am -Dtest=CustServiceCircularDependencyContractTest,PrestoragePaymentRelationSequenceContractTest -Dsurefire.failIfNoSpecifiedTests=false test`
+- 结果：
+  - `BUILD SUCCESS`
+  - `CustServiceCircularDependencyContractTest`: 1 tests / 0 failures / 0 errors / 0 skipped
+  - `PrestoragePaymentRelationSequenceContractTest`: 1 tests / 0 failures / 0 errors / 0 skipped
+- 说明：
+  - `-Dsurefire.failIfNoSpecifiedTests=false` 用于 reactor 前置模块无匹配 `-Dtest` 用例时继续执行到 `sw-business-server`
+  - 本次复核覆盖四处 `CustService` 懒加载注入 contract 与 `biz_prestorage_payment_relation_id_seq` 注解 contract

docs/evidence/rev004-accounting/rev004-split-fixed-fee-first-child-2026-06-19.md

@@ -0,0 +1,46 @@
+# REV004 分账固定费用归属修复验证记录
+
+## 背景
+
+按水量分账采用连续阶梯重算后，`calculationMode=3` 的固定金额费用会在每个子账单重算一次，导致固定费用被重复收取。
+
+本次明确业务口径：按水量分账时，固定金额费用只归属第 1 个子账单，后续子账单该固定费用为 0。
+
+## 实现范围
+
+- 后端仓库：`../water-backend/`
+- 基线：`6156e47f8`
+- 验证日期：2026-06-19
+- 涉及文件：
+  - `sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/service/accountingadjust/trial/UnsoldTrialPreviewServiceImpl.java`
+  - `sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/service/accountingadjust/AccountingAdjustActionServiceImpl.java`
+  - `sw-business/sw-business-server/src/test/java/cn/com/emsoft/sw/business/service/accountingadjust/trial/UnsoldTrialPreviewServiceImplTest.java`
+  - `sw-business/sw-business-server/src/test/java/cn/com/emsoft/sw/business/service/accountingadjust/AccountingAdjustActionServiceImplTest.java`
+
+## 规则
+
+- 按水量分账继续按拆分顺序做连续阶梯重算。
+- 水价费用配置中 `calculationMode=3` 的固定金额费用：
+  - 第 1 个子账单取原账单对应费用金额。
+  - 第 2..N 个子账单置 0。
+- 正式回写时同步调整子账单费用明细，固定费用明细第 1 个子账单保留原金额，后续子账单清零。
+- 按费用组成分账不在本次范围内，保持原逻辑。
+
+## 验证
+
+执行命令：
+
+```bash
+mvn -pl sw-business/sw-business-server -am -Dtest=UnsoldTrialPreviewServiceImplTest,AccountingAdjustActionServiceImplTest -Dsurefire.failIfNoSpecifiedTests=false test
+```
+
+结果：
+
+- `UnsoldTrialPreviewServiceImplTest`：11 tests, 0 failures, 0 errors
+- `AccountingAdjustActionServiceImplTest`：19 tests, 0 failures, 0 errors
+- Reactor build：SUCCESS
+
+补充说明：
+
+- 初次仅使用 `-pl sw-business/sw-business-server` 执行时，因未同时构建 `sw-business-api` 依赖，命中本地依赖中的 `CustPriceChangeUpdateDTO` 缺失编译错误；改用 `-am` 后源码依赖正常参与构建。
+- `-am` 执行指定测试时，上游模块需要追加 `-Dsurefire.failIfNoSpecifiedTests=false`，避免上游模块没有匹配测试导致提前失败。

docs/evidence/rev005-invoice/2026-06-16-invoice-document-audit.md

@@ -0,0 +1,129 @@
+# REV-005 发票业务流 — 文档审计报告
+
+**审计日期**: 2026-06-16  
+**审计范围**: `water-docs/specs/002-rev005-invoice-flow/` + `docs/design/` 主文档 + `water-backend` 代码（worktree `backend-rev005`）  
+**审计目标**: 评估发票相关文档的完整性、一致性和可追溯性
+
+---
+
+## 1. 审计总览
+
+| 维度 | 结论 |
+|------|------|
+| 规格完整性 | ✅ 完备 |
+| 正式设计一致性 | ⚠️ 轻微偏差（状态定义 6 vs 4 态） |
+| 接口契约覆盖 | ✅ 完备 |
+| 数据模型覆盖 | ✅ 完备（正式版在 DB 设计中，specs 草稿已删除） |
+| 代码实现对应 | ✅ 59/65 任务完成，6 项为验证任务 |
+| 前端设计覆盖 | ✅ 有独立前端设计文档（866 行） |
+| 验证证据 | ❌ 8 项验证任务未完成 |
+
+---
+
+## 2. 文档地图
+
+```
+specs/002-rev005-invoice-flow/
+├── spec.md                      ✅ 有
+├── plan.md                      ✅ 有
+├── tasks.md                     ✅ 有（65 项，59 完成）
+├── research.md                  ✅ 有
+├── quickstart.md                ✅ 有
+├── verification.md              ⚠️ 有，但 8 个验证任务未完成
+└── frontend-finance-design.md   ✅ 有（2026-05-12 新增）
+
+docs/design/ (正式主文档)
+├── 02_Detailed_Design/12_REV_Detailed.md    ✅ REV-005 章节完整
+├── 03_Technical_Design/01_Database_Design.md ✅ biz_invoice 表覆盖
+└── 03_Technical_Design/03_Interface_Design.md ✅ IF-REV-008/009 定义完整
+
+docs/evidence/rev005-invoice/                📭 空（尚无证据入库）
+```
+
+---
+
+## 3. 发现
+
+### 3.1 状态定义差异（中风险）
+
+**问题**：`12_REV_Detailed.md` 定义了 6 个发票状态（`SUBMITTED`、`PENDING`、`SUCCESS`、`FAIL`、`INVALID`、`RED_INK`），但 `InvoiceController` 代码中实现了 `invalidate` 和 `red-ink` 两个独立端点，而 `InvoiceDO` 中的 `invoiceStatus` 字段是否支持这 6 态尚未在代码层确认。
+
+**影响**：作废/红冲是二期补齐的功能，需确认 `biz_invoice` 表的 `invoice_status` 枚举已包含 `INVALID` 和 `RED_INK`，否则运行时会抛异常。
+
+**建议**：检查 `InvoiceStatusEnum`（如存在）或 `biz_invoice` 的 DDL 确认枚举覆盖。
+
+### 3.2 验证证据缺失（低风险）
+
+`specs/002-rev005-invoice-flow/verification.md` 中 8 个验证任务未完成：
+
+| 编号 | 内容 | 阻塞点 |
+|------|------|--------|
+| T022 | 重复申请、部分开票拒绝的样本 | 需联调环境 |
+| T033 | SYS-008 不可用、超时等异常样本 | 需联调环境 |
+| T044 | 回写/查询/下载/推送成功率统计 | 需联调环境 |
+| T055 | 作废/红冲运行态日志样本 | 需联调环境 |
+| T060-T063 | SC-001~SC-004 性能指标采样 | 需测试环境 |
+
+**影响**：不影响功能实现，但会影响验收签字。
+
+**建议**：在提测前集中补齐，可安排在联调阶段同步采集。
+
+### 3.3 接口路径不一致（低风险）
+
+| 定义位置 | 路径 |
+|----------|------|
+| `specs/002/contracts/if-rev-008.md`（已删除） | `/api/invoice/apply`（假设） |
+| `03_Interface_Design.md` | `/business/invoice/apply` |
+| `InvoiceController.java` | `/business/invoice/apply`（`@RequestMapping("/business/invoice")` + `@PostMapping("/apply")`） |
+
+正式接口设计和代码实现路径一致（`/business/invoice/apply`）。specs 里的旧契约已删除，不存在冲突。✅ 无问题。
+
+### 3.4 前端设计文档状态（观察项）
+
+`frontend-finance-design.md` 是 2026-05-12 新增的，晚于主设计文档（2026-03-19）。它是独立于后端设计文档的前端实现补充，目前状态为"作为前端实现输入"。
+
+**影响**：`water-frontend` 尚未同步确认是否已按照此文档实现。
+
+**建议**：下一步在 `water-frontend` 的 AGENTS.md 或对应 spec 中确认前端实现进度。
+
+### 3.5 数据模型一致性（已解决）
+
+此前 `specs/002/` 存在独立的 `data-model.md` 和 `contracts/` 目录，与正式设计文档有内容重叠。本次审计已删除冗余草稿，数据模型以 `01_Database_Design.md` 为准，接口以 `03_Interface_Design.md` 为准。
+
+---
+
+## 4. FR 覆盖矩阵
+
+| FR | 描述 | 设计文档 | 代码 | 状态 |
+|----|------|---------|------|------|
+| FR-001 | 后台发票申请接口 | ✅ | ✅ `POST /apply` | 已实现 |
+| FR-002 | 校验账单状态 | ✅ | ✅ `InvoiceServiceImpl` | 已实现 |
+| FR-003 | 校验客户开票信息 | ✅ | ✅ | 已实现 |
+| FR-004 | 校验开票限额 | ⚠️ 设计中提及但未详细展开 | ❓ 待确认 | 部分 |
+| FR-005 | 生成发票申请记录 | ✅ | ✅ `biz_invoice_record` | 已实现 |
+| FR-006 | 调用 SYS-008 | ✅ | ✅ `InvoicePlatformClient` | 已实现 |
+| FR-007 | 定时查询兜底 | ✅ | ✅ `InvoiceCompensateJob` | 已实现 |
+| FR-008 | 更新发票状态 | ✅ | ✅ | 已实现 |
+| FR-009 | 发票-账单关联 | ✅ | ✅ `biz_charge_invoice_rel` | 已实现 |
+| FR-010 | 客户侧查询/下载/推送 | ✅ | ✅ 3 个端点 | 已实现 |
+| FR-011 | 操作日志 | ✅ | ⚠️ 部分方法有日志 | 部分 |
+| FR-012 | 作废入口 | ✅ | ✅ `POST /invalidate` | 已实现 |
+| FR-013 | 红冲入口 | ✅ | ✅ `POST /red-ink` | 已实现 |
+| FR-014 | 终态保护与结果回写 | ✅ | ✅ | 已实现 |
+
+**关键发现**：FR-004（开票限额）在设计文档中提及但未明确限额来源（配置表？固定值？），代码层待确认。FR-011（操作日志）在关键动作上有日志，但完整度待验证。
+
+---
+
+## 5. 建议优先级
+
+| 优先级 | 建议 |
+|--------|------|
+| **P0** | 确认 `biz_invoice` 的 `invoiceStatus` 枚举是否包含 `INVALID` 和 `RED_INK`，避免作废/红冲端点运行时报错 |
+| **P1** | 明确开票限额校验逻辑（FR-004）：从配置表读取还是硬编码，限额是单笔还是累计 |
+| **P1** | 联调阶段集中采集 T022/T033/T044/T055/T060-T063 的验证样本 |
+| **P2** | 确认 `water-frontend` 对 `frontend-finance-design.md` 的实现进度 |
+
+---
+
+审计结论：REV-005 发票业务流的文档体系基本完备，设计文档、接口契约、数据模型和代码实现高度对齐。主要风险点是作废/红冲状态枚举的代码层覆盖确认，以及 8 项验证样本的补充。

docs/evidence/revenue-bugfix-clear-scope-2026-06-08.md

@@ -1,101 +0,0 @@
-# 营收明确缺陷第一批修复验证记录
-
-日期：2026-06-08
-
-## 修复范围
-
-- #78 水价调整失败后重试闭环
-- #39 柜台预存缴费进入结账
-- #50 柜台结账收费员筛选
-- #53 预存抵扣校验
-- #58/#59 柜台红冲记录查询
-- #69/#76 待审批账务调整文案
-
-## 后端基线
-
-- 仓库：water-backend
-- Worktree：backend-revenue-bugfix-clear-scope
-- 提交：`ba136759b1925789cb0adc18105d00d6928add59`
-
-## 前端基线
-
-- 仓库：water-frontend
-- Worktree：frontend-revenue-bugfix-clear-scope
-- 提交：`5f7ad7754473541483b26efa324419eb7a5d1a3b`
-
-## 验证命令与结果
-
-### 后端 targeted tests
-
-```bash
-cd /Volumes/Dpan/github/water-workspace/worktrees/backend-revenue-bugfix-clear-scope
-mvn -pl sw-business/sw-business-server -Dtest=PriceTemplateServiceImplTest,PriceTemplateAdjustmentLockRedisDAOTest,CounterSettleApplicationServiceImplTest,ChargeServiceImplCounterPrepayTest test
-```
-
-结果：通过。
-
-- Surefire 汇总：`Tests run: 26, Failures: 0, Errors: 0, Skipped: 0`
-- Maven 结果：`BUILD SUCCESS`
-- 备注：执行期间存在既有 Maven model warning、Mockito dynamic-agent warning；`PriceTemplateServiceImplTest` 中有一段业务代码捕获后记录的 NPE 栈日志，但测试结果为 0 failures / 0 errors。
-
-### 后端 compile
-
-```bash
-cd /Volumes/Dpan/github/water-workspace/worktrees/backend-revenue-bugfix-clear-scope
-mvn -pl sw-business/sw-business-server -DskipTests compile
-```
-
-结果：通过。
-
-- Maven 结果：`BUILD SUCCESS`
-
-### 前端 contract test
-
-```bash
-cd /Volumes/Dpan/github/water-workspace/worktrees/frontend-revenue-bugfix-clear-scope
-node --test tests/revenue-bugs/revenueBugfixClearScope.contract.test.mjs
-```
-
-结果：通过。
-
-- Node test 汇总：`tests 5`, `pass 5`, `fail 0`
-
-### 前端 settings contract regression
-
-```bash
-cd /Volumes/Dpan/github/water-workspace/worktrees/frontend-revenue-bugfix-clear-scope
-node --test tests/settings/priceTemplateAdjustmentErrorHandling.test.mjs
-```
-
-结果：通过。
-
-- Node test 汇总：`tests 3`, `pass 3`, `fail 0`
-
-### 前端 type check
-
-```bash
-pnpm ts:check
-```
-
-结果：未完成，不作为通过项。
-
-- 首次执行长时间无诊断输出后以 `[ELIFECYCLE] Command failed.` 退出。
-- 随后按用户明确指令停止继续运行 `vue-tsc` / `pnpm ts:check`。
-- 已终止残留 `vue-tsc` 进程。
-
-### 前端 build
-
-```bash
-cd /Volumes/Dpan/github/water-workspace/worktrees/frontend-revenue-bugfix-clear-scope
-pnpm build:dev
-```
-
-结果：通过。
-
-- 输出：`Build successful. Please see dist directory`
-- 备注：构建期间存在既有 Vite CJS deprecation warning、SVG icon symbolId warning、Rollup PURE annotation warning。
-
-## 备注
-
-- 前端 worktree 中存在未跟踪 `test-results/*.png` 截图产物，本次未提交。
-- 本轮未处理 #70 和 #9。#70 需抓包确认提交字段；#9 需产品确认抄表状态规则。

docs/guides/SYSTEM_CAPABILITY_CLOSURE_MAP.md

@@ -328,7 +328,7 @@ REV-004 先统一账务状态、留痕、原交易校验口径
 
 - `specs/001-rev004-accounting/`
 - `specs/002-rev005-invoice-flow/`
-- `specs/003-rev006-reminder-event-design/`
+- `specs/003-rev003-rev006-reminder-event-design/`
 - `specs/004-rev007-revenue-statistics-design/`
 - `docs/design/00_Management/01_Project_Progress.md`
 - `docs/design/00_Management/03_Task_Checklist.md`

docs/superpowers/plans/2026-06-08-arrearage-reminder-frontend.md

@@ -0,0 +1,626 @@
+# 催缴登记 (Arrearage Reminder) 前端对接 Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 将两个前端页面（欠费催缴池 + 催缴记录）从 mock 数据切换到真实后端 API，包括 API 层补齐、催缴表单对接、汇总统计、导出功能。
+
+**Architecture:** 后端 9 个接口均已就绪 (`POST /create`, `GET /page`, `GET /pending-page`, `GET /get`, `GET /detail-list`, `POST /batch-create`, `GET /pending-summary`, `GET /pending-export`, `GET /pending-detail-export`)。前端按 "API 层 → 催缴表单 → 欠费池页面 → 催缴记录页面" 的顺序逐层对接，每层完成后可独立验证。
+
+**Tech Stack:** Vue 3, TypeScript, Element Plus, Axios (`@/config/axios`), pnpm
+
+---
+
+## File Structure
+
+### API layer
+- Modify: `../water-frontend/src/api/collectionManage/arrears/index.ts`
+  - 新增所有请求/响应 VO 类型 + 7 个缺失的 API 方法
+
+### Components
+- Modify: `../water-frontend/src/views/collectionManage/arrears/components/RemindForm.vue`
+  - 对接 `batchCreate` API，接收父组件传入的选中行数据
+
+### Views
+- Modify: `../water-frontend/src/views/collectionManage/arrears/index.vue`
+  - 汇总统计条对接 `getPendingSummary`、导出对接 `getPendingExportList`、催缴按钮传递选中数据给 RemindForm
+- Modify: `../water-frontend/src/views/collectionManage/collectionRecord/index.vue`
+  - 列表对接 `getPage`、详情展开对接 `getDetailList`、导出对接后端（如有对应接口）
+  - 查询表单字段对齐 `ArrearageReminderPageReqVO`
+
+---
+
+### Task 1: 补齐 API 层 — 类型定义与全部接口方法
+
+**Files:**
+- Modify: `../water-frontend/src/api/collectionManage/arrears/index.ts`
+
+- [ ] **Step 1: 添加所有 VO 类型定义和 API 方法**
+
+```typescript
+import request from '@/config/axios'
+import download from '@/utils/download'
+
+// ========== 请求 VO ==========
+
+export interface ArrearagePendingPageReqVO {
+  pageNo: number
+  pageSize: number
+  deptId?: number
+  code?: string
+  name?: string
+  address?: string
+  mobile?: string
+  custStates?: number[]
+  custType?: number
+  billMonthStart?: number
+  billMonthEnd?: number
+  meterReaderId?: number
+  bookCode?: string
+  arrearsCountMin?: number
+  arrearsCountMax?: number
+  arrearsAmountMin?: number
+  arrearsAmountMax?: number
+  remindFilter?: string
+}
+
+export interface ArrearageReminderPageReqVO {
+  pageNo: number
+  pageSize: number
+  custId?: number
+  reminderUser?: string
+  reminderType?: number
+  reminderReason?: number
+  reminderResult?: number
+}
+
+export interface ArrearageReminderCreateReqVO {
+  custId: number
+  chargeIds: number[]
+  reminderType: number
+  reminderReason: number
+  reminderResult: number
+  reminderUser: string
+  reminderTemplate?: number
+  remark?: string
+}
+
+export interface ArrearageReminderBatchCreateReqVO {
+  customers: {
+    custId: number
+    chargeIds: number[]
+  }[]
+  reminderType: number
+  reminderReason: number
+  reminderResult: number
+  reminderUser: string
+  reminderTemplate?: number
+  remark?: string
+}
+
+// ========== 响应 VO ==========
+
+export interface ArrearagePendingPageRespVO {
+  custId: number
+  custCode: string
+  custName: string
+  custAddress: string
+  meterCaliber: string
+  waterNature: string
+  arrearsCount: number
+  waterVolume: number
+  totalAmount: number
+  penaltyAmount: number
+  receivableAmount: number
+  billAmount: number
+  accountMonthRange: string
+  custStatus: string
+  prestoreAmount: number
+  mobile: string
+  isRemindedThisMonth: boolean
+  agreementNo: string
+  contractNo: string
+  details: ArrearagePendingChargeDetailRespVO[]
+}
+
+export interface ArrearagePendingChargeDetailRespVO {
+  chargeId: number
+  billMonth: string
+  lastReading: number
+  currentReading: number
+  waterVolume: number
+  billAmount: number
+  penaltyAmount: number
+  readingDate: string
+}
+
+export interface ArrearagePendingSummaryRespVO {
+  custCount: number
+  arrearsCount: number
+  waterVolume: number
+  billAmount: number
+  penaltyAmount: number
+  totalAmount: number
+  receivableAmount: number
+}
+
+export interface ArrearageReminderPageRespVO {
+  id: number
+  custId: number
+  custCode: string
+  custName: string
+  reminderType: number
+  reminderReason: number
+  reminderUser: string
+  remark: string
+  reminderTemplate: number
+  completeTime: string
+  pushState: number
+  pushResults: string
+  reminderResult: number
+  batchStamp: string
+  totalBillWater: number
+  totalExtendedAmount: number
+  totalLateFee: number
+  deposit: number
+  mobile: string
+  createTime: string
+  updateTime: string
+}
+
+export interface ArrearageReminderRespVO extends ArrearageReminderPageRespVO {}
+
+export interface ArrearageReminderDetailRespVO {
+  id: number
+  arrearageReminderId: number
+  chargeId: number
+  lateFee: number
+  createTime: string
+  updateTime: string
+}
+
+export interface ArrearageReminderCreateRespVO {
+  id: number
+  detailCount: number
+}
+
+export interface ArrearageReminderBatchCreateRespVO {
+  successCount: number
+  failCount: number
+  successItems: { custId: number; reminderId: number; detailCount: number }[]
+  failItems: { custId: number; reason: string }[]
+}
+
+// ========== API 方法 ==========
+
+export const ArrearsApi = {
+  // 待催欠费池
+  getPendingPage: async (params: ArrearagePendingPageReqVO) => {
+    return await request.get<{ list: ArrearagePendingPageRespVO[]; total: number }>({
+      url: '/business/arrearage-reminder/pending-page',
+      params
+    })
+  },
+
+  getPendingSummary: async (params: ArrearagePendingPageReqVO) => {
+    return await request.get<ArrearagePendingSummaryRespVO>({
+      url: '/business/arrearage-reminder/pending-summary',
+      params
+    })
+  },
+
+  // 催缴登记 CRUD
+  create: async (data: ArrearageReminderCreateReqVO) => {
+    return await request.post<ArrearageReminderCreateRespVO>({
+      url: '/business/arrearage-reminder/create',
+      data
+    })
+  },
+
+  batchCreate: async (data: ArrearageReminderBatchCreateReqVO) => {
+    return await request.post<ArrearageReminderBatchCreateRespVO>({
+      url: '/business/arrearage-reminder/batch-create',
+      data
+    })
+  },
+
+  getPage: async (params: ArrearageReminderPageReqVO) => {
+    return await request.get<{ list: ArrearageReminderPageRespVO[]; total: number }>({
+      url: '/business/arrearage-reminder/page',
+      params
+    })
+  },
+
+  get: async (id: number) => {
+    return await request.get<ArrearageReminderRespVO>({
+      url: '/business/arrearage-reminder/get',
+      params: { id }
+    })
+  },
+
+  getDetailList: async (reminderId: number) => {
+    return await request.get<ArrearageReminderDetailRespVO[]>({
+      url: '/business/arrearage-reminder/detail-list',
+      params: { reminderId }
+    })
+  },
+
+  // 导出
+  exportPending: async (params: ArrearagePendingPageReqVO) => {
+    const res = await request.download({
+      url: '/business/arrearage-reminder/pending-export',
+      params
+    })
+    download.response(res, '待催欠费客户.xlsx')
+  },
+
+  exportPendingDetail: async (params: ArrearagePendingPageReqVO) => {
+    const res = await request.download({
+      url: '/business/arrearage-reminder/pending-detail-export',
+      params
+    })
+    download.response(res, '待催欠费明细.xlsx')
+  }
+}
+```
+
+- [ ] **Step 2: 验证 API 层编译**
+
+Run: `cd ../water-frontend && npx vue-tsc --noEmit src/api/collectionManage/arrears/index.ts 2>&1 | head -20`
+Expected: No type errors
+
+---
+
+### Task 2: RemindForm 对接 batchCreate API
+
+**Files:**
+- Modify: `../water-frontend/src/views/collectionManage/arrears/components/RemindForm.vue`
+
+- [ ] **Step 1: 重写 RemindForm 脚本，接收选中行 props 并调 batchCreate**
+
+将 `<script setup lang="ts">` 段替换为：
+
+```typescript
+import { ArrearsApi } from '@/api/collectionManage/arrears'
+
+const message = useMessage()
+const dialogVisible = ref(false)
+const formRef = ref()
+
+const props = defineProps<{
+  selectedRows: any[]
+}>()
+
+// reminderType 映射: '催缴单'->1, '短信'->2, '电话'->3, '微信'->4, '其它'->5, '热线'->6
+const methodMap: Record<string, number> = {
+  '催缴单': 1, '短信': 2, '电话': 3, '微信': 4, '其它': 5, '热线': 6
+}
+
+const formData = ref({
+  method: '催缴单',
+  operator: '',
+  reason: '',
+  remark: ''
+})
+
+const rules = {
+  method: [{ required: true, message: '请选择催缴方式', trigger: 'change' }],
+  operator: [{ required: true, message: '请选择催缴人员', trigger: 'change' }],
+  reason: [{ required: true, message: '请选择催缴原因', trigger: 'change' }]
+}
+
+const open = () => {
+  dialogVisible.value = true
+  formData.value = {
+    method: '催缴单',
+    operator: '',
+    reason: '',
+    remark: ''
+  }
+}
+
+const submitForm = async () => {
+  if (!formRef.value) return
+  await formRef.value.validate(async (valid: boolean) => {
+    if (!valid) return
+    try {
+      const customers = props.selectedRows.map((row: any) => ({
+        custId: row.custId,
+        chargeIds: row.details?.map((d: any) => d.chargeId) || []
+      }))
+      const res = await ArrearsApi.batchCreate({
+        customers,
+        reminderType: methodMap[formData.value.method] || 1,
+        reminderReason: Number(formData.value.reason),
+        reminderResult: 0,
+        reminderUser: formData.value.operator,
+        remark: formData.value.remark
+      })
+      if (res.failCount > 0) {
+        const failMsgs = res.failItems.map((f: any) => `客户${f.custId}: ${f.reason}`).join('; ')
+        message.warning(`成功 ${res.successCount} 条，失败 ${res.failCount} 条。${failMsgs}`)
+      } else {
+        message.success(`成功创建 ${res.successCount} 条催缴记录`)
+      }
+      dialogVisible.value = false
+      emit('success')
+    } catch (e: any) {
+      message.error(e?.message || '催缴失败')
+    }
+  })
+}
+
+const emit = defineEmits(['success'])
+defineExpose({ open })
+```
+
+- [ ] **Step 2: 修改父组件传参 — 更新 arrears/index.vue 中 RemindForm 的使用**
+
+在 `../water-frontend/src/views/collectionManage/arrears/index.vue` 底部模板中：
+
+```
+<!-- 修改前 -->
+<RemindForm ref="remindFormRef" @success="handleSuccess" />
+
+<!-- 修改后 -->
+<RemindForm ref="remindFormRef" :selected-rows="selectedRows" @success="handleSuccess" />
+```
+
+- [ ] **Step 3: 验证编译**
+
+Run: `cd ../water-frontend && npx vue-tsc --noEmit 2>&1 | tail -20`
+Expected: No type errors (may have pre-existing errors in other files, check only arrearage-related)
+
+---
+
+### Task 3: 欠费催缴池页面 — 汇总统计 + 导出 + 全选催缴
+
+**Files:**
+- Modify: `../water-frontend/src/views/collectionManage/arrears/index.vue`
+
+- [ ] **Step 1: 添加汇总统计数据获取**
+
+在 `getList` 调用后追加 summary 请求。找到 `script setup` 中的 `getList` 函数（约 line 629），在其后添加：
+
+```typescript
+const summary = ref<{
+  custCount: number
+  arrearsCount: number
+  waterVolume: number
+  billAmount: number
+  penaltyAmount: number
+  totalAmount: number
+  receivableAmount: number
+}>({
+  custCount: 0, arrearsCount: 0, waterVolume: 0,
+  billAmount: 0, penaltyAmount: 0, totalAmount: 0, receivableAmount: 0
+})
+
+const fetchSummary = async () => {
+  try {
+    summary.value = await ArrearsApi.getPendingSummary(buildPageParams())
+  } catch {
+    // summary stays at zero
+  }
+}
+```
+
+修改 `handleQuery` 和 `onMounted` 中的 `getList()` 调用为并行：
+
+```typescript
+const handleQuery = () => {
+  queryParams.pageNo = 1
+  Promise.all([getList(), fetchSummary()])
+}
+```
+
+并在 `onMounted` 中：
+
+```typescript
+onMounted(async () => {
+  await Promise.resolve(getSiteTree())
+  await Promise.all([getList(), fetchSummary()])
+})
+```
+
+- [ ] **Step 2: 替换模板中的硬编码统计值为真实数据**
+
+找到 `<el-descriptions>` 区域（约 line 211-226），替换其中各 `el-descriptions-item` 的值为 `summary` 响应式数据：
+
+```html
+<el-descriptions :column="5" class="mt-15px mb-8px" border label-width="120">
+  <el-descriptions-item label="客户数">
+    <span class="text-orange-500 font-bold">{{ summary.custCount }}</span>
+  </el-descriptions-item>
+  <el-descriptions-item label="欠费笔数">
+    <span class="text-orange-500 font-bold">{{ summary.arrearsCount }}</span>
+  </el-descriptions-item>
+  <el-descriptions-item label="用水量">
+    <span class="text-orange-500 font-bold">{{ summary.waterVolume }}</span>
+  </el-descriptions-item>
+  <el-descriptions-item label="合计金额">
+    <span class="text-orange-500 font-bold">¥{{ summary.totalAmount }}</span>
+  </el-descriptions-item>
+  <el-descriptions-item label="账单金额">
+    <span class="text-orange-500 font-bold">¥{{ summary.billAmount }}</span>
+  </el-descriptions-item>
+  <el-descriptions-item label="违约金">
+    <span class="text-orange-500 font-bold">¥{{ summary.penaltyAmount }}</span>
+  </el-descriptions-item>
+  <el-descriptions-item label="应缴金额">
+    <span class="text-orange-500 font-bold">¥{{ summary.receivableAmount }}</span>
+  </el-descriptions-item>
+</el-descriptions>
+```
+
+- [ ] **Step 3: 导出对接真实 API**
+
+找到 `handleExport` 函数（约 line 663），替换为：
+
+```typescript
+const handleExport = async () => {
+  try {
+    message.loading('正在导出...')
+    await ArrearsApi.exportPending(buildPageParams())
+    message.success('导出成功')
+  } catch {
+    message.error('导出失败')
+  }
+}
+```
+
+- [ ] **Step 4: 全部催缴传参**
+
+找到 `handleRemindAll`（约 line 657），当前直接 `remindFormRef.value.open()`，需要传入当前列表中所有行的数据。修改为：
+
+```typescript
+const handleRemindAll = () => {
+  selectedRows.value = list.value
+  remindFormRef.value.open()
+}
+```
+
+- [ ] **Step 5: 从 API 导入汇总相关方法**
+
+在 `arrears/index.vue` 的 import 中，`ArrearsApi` 的导入行保持不变（当前已导入），新增 `summary` ref 定义的位置放到 `selectedRows` 附近。
+
+- [ ] **Step 6: 验证编译**
+
+Run: `cd ../water-frontend && npx vue-tsc --noEmit 2>&1 | tail -20`
+Expected: No new type errors from arrears files
+
+---
+
+### Task 4: 催缴记录页面 — 列表与详情对接
+
+**Files:**
+- Modify: `../water-frontend/src/views/collectionManage/collectionRecord/index.vue`
+
+- [ ] **Step 1: 添加 API 导入**
+
+在 script setup 顶部 import 中加入：
+
+```typescript
+import { ArrearsApi } from '@/api/collectionManage/arrears'
+```
+
+- [ ] **Step 2: 添加详情数据 ref 和获取方法**
+
+在 `list` ref 附近（约 line 294）追加：
+
+```typescript
+const detailMap = ref<Record<number, any[]>>({})
+
+const fetchDetailList = async (reminderId: number) => {
+  if (detailMap.value[reminderId]) return
+  try {
+    const details = await ArrearsApi.getDetailList(reminderId)
+    detailMap.value[reminderId] = details
+  } catch {
+    detailMap.value[reminderId] = []
+  }
+}
+```
+
+- [ ] **Step 3: 替换 getList 为真实 API 调用**
+
+找到现有的 getList 函数（当前为 mock 数据），替换为：
+
+```typescript
+const getList = async () => {
+  loading.value = true
+  try {
+    const data = await ArrearsApi.getPage({
+      pageNo: queryParams.pageNo,
+      pageSize: queryParams.pageSize,
+      custId: undefined, // 后续可扩展
+      reminderUser: queryParams.remindUser || undefined,
+      reminderType: undefined,
+      reminderReason: queryParams.remindReason ? Number(queryParams.remindReason) : undefined,
+      reminderResult: queryParams.remindResult ? Number(queryParams.remindResult) : undefined
+    })
+    list.value = (data?.list || []).map((item: any) => ({
+      ...item,
+      id: item.id,
+      deptName: item.deptName || '-',
+      custCode: item.custCode,
+      custName: item.custName,
+      custAddress: item.custAddress || '-',
+      remindUser: item.reminderUser,
+      remindMethod: item.reminderType,
+      remindReason: item.reminderReason,
+      mobile: item.mobile,
+      arrearsCount: 0, // reminder records don't carry count — fetched via details
+      arrearsWaterVolume: item.totalBillWater,
+      arrearsAmount: item.totalExtendedAmount,
+      penaltyAmount: item.totalLateFee,
+      prestoreBalance: item.deposit,
+      completeDate: item.completeTime,
+      registerDate: item.createTime,
+      remark: item.remark,
+      expanded: false,
+      pushStatus: item.pushState,
+      details: []
+    }))
+    total.value = data?.total || 0
+  } finally {
+    loading.value = false
+  }
+}
+```
+
+- [ ] **Step 4: 展开行对接详情**
+
+找到模板中的 expand slot（当前显示 mock 数据 `detailsMock1`），替换为绑定 `detailMap`：
+
+```html
+<template #expand="scope">
+  <div class="p-20px bg-gray-50">
+    <el-table
+      :data="detailMap[scope.row.id] || []"
+      border
+      style="width: 100%"
+      v-loading="!detailMap[scope.row.id]"
+    >
+      <el-table-column prop="chargeId" label="账单ID" width="120" />
+      <el-table-column prop="lateFee" label="违约金" width="120" />
+      <el-table-column prop="createTime" label="创建时间" width="180" />
+    </el-table>
+  </div>
+</template>
+```
+
+- [ ] **Step 5: 展开事件触发详情加载**
+
+在 `handleExpandChange` 中调用 `fetchDetailList`：
+
+```typescript
+const handleExpandChange = (row: any, expandedRows: any[]) => {
+  row.expanded = expandedRows.includes(row)
+  if (row.expanded) {
+    fetchDetailList(row.id)
+  }
+}
+```
+
+- [ ] **Step 6: 删除 mock 数据**
+
+删除文件中的 `detailsMock1` 等 mock 数据声明。
+
+- [ ] **Step 7: 验证编译**
+
+Run: `cd ../water-frontend && npx vue-tsc --noEmit 2>&1 | tail -20`
+Expected: No new type errors
+
+---
+
+## Verification Checklist
+
+完成所有 4 个 Task 后，执行端到端 smoke：
+
+- [ ] `npx vue-tsc --noEmit` 编译通过
+- [ ] 欠费催缴池页面：汇总统计数字不再是硬编码
+- [ ] 欠费催缴池页面：点击"导出"触发 `GET /pending-export` 下载 xlsx
+- [ ] 欠费催缴池页面：勾选客户 → 点击"选中催缴" → 弹窗填写 → 提交 → 调 `POST /batch-create`
+- [ ] 欠费催缴池页面：点击"全部催缴"将当前列表全部行传入 RemindForm
+- [ ] 催缴记录页面：列表从 `GET /page` 加载，查询条件生效
+- [ ] 催缴记录页面：展开行从 `GET /detail-list` 加载账单明细

docs/superpowers/plans/2026-06-08-revenue-bugfix-clear-scope-acceptance-test.md

@@ -0,0 +1,673 @@
+# Revenue Bugfix Clear Scope Acceptance Test Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 为营收明确缺陷第一批修复提供一份可交给测试人员执行的业务验收用例计划。
+
+**Architecture:** 本计划按缺陷编号拆分验收场景，每个场景包含前置条件、操作步骤、期望结果和证据要求。验收不绑定具体测试工具，测试人员可通过浏览器页面、业务后台、数据库只读查询或接口日志完成证据采集。
+
+**Tech Stack:** 福建水务营收系统、营收后台页面、柜台收费、柜台结账、红冲记录、水价模板、账务调整审批流程。
+
+---
+
+## 适用范围
+
+本计划对应 `docs/superpowers/specs/2026-06-08-revenue-bugfix-clear-scope-design.md` 中纳入本轮的缺陷：
+
+- `#78` 水价调整：执行报错后，用户不应只能关闭菜单从头开始。
+- `#39` 柜台结账：柜台预存缴费记录应能进入待结清并完成结账。
+- `#50` 柜台结账：收费员筛选不应被后端无条件覆盖为当前登录用户。
+- `#53` 柜台收费：预存抵扣金额需要前后端契约保护和回归验证。
+- `#58/#59` 红冲记录：柜台红冲后应能在红冲记录页按红冲时间查到。
+- `#69/#76` 未销分账、呆坏账、价差调整、违约金减免：前端应准确表达“申请已提交，待审批/待回写”，不得提示为已生效。
+
+以下问题不纳入本次验收：
+
+- `#70` 未销调整提示成功但账单未变。
+- `#9` 抄表状态修改无影响。
+
+## 验收环境要求
+
+- 使用已经部署本轮前后端修复的测试环境。
+- 测试账号至少包含：
+  - 管理员账号：可查看全部收费员数据，可执行水价调整、柜台结账、红冲记录查询。
+  - 收费员 A：可进行柜台收费、预存充值、柜台结账。
+  - 收费员 B：可进行柜台收费或预存充值，用于验证收费员筛选。
+  - 审批相关账号：可查看账务调整提交后的待审批记录。
+- 所有测试数据应使用测试客户，不使用生产客户。
+- 每个用例执行前记录测试时间、测试账号、客户编号、业务单号、页面截图或后台记录。
+
+## 测试数据准备
+
+- 客户 C1：存在正常水表、正常用水性质、可生成账单，账户预存余额为 0。
+- 客户 C2：存在正常水表和未结清账单，账户预存余额大于 0，余额小于或等于选中账单应收金额。
+- 客户 C3：存在正常水表和未结清账单，账户预存余额大于选中账单应收金额。
+- 客户 C4：用于柜台预存充值，不要求存在当月未结清账单。
+- 客户 C5：用于账务调整申请，存在可分账、可呆坏账、可价差调整或可违约金减免的历史账单。
+- 收费员 A 和收费员 B 分别产生至少一笔柜台收费或预存充值记录。
+- 柜台结账测试前确认存在未结账记录，红冲测试前确认存在已结账记录。
+
+## 验收通过标准
+
+- 所有 P0 和 P1 用例通过。
+- P2 用例不出现阻断主流程的问题。
+- 每个缺陷编号至少有一条正向用例和一条异常或边界用例完成验证。
+- 页面提示、列表数据、业务记录三类证据能够互相印证。
+- 若出现失败，必须记录缺陷编号、操作步骤、输入数据、期望结果、实际结果和证据截图。
+
+---
+
+### Task 1: #78 水价调整失败恢复验收
+
+**覆盖目标：** 水价调整提交失败后，用户能看到明确错误，并可继续在当前页面修正后重新提交，不需要关闭菜单或重新进入页面。
+
+- [ ] **Step 1: 准备水价调整测试数据**
+
+前置条件：
+
+- 使用管理员账号登录。
+- 进入“设置 / 价格 / 水价模板”页面。
+- 选择一个允许调价的水价模板。
+- 记录模板名称、模板编号、当前生效水价。
+
+通过标准：
+
+- 页面能进入水价模板详情。
+- 页面存在“开始调价”或等价操作入口。
+
+- [ ] **Step 2: 验证开始调价失败提示**
+
+操作步骤：
+
+1. 使用账号 A 进入水价模板并点击“开始调价”。
+2. 保持账号 A 不提交调价。
+3. 使用账号 B 进入同一租户同一水价模板并点击“开始调价”。
+
+期望结果：
+
+- 账号 B 不应静默失败。
+- 页面应提示锁被占用、当前不可调价或等价业务错误。
+- 账号 B 页面不应进入可编辑调价态。
+- 账号 A 的调价状态不被账号 B 破坏。
+
+证据要求：
+
+- 账号 B 错误提示截图。
+- 账号 A 仍处于调价态的截图。
+
+- [ ] **Step 3: 验证提交失败后可继续修正**
+
+操作步骤：
+
+1. 使用账号 A 在调价态修改一个价格项。
+2. 构造一条业务不允许提交的数据，例如价格为空、价格为负数、必填项缺失，或使用环境中已知会被后端拒绝的调价数据。
+3. 点击提交。
+4. 查看失败提示。
+5. 在不关闭菜单、不刷新浏览器、不重新进入页面的情况下，把错误字段修正为合法值。
+6. 再次点击提交。
+
+期望结果：
+
+- 第一次提交失败时，页面显示明确失败原因。
+- 页面仍保留在可继续处理的状态，用户能继续修改表单。
+- 第二次提交成功后，页面提示调价成功或进入后续审批状态。
+- 调价结果在水价模板详情中可见，或能看到对应待审批记录。
+
+证据要求：
+
+- 第一次失败提示截图。
+- 修正后再次提交成功截图。
+- 成功后的水价模板详情或审批记录截图。
+
+- [ ] **Step 4: 验证取消调价失败提示**
+
+操作步骤：
+
+1. 进入水价模板调价态。
+2. 点击“取消调价”。
+3. 如环境支持模拟失败，触发取消失败；如不支持模拟失败，则在网络异常或锁失效条件下验证。
+
+期望结果：
+
+- 取消失败时页面显示明确失败原因。
+- 页面不应出现无提示、按钮无响应或调试信息外露。
+
+证据要求：
+
+- 取消失败提示截图，或说明当前环境无法制造取消失败但正常取消路径通过。
+
+---
+
+### Task 2: #39 柜台预存缴费进入待结清并完成结账验收
+
+**覆盖目标：** 柜台预存充值记录能出现在柜台结账待结清列表，并可被结账确认。
+
+- [ ] **Step 1: 创建柜台预存充值记录**
+
+前置条件：
+
+- 使用收费员 A 登录。
+- 选择客户 C4。
+- 客户 C4 当前无未结账预存充值记录，或记录本次充值前的未结账数量。
+
+操作步骤：
+
+1. 进入“柜台收费”或预存充值入口。
+2. 为客户 C4 办理一笔预存充值，金额使用 `100.00` 元。
+3. 完成支付。
+4. 记录缴费单号、客户编号、充值金额、收费员、缴费时间。
+
+期望结果：
+
+- 预存充值成功。
+- 系统生成柜台缴费记录。
+- 该记录未被标记为已结账。
+
+证据要求：
+
+- 充值成功页面或缴费记录截图。
+- 单号、金额、收费员、时间。
+
+- [ ] **Step 2: 查询柜台结账待结清列表**
+
+操作步骤：
+
+1. 使用收费员 A 或管理员进入“柜台结账”页面。
+2. 查询未结账记录。
+3. 使用客户 C4、收费员 A 或缴费时间范围筛选。
+
+期望结果：
+
+- 客户 C4 的 `100.00` 元预存充值记录出现在待结清列表。
+- 记录金额、客户、收费员、缴费时间正确。
+- 若该记录没有账单月份、收费单号或营业账 ID，页面显示 `--` 或空值占位，不应显示 `undefined`、`null`、报错或导致整行无法选择。
+
+证据要求：
+
+- 待结清列表截图。
+- 可见客户、金额、收费员、缴费时间、空值占位。
+
+- [ ] **Step 3: 完成预存充值记录结账**
+
+操作步骤：
+
+1. 在待结清列表选择客户 C4 的预存充值记录。
+2. 点击结账或确认结账。
+3. 核对结账汇总金额为 `100.00` 元。
+4. 确认提交。
+
+期望结果：
+
+- 结账成功。
+- 结账汇总金额包含该预存充值金额。
+- 结账后该记录不再出现在待结清列表。
+- 已结账记录中能查询到对应结账单。
+
+证据要求：
+
+- 结账确认弹窗或确认页截图。
+- 结账成功截图。
+- 结账后待结清列表无该记录截图。
+- 已结账记录或结账单详情截图。
+
+---
+
+### Task 3: #50 柜台结账收费员筛选验收
+
+**覆盖目标：** 柜台结账查询在指定收费员时按指定收费员查询，不被强制覆盖为当前登录用户。
+
+- [ ] **Step 1: 准备两个收费员的未结账记录**
+
+操作步骤：
+
+1. 使用收费员 A 产生一笔柜台收费或预存充值未结账记录。
+2. 使用收费员 B 产生一笔柜台收费或预存充值未结账记录。
+3. 记录两笔记录的客户、金额、收费员、缴费时间。
+
+期望结果：
+
+- 收费员 A 和收费员 B 各有至少一笔未结账记录。
+- 两笔记录可通过客户或时间区分。
+
+证据要求：
+
+- 两笔未结账记录的业务单据或列表截图。
+
+- [ ] **Step 2: 管理员按收费员 A 查询**
+
+操作步骤：
+
+1. 使用管理员进入“柜台结账”页面。
+2. 筛选收费员为收费员 A。
+3. 点击查询。
+
+期望结果：
+
+- 列表显示收费员 A 的未结账记录。
+- 列表不混入收费员 B 的记录。
+- 页面筛选条件保持为收费员 A。
+
+证据要求：
+
+- 查询条件和结果列表同屏截图。
+
+- [ ] **Step 3: 管理员按收费员 B 查询**
+
+操作步骤：
+
+1. 保持管理员账号。
+2. 将收费员筛选改为收费员 B。
+3. 点击查询。
+
+期望结果：
+
+- 列表显示收费员 B 的未结账记录。
+- 列表不再显示收费员 A 的记录。
+- 系统没有把筛选条件改回管理员或当前登录用户。
+
+证据要求：
+
+- 查询条件和结果列表同屏截图。
+
+- [ ] **Step 4: 不选择收费员时验证默认规则**
+
+操作步骤：
+
+1. 使用收费员 A 登录。
+2. 进入“柜台结账”页面。
+3. 不选择收费员，直接查询未结账记录。
+
+期望结果：
+
+- 若系统规则为普通收费员默认查本人，则列表只显示收费员 A 的记录。
+- 页面不应显示其他收费员数据，除非当前账号被配置为可查看全部收费员。
+
+证据要求：
+
+- 登录账号信息和查询结果截图。
+
+---
+
+### Task 4: #53 柜台收费预存抵扣验收
+
+**覆盖目标：** 预存抵扣金额受预存余额和账单应收限制，合法抵扣能扣减余额并写入支付记录，非法抵扣有明确提示。
+
+- [ ] **Step 1: 验证预存余额为 0 时开启抵扣**
+
+前置条件：
+
+- 客户 C1 存在未结清账单。
+- 客户 C1 预存余额为 `0.00`。
+
+操作步骤：
+
+1. 进入“柜台收费”页面。
+2. 查询客户 C1。
+3. 选择一笔或多笔未结清账单。
+4. 开启预存抵扣。
+5. 尝试提交收费。
+
+期望结果：
+
+- 系统提示当前可抵扣金额为 0，或要求确认不使用预存抵扣继续收费。
+- 未经确认不应直接提交收费。
+- 若确认继续，应按普通支付金额完成收费，不应产生预存扣减。
+
+证据要求：
+
+- 预存余额为 0 的页面截图。
+- 提示或确认弹窗截图。
+- 最终收费记录截图。
+
+- [ ] **Step 2: 验证抵扣金额小于账单应收**
+
+前置条件：
+
+- 客户 C2 存在未结清账单，应收金额大于预存余额。
+- 客户 C2 预存余额记录为 `B` 元，选中账单应收合计记录为 `R` 元，满足 `0 < B < R`。
+
+操作步骤：
+
+1. 查询客户 C2。
+2. 选择账单应收合计为 `R` 的账单。
+3. 开启预存抵扣。
+4. 确认页面计算抵扣金额为 `B`，剩余应付金额为 `R - B`。
+5. 完成收费。
+6. 查询客户 C2 账户余额和支付记录。
+
+期望结果：
+
+- 抵扣金额不超过预存余额。
+- 抵扣金额不超过账单应收合计。
+- 支付成功后客户预存余额扣减为 `0.00`。
+- 支付记录中能看到预存抵扣金额为 `B`，或业务明细中能证明本次抵扣 `B`。
+
+证据要求：
+
+- 收费前余额和应收金额截图。
+- 收费确认金额截图。
+- 收费成功后余额截图。
+- 支付记录或业务明细截图。
+
+- [ ] **Step 3: 验证预存余额大于账单应收**
+
+前置条件：
+
+- 客户 C3 存在未结清账单。
+- 客户 C3 预存余额记录为 `B` 元，选中账单应收合计记录为 `R` 元，满足 `B > R > 0`。
+
+操作步骤：
+
+1. 查询客户 C3。
+2. 选择应收合计为 `R` 的账单。
+3. 开启预存抵扣。
+4. 完成收费。
+5. 查询客户 C3 账户余额和支付记录。
+
+期望结果：
+
+- 抵扣金额为 `R`，不得超过账单应收合计。
+- 本次实际支付金额为 `0.00` 或无需额外现金支付，按页面规则展示。
+- 收费成功后客户预存余额为 `B - R`。
+- 支付记录保留本次预存抵扣金额 `R`。
+
+证据要求：
+
+- 收费确认页截图。
+- 收费成功后余额截图。
+- 支付记录或业务明细截图。
+
+- [ ] **Step 4: 验证非法抵扣金额被拒绝**
+
+操作步骤：
+
+1. 在可操作环境中尝试提交超过预存余额的抵扣金额。
+2. 在可操作环境中尝试提交超过账单应收合计的抵扣金额。
+3. 在可操作环境中尝试提交负数抵扣金额。
+
+期望结果：
+
+- 三类非法金额均被拒绝。
+- 页面或后端返回明确错误原因。
+- 客户余额、账单状态、支付记录不发生错误变更。
+
+证据要求：
+
+- 每类非法输入的错误提示截图。
+- 验证余额和账单状态未变的截图。
+
+---
+
+### Task 5: #58/#59 柜台红冲记录验收
+
+**覆盖目标：** 柜台结账红冲后，红冲记录页能按红冲时间查询到记录，并展示柜台红冲业务字段。
+
+- [ ] **Step 1: 准备已结账记录**
+
+操作步骤：
+
+1. 使用收费员 A 完成一笔柜台收费或预存充值。
+2. 在“柜台结账”中完成结账。
+3. 记录结账单号、客户、收费员、结账金额、结账时间。
+
+期望结果：
+
+- 存在一笔可红冲的已结账记录。
+
+证据要求：
+
+- 结账单详情截图。
+
+- [ ] **Step 2: 执行柜台红冲**
+
+操作步骤：
+
+1. 进入已结账记录或结账单详情。
+2. 对 Step 1 的结账记录执行红冲。
+3. 填写红冲原因，例如“验收测试红冲”。
+4. 提交红冲。
+5. 记录红冲时间、红冲金额、红冲原因。
+
+期望结果：
+
+- 红冲成功。
+- 原结账记录状态变为部分红冲或全部红冲。
+- 系统生成红冲记录。
+
+证据要求：
+
+- 红冲提交页面截图。
+- 红冲成功提示截图。
+- 原结账记录状态截图。
+
+- [ ] **Step 3: 按红冲时间查询红冲记录**
+
+操作步骤：
+
+1. 进入“红冲记录”页面。
+2. 设置红冲时间范围，开始时间早于 Step 2 的红冲时间，结束时间晚于 Step 2 的红冲时间。
+3. 点击查询。
+
+期望结果：
+
+- 列表能查询到 Step 2 产生的红冲记录。
+- 查询条件标签应表达为“红冲时间”或等价语义。
+- 返回记录展示结账单号、收费员、客户、红冲金额、红冲时间、红冲原因。
+- 红冲金额与 Step 2 记录一致。
+
+证据要求：
+
+- 查询条件和结果列表同屏截图。
+
+- [ ] **Step 4: 验证红冲时间范围边界**
+
+操作步骤：
+
+1. 将查询开始时间设置为红冲时间之后。
+2. 点击查询。
+3. 将查询结束时间设置为红冲时间之前。
+4. 点击查询。
+5. 将查询时间范围重新覆盖红冲时间。
+6. 点击查询。
+
+期望结果：
+
+- 红冲时间不在范围内时，不显示该红冲记录。
+- 红冲时间在范围内时，显示该红冲记录。
+- 系统不应按创建时间、处理时间或其他非红冲时间字段错误命中。
+
+证据要求：
+
+- 不命中截图两张。
+- 命中截图一张。
+
+---
+
+### Task 6: #69/#76 待审批状态文案验收
+
+**覆盖目标：** 未销分账、呆坏账、价差调整、违约金减免提交后，页面按业务状态提示“申请已提交，待审批/待回写/处理完成”，不把待审批误说成已生效。
+
+- [ ] **Step 1: 验证未销分账申请文案**
+
+操作步骤：
+
+1. 进入账务调整相关页面。
+2. 选择客户 C5 的一笔可分账账单。
+3. 发起未销分账申请。
+4. 提交后观察页面提示和列表状态。
+
+期望结果：
+
+- 如该操作需要审批，页面提示“申请已提交，待审批”或等价文案。
+- 页面不应提示“分账成功”“已生效”这类让用户误解为即时落账的文案。
+- 审批列表或业务记录中存在待审批申请。
+
+证据要求：
+
+- 提交后提示截图。
+- 业务列表状态或审批记录截图。
+
+- [ ] **Step 2: 验证呆坏账申请文案**
+
+操作步骤：
+
+1. 选择客户 C5 的一笔可做呆坏账处理的账单。
+2. 发起呆坏账申请。
+3. 提交后观察页面提示和列表状态。
+
+期望结果：
+
+- 如该操作需要审批，页面提示“申请已提交，待审批”或等价文案。
+- 页面不应提示“呆坏账处理完成”“已生效”这类即时落账文案。
+- 审批列表或业务记录中存在待审批申请。
+
+证据要求：
+
+- 提交后提示截图。
+- 业务列表状态或审批记录截图。
+
+- [ ] **Step 3: 验证价差调整申请文案**
+
+操作步骤：
+
+1. 选择客户 C5 的一笔可价差调整账单。
+2. 发起价差调整申请。
+3. 提交后观察页面提示和列表状态。
+
+期望结果：
+
+- 如该操作需要审批，页面提示“申请已提交，待审批”或等价文案。
+- 若后端返回待回写状态，页面提示“待回写”或“待执行”。
+- 页面不应把待审批或待回写状态表达为已完成。
+
+证据要求：
+
+- 提交后提示截图。
+- 业务列表状态或审批记录截图。
+
+- [ ] **Step 4: 验证违约金减免申请文案**
+
+操作步骤：
+
+1. 选择客户 C5 的一笔存在违约金或可减免账单。
+2. 发起违约金减免申请。
+3. 提交后观察页面提示和列表状态。
+
+期望结果：
+
+- 如该操作需要审批，页面提示“申请已提交，待审批”或等价文案。
+- 若后端返回处理完成且已回写，页面可提示“处理完成”。
+- 页面文案必须与审批状态和回写状态一致。
+
+证据要求：
+
+- 提交后提示截图。
+- 业务列表状态或审批记录截图。
+
+---
+
+### Task 7: 回归与一致性验收
+
+**覆盖目标：** 本轮修复不破坏柜台收费、柜台结账、红冲记录、水价模板和账务调整的基础链路。
+
+- [ ] **Step 1: 柜台收费基础回归**
+
+操作步骤：
+
+1. 选择一个无预存抵扣的客户。
+2. 完成一笔普通柜台收费。
+3. 查询支付记录和账单状态。
+
+期望结果：
+
+- 收费成功。
+- 账单状态更新正确。
+- 支付记录金额正确。
+
+证据要求：
+
+- 收费成功截图。
+- 支付记录或账单状态截图。
+
+- [ ] **Step 2: 柜台结账基础回归**
+
+操作步骤：
+
+1. 查询普通账单收费产生的未结账记录。
+2. 选择记录并完成结账。
+3. 查询已结账记录。
+
+期望结果：
+
+- 普通账单收费记录仍可结账。
+- 结账金额正确。
+- 结账后不再出现在待结清列表。
+
+证据要求：
+
+- 待结清、结账确认、已结账记录截图。
+
+- [ ] **Step 3: 红冲记录页面基础回归**
+
+操作步骤：
+
+1. 不输入任何筛选条件，打开红冲记录页面。
+2. 输入客户、收费员、红冲时间范围分别查询。
+
+期望结果：
+
+- 页面正常加载。
+- 查询条件可正常输入和清空。
+- 列表分页、刷新、空结果状态正常。
+
+证据要求：
+
+- 默认列表或空列表截图。
+- 条件查询截图。
+
+- [ ] **Step 4: 水价模板基础回归**
+
+操作步骤：
+
+1. 进入水价模板页面。
+2. 展开组织或模板树。
+3. 查看水价明细。
+4. 不进入调价态时执行普通查看和刷新。
+
+期望结果：
+
+- 水价模板树正常加载。
+- 明细正常展示。
+- 未进入调价态时不会出现可编辑误状态。
+
+证据要求：
+
+- 模板树和明细截图。
+
+## 验收记录模板
+
+测试人员执行时，每条用例按以下格式记录：
+
+```text
+缺陷编号：
+用例名称：
+执行人：
+执行时间：
+测试环境：
+登录账号：
+客户编号：
+业务单号：
+前置数据：
+操作步骤：
+期望结果：
+实际结果：
+通过状态：通过 / 不通过 / 阻塞
+证据文件：
+备注：
+```
+
+## 自检结果
+
+- 规格覆盖：本计划覆盖 `#78`、`#39`、`#50`、`#53`、`#58/#59`、`#69/#76`，并明确排除 `#70`、`#9`。
+- 占位扫描：未发现占位内容。
+- 类型一致性：缺陷编号、业务页面、状态文案、金额边界、时间字段均与设计文档保持一致。

docs/superpowers/plans/2026-06-10-prestore-error-handling-and-frontend-display.md

@@ -0,0 +1,153 @@
+# 预存余额错误处理修复 + 柜台收费开票/分账状态展示
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 修复 3 类异常处理缺陷 + 柜台收费主表格增加开票状态和分账状态列。
+
+**Architecture:** 后端 3 处异常处理修正已完成(未提交)，本次计划覆盖剩余 2 项：后端 VO 加字段 + 前端表格加列。`BeanUtils.toBean` 自动映射同名属性，后端改动最小。
+
+**Tech Stack:** Spring Boot 3, MyBatis-Plus, Vue 3, Element Plus, TypeScript
+
+---
+
+## 已完成修改 (未提交)
+
+| 文件 | 修改内容 |
+|------|---------|
+| `ChargeServiceImpl.java:2276-2281` | `catch(Exception)` 不再包装为 `IllegalArgumentException`，改为 `exception(INTERNAL_SERVER_ERROR)` |
+| `ChargeServiceImpl.java:2446-2448` | 开票状态校验从 `!= NOT_INVOICED` 改为仅拦截 `PARTIALLY_INVOICED` 和 `INVOICE_COMPLETED` |
+| `PrestorageAdjustInternalApiImpl.java:194-200` | catch 内 DB 更新加嵌套 try-catch，防止状态更新失败吞异常 |
+| `BadDebt/PriceDiff/LateFeeReduce/Writtenoff` AdjustInternalApiImpl | catch 内 `.message(e.getMessage())` 加 null-safe |
+
+---
+
+### Task 1: 后端 — ChargeDetailsPageRespVO 加分账字段
+
+**Files:**
+- Modify: `sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/controller/admin/charge/vo/ChargeDetailsPageRespVO.java` (在 `invoiceStateName` 之后插入)
+
+**Purpose:** 柜台收费主表格 API (`/business/charge/page-details`) 返回 `splitAdjustId`、`splitStatus` 字段，供前端展示分账状态。`ChargeDO` 已有这两个字段，只需在 VO 中声明即可自动映射。
+
+- [ ] **Step 1: 在 ChargeDetailsPageRespVO 添加字段**
+
+在 `ChargeDetailsPageRespVO.java` 的 `invoiceStateName` 字段后面添加：
+
+```java
+    @Schema(description = "分账调整主表ID")
+    private Long splitAdjustId;
+
+    @Schema(description = "分账状态：NONE/PARENT_SPLIT/SPLIT_CHILD")
+    @ExcelProperty("分账状态")
+    private String splitStatus;
+```
+
+位置：`invoiceStateName` 字段声明之后、`meterOthType` 字段之前。`BeanUtils.toBean` 自动从 `ChargeDO.splitAdjustId` / `ChargeDO.splitStatus` 映射。
+
+- [ ] **Step 2: 编译验证**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend/sw-business/sw-business-server && mvn compile -o
+```
+
+Expected: BUILD SUCCESS.
+
+- [ ] **Step 3: Commit**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend
+git add sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/controller/admin/charge/vo/ChargeDetailsPageRespVO.java
+git commit -m "feat(charge): ChargeDetailsPageRespVO 加分账字段 splitAdjustId + splitStatus"
+```
+
+---
+
+### Task 2: 前端 — 柜台收费主表格加开票状态 + 分账状态列
+
+**Files:**
+- Modify: `water-frontend/src/views/operatingCharges/counterCharging/index.vue:206-208` (在"状态"列之后插入两列)
+
+**Purpose:** 待缴账单表格中，在"状态"列后面加"开票状态"（已有后端字段 `invoiceStateName`）和"分账状态"（新后端字段 `splitStatus`），让操作员预判操作是否会被拦截。
+
+- [ ] **Step 1: 在待缴账单表格加两列**
+
+当前代码（约 206-208 行）：
+```html
+          <el-table-column label="状态" min-width="100">
+            <template #default>未收</template>
+          </el-table-column>
+```
+
+修改为：
+```html
+          <el-table-column label="状态" min-width="100">
+            <template #default>未收</template>
+          </el-table-column>
+          <el-table-column prop="invoiceStateName" label="开票状态" min-width="100">
+            <template #default="{ row }">{{ row.invoiceStateName || '-' }}</template>
+          </el-table-column>
+          <el-table-column label="分账" min-width="90">
+            <template #default="{ row }">
+              <el-tag v-if="row.splitStatus === 'PARENT_SPLIT'" type="warning" size="small">已分账</el-tag>
+              <el-tag v-else-if="row.splitStatus === 'SPLIT_CHILD'" type="info" size="small">子账单</el-tag>
+              <span v-else>-</span>
+            </template>
+          </el-table-column>
+```
+
+- [ ] **Step 2: 集收号模式下的子表格也同样加列**
+
+找到集收号子表格（约 75-89 行，`getHubCustomerCharges` 对应的 el-table），在"状态"列后同样插入上述两列。列定义相同。
+
+- [ ] **Step 3: TypeScript 类型检查**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend && npx vue-tsc --noEmit 2>&1 | grep "counterCharging" | head -10
+```
+
+Expected: 无新增错误（`CounterChargingChargeVO` 声明了 `[key: string]: any`，新字段不会报类型错误）。
+
+- [ ] **Step 4: Commit**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+git add src/views/operatingCharges/counterCharging/index.vue
+git commit -m "feat(counter): 柜台收费表格加开票状态 + 分账状态列"
+```
+
+---
+
+### Task 3: 提交全部后端异常处理修复
+
+**Files:** (已在工作区修改，待提交)
+- `ChargeServiceImpl.java`
+- `PrestorageAdjustInternalApiImpl.java`
+- `BadDebtAdjustInternalApiImpl.java`
+- `PriceDiffAdjustInternalApiImpl.java`
+- `LateFeeReduceInternalApiImpl.java`
+- `WrittenoffAdjustInternalApiImpl.java`
+
+- [ ] **Step 1: 确认修改内容**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend && git diff --stat
+```
+
+应显示 6 files changed.
+
+- [ ] **Step 2: 编译确认**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend/sw-business/sw-business-server && mvn compile -o
+```
+
+Expected: BUILD SUCCESS (仅 WARNING，无 ERROR).
+
+- [ ] **Step 3: Commit**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend
+git add -A
+git commit -m "fix: 异常处理修正 — handleUsageAdjust 不伪装 400 + invoiceState 放宽 + InternalApi catch 加固"
+```
+
+---

docs/superpowers/plans/2026-06-14-account-log-backend-alignment.md

@@ -0,0 +1,255 @@
+# 账务日志统计字段对齐 Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 修复 `getLogStat` 返回字段与前端 `AccountingAdjustStatRespVO` 不匹配的问题，使账务日志统计面板正确显示金额汇总、各状态笔数。
+
+**Architecture:** 后端已有 `AccountingAdjustLogController`（含 `log-page`/`log-stat`/`log-detail`）和 `AccountingAdjustActionController`（含 `log-refund`/`log-prestorage`/`log-revoke`/`log-process`/`log-attachments`/`log-export`），6 个操作端点均已存在。唯一缺口是 `log-stat` 返回的 `AccountingAdjustLogStatRespVO` 使用 `totalAmount`/`completedCount` 等旧字段名，而前端期望 `totalActionAmount`/`successCount`/`failCount` 等 8 个新字段。
+
+**Tech Stack:** Java 17, Spring Boot, MyBatis-Plus, JUnit 5 + Mockito, Lombok
+
+---
+
+## 前置说明：端点已存在
+
+前端调用的 6 个操作端点均已在 `AccountingAdjustActionController` 中实现，路径对比如下：
+
+| 前端 API | 后端 Controller | 状态 |
+|---|---|---|
+| `GET log-export` | `ActionController.exportLog()` | ✅ |
+| `GET log-process` | `ActionController.getLogProcess()` | ✅ |
+| `GET log-attachments` | `ActionController.getLogAttachments()` | ✅ |
+| `POST log-refund` | `ActionController.createLogRefund()` | ✅ |
+| `POST log-prestorage` | `ActionController.createLogPrestorage()` | ✅ |
+| `POST log-revoke` | `ActionController.revokeLog()` | ✅ |
+
+本次只修 **统计字段对齐** 一个问题。
+
+---
+
+### Task 1: 扩展 StatRespVO 字段
+
+**Files:**
+- Modify: `sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/controller/admin/accountingadjust/accountProcess/vo/AccountingAdjustLogStatRespVO.java`
+- Reference: `sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/service/accountingadjust/accountProcess/AccountingAdjustLogProcessServiceImpl.java:95-107` (current `getLogStat`)
+
+**当前字段（6个，与前端不匹配）：**
+
+```java
+private Long totalCount;        // 总条数 → 保留
+private BigDecimal totalAmount;        // 调整金额 → 改为 totalActionAmount
+private BigDecimal totalWaterVolume;   // 调整水量 → 保留兼容
+private Long completedCount;    // 已完成数量 → 替换
+private Long pendingCount;      // 未完成数量 → 替换
+private Long cancelledCount;    // 已撤销数量 → 替换
+```
+
+**前端期望字段（需新增）：**
+
+```java
+private BigDecimal totalActionAmount;  // 金额汇总
+private Long totalCount;               // 总笔数 (已有)
+private Long successCount;             // 成功笔数
+private Long failCount;                // 失败笔数
+private Long pendingApprovalCount;     // 待审批笔数
+private Long approvalRequiredCount;    // 需要审批笔数
+private Long approvedCount;            // 审批通过笔数
+private Long rejectedCount;            // 审批驳回笔数
+```
+
+- [ ] **Step 1: 修改 VO 字段**
+
+用以下完整内容替换 `AccountingAdjustLogStatRespVO.java`：
+
+```java
+package cn.com.emsoft.sw.business.controller.admin.accountingadjust.accountProcess.vo;
+
+import io.swagger.v3.oas.annotations.media.Schema;
+import lombok.Data;
+
+import java.math.BigDecimal;
+
+@Schema(description = "管理后台 - 账务日志兼容统计 Response VO")
+@Data
+public class AccountingAdjustLogStatRespVO {
+
+    @Schema(description = "金额汇总（所有记录 actionAmount 求和）")
+    private BigDecimal totalActionAmount;
+
+    @Schema(description = "总笔数")
+    private Long totalCount;
+
+    @Schema(description = "成功笔数 (resultStatus == SUCCESS)")
+    private Long successCount;
+
+    @Schema(description = "失败笔数 (resultStatus == FAIL)")
+    private Long failCount;
+
+    @Schema(description = "待审批笔数 (approvalStatus == PENDING_APPROVAL)")
+    private Long pendingApprovalCount;
+
+    @Schema(description = "需要审批笔数 (approvalRequired == true)")
+    private Long approvalRequiredCount;
+
+    @Schema(description = "审批通过笔数 (approvalStatus == APPROVED)")
+    private Long approvedCount;
+
+    @Schema(description = "审批驳回笔数 (approvalStatus == REJECTED)")
+    private Long rejectedCount;
+
+    // 保留旧字段兼容已有调用方（如单元测试中的 getTotalAmount()）
+    @Schema(description = "调整金额（兼容别名，等同于 totalActionAmount）")
+    private BigDecimal totalAmount;
+
+    @Schema(description = "调整水量")
+    private BigDecimal totalWaterVolume;
+
+    @Schema(description = "已完成数量（兼容别名，等同于 successCount）")
+    private Long completedCount;
+
+    @Schema(description = "未完成数量（兼容别名，等同于 pendingApprovalCount）")
+    private Long pendingCount;
+
+    @Schema(description = "已撤销数量（兼容别名，等同于 failCount + rejectedCount）")
+    private Long cancelledCount;
+}
+```
+
+**设计要点：保留旧字段 `totalAmount`/`completedCount`/`pendingCount`/`cancelledCount` 作为兼容别名，Service 中同时设置新旧两套字段，避免破坏已有单元测试。**
+
+---
+
+### Task 2: 更新 getLogStat 实现
+
+**Files:**
+- Modify: `sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/service/accountingadjust/accountProcess/AccountingAdjustLogProcessServiceImpl.java:95-107`
+- Test: `sw-business/sw-business-server/src/test/java/cn/com/emsoft/sw/business/service/accountingadjust/accountProcess/AccountingAdjustLogProcessServiceImplTest.java`
+
+- [ ] **Step 1: 替换 getLogStat 方法体**
+
+将 `AccountingAdjustLogProcessServiceImpl.java` 中 `getLogStat` 方法（当前约 12 行）替换为：
+
+```java
+@Override
+public AccountingAdjustLogStatRespVO getLogStat(AccountingAdjustLogPageReqVO reqVO) {
+    List<LegacyLogRecord> records = loadRecords(reqVO);
+    AccountingAdjustLogStatRespVO respVO = new AccountingAdjustLogStatRespVO();
+
+    // 新字段：前端直接使用
+    respVO.setTotalActionAmount(records.stream()
+            .map(record -> nvl(record.actionAmount))
+            .reduce(BigDecimal.ZERO, BigDecimal::add));
+    respVO.setTotalCount((long) records.size());
+    respVO.setSuccessCount(records.stream()
+            .filter(record -> "SUCCESS".equals(record.resultStatus)).count());
+    respVO.setFailCount(records.stream()
+            .filter(record -> "FAIL".equals(record.resultStatus)).count());
+    respVO.setPendingApprovalCount(records.stream()
+            .filter(record -> "PENDING_APPROVAL".equals(record.approvalStatus)).count());
+    respVO.setApprovalRequiredCount(records.stream()
+            .filter(record -> Boolean.TRUE.equals(record.approvalRequired)).count());
+    respVO.setApprovedCount(records.stream()
+            .filter(record -> "APPROVED".equals(record.approvalStatus)).count());
+    respVO.setRejectedCount(records.stream()
+            .filter(record -> "REJECTED".equals(record.approvalStatus)).count());
+
+    // 旧字段兼容（供已有单元测试和未迁移调用方使用）
+    respVO.setTotalAmount(respVO.getTotalActionAmount());
+    respVO.setTotalWaterVolume(records.stream()
+            .map(record -> nvl(record.waterVolumeChange))
+            .reduce(BigDecimal.ZERO, BigDecimal::add));
+    respVO.setCompletedCount(respVO.getSuccessCount());
+    respVO.setPendingCount(respVO.getPendingApprovalCount());
+    respVO.setCancelledCount(respVO.getFailCount() + respVO.getRejectedCount());
+
+    return respVO;
+}
+```
+
+**注意：`LegacyLogRecord` 中 `actionAmount`、`resultStatus`、`approvalStatus`、`approvalRequired`、`waterVolumeChange` 字段已在 Service 内部类中定义，无需额外 import。**
+
+- [ ] **Step 2: 编译验证**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend
+mvn compile -pl sw-business/sw-business-server -am -q 2>&1 | tail -10
+```
+
+预期：`BUILD SUCCESS`
+
+---
+
+### Task 3: 更新单元测试
+
+**Files:**
+- Modify: `sw-business/sw-business-server/src/test/java/cn/com/emsoft/sw/business/service/accountingadjust/accountProcess/AccountingAdjustLogProcessServiceImplTest.java`
+
+- [ ] **Step 1: 在已有测试中添加新字段断言**
+
+在 `getLogDetailAndStat_shouldReturnMergedDetailsAndCounts` 测试方法末尾（`assertEquals(new BigDecimal("5.00"), stat.getTotalAmount());` 之后），追加新字段断言：
+
+```java
+// 新统计字段断言
+assertEquals(new BigDecimal("5.00"), stat.getTotalActionAmount());
+assertEquals(1L, stat.getSuccessCount());
+assertEquals(0L, stat.getFailCount());
+assertEquals(1L, stat.getPendingApprovalCount());
+assertEquals(1L, stat.getApprovalRequiredCount());
+assertEquals(0L, stat.getApprovedCount());
+assertEquals(0L, stat.getRejectedCount());
+// 保持旧字段兼容断言
+assertEquals(new BigDecimal("5.00"), stat.getTotalAmount());
+assertEquals(1L, stat.getCompletedCount());
+assertEquals(1L, stat.getPendingCount());
+assertEquals(0L, stat.getCancelledCount());
+```
+
+- [ ] **Step 2: 运行测试验证**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend
+mvn test -pl sw-business/sw-business-server -Dtest=AccountingAdjustLogProcessServiceImplTest -q 2>&1 | tail -15
+```
+
+预期所有测试通过（4 个 test case，含新增断言）。
+
+---
+
+### Task 4: 全量编译 + 提交
+
+- [ ] **Step 1: 全量编译**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend
+mvn compile -pl sw-business/sw-business-server -am -q 2>&1 | tail -10
+```
+
+- [ ] **Step 2: 提交**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend
+git add sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/controller/admin/accountingadjust/accountProcess/vo/AccountingAdjustLogStatRespVO.java
+git add sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/service/accountingadjust/accountProcess/AccountingAdjustLogProcessServiceImpl.java
+git add sw-business/sw-business-server/src/test/java/cn/com/emsoft/sw/business/service/accountingadjust/accountProcess/AccountingAdjustLogProcessServiceImplTest.java
+git commit -m "fix: align log-stat response fields with frontend AccountingAdjustStatRespVO
+
+- Add totalActionAmount, successCount, failCount, pendingApprovalCount,
+  approvalRequiredCount, approvedCount, rejectedCount to StatRespVO
+- Update getLogStat() to compute new fields from loaded records
+- Keep legacy fields (totalAmount, completedCount, pendingCount,
+  cancelledCount) as compatibility aliases
+- Update unit test with new field assertions"
+```
+
+---
+
+## Self-Review
+
+**1. Spec coverage:** 统计字段对齐是唯一的后端缺口，Task 1-3 完整覆盖。
+
+**2. Placeholder scan:** 无 TBD/TODO/占位符，所有步骤都有具体代码和命令。
+
+**3. Type consistency:**
+- `LegacyLogRecord` 内部类字段 `actionAmount`（BigDecimal）、`resultStatus`（String）、`approvalStatus`（String）、`approvalRequired`（Boolean）、`waterVolumeChange`（BigDecimal）均在 ServiceImpl 中定义，与 `getLogStat` 新实现一致。
+- `AccountingAdjustLogStatRespVO` 新旧字段并存，旧测试 `getTotalAmount()` 等调用不受影响。
+- 前端 `AccountingAdjustStatRespVO` 的 8 个字段名与新增 VO 字段名完全一致（驼峰命名）。

docs/superpowers/plans/2026-06-14-account-log-baddebt-recovery.md

@@ -0,0 +1,203 @@
+# 账务日志功能按钮 + 呆坏账恢复 Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 修复账务日志页功能按钮（撤销/退转款/预转存/呆坏账恢复）根据数据状态正确显示，不再硬编码 `false`；新增呆坏账恢复入口。
+
+**Architecture:** 后端 `toPageResp()` 当前将 `canRevoke`/`canRefund`/`canPrestore` 硬编码为 `false`，`canRecoverBadDebt` 字段不存在。修复后根据 `LegacyLogRecord` 的 `objectType` + `resultStatus` + `approvalStatus` 动态判定；前端补 API 调用和按钮。
+
+**Tech Stack:** Java 17 + Spring Boot (backend), Vue 3 + TypeScript (frontend)
+
+---
+
+## canXxx 判定规则
+
+在 `toPageResp(LegacyLogRecord record)` 中按以下规则赋值：
+
+| 字段 | 条件 | 说明 |
+|---|---|---|
+| `canRevoke` | `approvalStatus == "PENDING_APPROVAL"` | 待审批状态可撤销 |
+| `canRefund` | `objectType == "PREPAID_REFUND" && resultStatus == "SUCCESS"` | 退转款成功后允许二次退款 |
+| `canPrestore` | `objectType == "PREPAID_REFUND" && resultStatus == "SUCCESS"` | 退转款成功后允许转预存 |
+| `canRecoverBadDebt` | `objectType == "BAD_DEBT_RECORD" && resultStatus == "SUCCESS"` | 坏账已执行可恢复为欠费 |
+
+---
+
+### Task 1: 后端 VO 加 canRecoverBadDebt
+
+**Files:**
+- Modify: `sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/controller/admin/accountingadjust/accountProcess/vo/AccountingAdjustLogPageRespVO.java`
+
+- [ ] **Step 1: 在 VO 末尾 canPrestore 后添加字段**
+
+```java
+    @Schema(description = "是否可恢复呆坏账")
+    private Boolean canRecoverBadDebt;
+```
+
+添加位置：紧跟 `private Boolean canPrestore;` 之后。
+
+---
+
+### Task 2: 后端 Service 修正 canXxx 赋值
+
+**Files:**
+- Modify: `sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/service/accountingadjust/accountProcess/AccountingAdjustLogProcessServiceImpl.java:520-522`
+
+- [ ] **Step 1: 替换硬编码 false 为动态判定**
+
+将 `toPageResp()` 中的三行：
+
+```java
+        respVO.setCanRevoke(false);
+        respVO.setCanRefund(false);
+        respVO.setCanPrestore(false);
+```
+
+替换为：
+
+```java
+        // 动态判定功能按钮可见性
+        respVO.setCanRevoke("PENDING_APPROVAL".equals(record.approvalStatus));
+        boolean refundEnabled = "PREPAID_REFUND".equals(record.objectType) && "SUCCESS".equals(record.resultStatus);
+        respVO.setCanRefund(refundEnabled);
+        respVO.setCanPrestore(refundEnabled);
+        respVO.setCanRecoverBadDebt("BAD_DEBT_RECORD".equals(record.objectType) && "SUCCESS".equals(record.resultStatus));
+```
+
+**同时需要更新 `AccountingAdjustLogPageReqVO` 的 `copyReq` 方法：** 无需改动，canXxx 是响应字段。
+
+---
+
+### Task 3: 前端 API 加 recoverBadDebt
+
+**Files:**
+- Modify: `src/api/accountProcess/accountLog/index.ts`
+
+- [ ] **Step 1: 添加接口类型和 API 方法**
+
+在 `AccountingAdjustPageRespVO` 接口中添加 `canRecoverBadDebt` 字段，并在 `AccountLogApi` 对象中添加 `recoverBadDebt` 方法：
+
+```typescript
+// 在 AccountingAdjustPageRespVO 接口中添加
+  canRecoverBadDebt?: boolean
+```
+
+```typescript
+// 在 AccountLogApi 对象中添加（放在 revokeAccountLog 之前）
+  // 账务日志呆坏账恢复
+  recoverBadDebt: async (data: { adjustmentNo: string }) => {
+    return await request.post<AccountingAdjustRespVO>({
+      url: '/business/accounting-adjust/log-recover-bad-debt',
+      data
+    })
+  },
+```
+
+---
+
+### Task 4: 前端页面加呆坏账恢复按钮
+
+**Files:**
+- Modify: `src/views/accountProcess/accountLog/index.vue`
+
+- [ ] **Step 1: 在 function 模板中添加按钮**
+
+在现有三个按钮之后、`</div>` 之前添加：
+
+```html
+            <el-button
+              v-if="scope.row.canRecoverBadDebt"
+              link
+              type="primary"
+              @click="handleRecoverBadDebt(scope.row)"
+            >
+              <el-tooltip effect="dark" content="恢复呆坏账" placement="top">
+                <Icon icon="ep:refresh-left" :size="18" />
+              </el-tooltip>
+            </el-button>
+```
+
+- [ ] **Step 2: 在 script 中添加处理函数**
+
+在 `handlePrestore` 之后添加：
+
+```typescript
+const handleRecoverBadDebt = async (row: any) => {
+  const adjustmentNo = row?.adjustmentNo
+  if (!adjustmentNo) {
+    message.warning('缺少调整单号，无法恢复')
+    return
+  }
+  try {
+    await message.confirm(`确认要将呆坏账调整单「${adjustmentNo}」恢复为欠费状态吗？`)
+    await AccountLogApi.recoverBadDebt({ adjustmentNo })
+    message.success('呆坏账已恢复为欠费')
+    await getList()
+  } catch (e: any) {
+    if (e !== 'cancel' && e !== 'close') {
+      message.error('恢复失败，请稍后重试')
+    }
+  }
+}
+```
+
+---
+
+### Task 5: 编译验证 + 提交
+
+- [ ] **Step 1: 后端编译 + 测试**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-backend
+mvn test -pl sw-business/sw-business-server -Dtest=AccountingAdjustLogProcessServiceImplTest -DfailIfNoTests=false 2>&1 | grep -E "Tests run|BUILD"
+```
+
+预期：Tests run: 4, Failures: 0, BUILD SUCCESS
+
+- [ ] **Step 2: 前端 TypeScript 编译**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+npx vue-tsc --noEmit 2>&1 | grep -i "error\|accountLog" | head -10
+```
+
+预期：无类型错误。
+
+- [ ] **Step 3: 提交**
+
+```bash
+# 后端
+cd /Volumes/Dpan/github/water-workspace/water-backend
+git add sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/controller/admin/accountingadjust/accountProcess/vo/AccountingAdjustLogPageRespVO.java
+git add sw-business/sw-business-server/src/main/java/cn/com/emsoft/sw/business/service/accountingadjust/accountProcess/AccountingAdjustLogProcessServiceImpl.java
+git commit -m "feat: add canRecoverBadDebt and fix canRevoke/canRefund/canPrestore logic
+
+- Add canRecoverBadDebt field to AccountingAdjustLogPageRespVO
+- Replace hardcoded false with dynamic logic in toPageResp():
+  canRevoke = approvalStatus is PENDING_APPROVAL
+  canRefund/canPrestore = PREPAID_REFUND + SUCCESS
+  canRecoverBadDebt = BAD_DEBT_RECORD + SUCCESS"
+
+# 前端
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+git add src/api/accountProcess/accountLog/index.ts src/views/accountProcess/accountLog/index.vue
+git commit -m "feat: add bad debt recovery button and API to account log page
+
+- Add recoverBadDebt API method calling POST log-recover-bad-debt
+- Add canRecoverBadDebt field to AccountingAdjustPageRespVO
+- Add recovery button with confirm dialog in function column"
+```
+
+---
+
+## Self-Review
+
+**1. Spec coverage:** 4 个功能按钮全部覆盖：canRevoke/canRefund/canPrestore 修正 + canRecoverBadDebt 新增。
+
+**2. Placeholder scan:** 无占位符，所有步骤含具体代码。
+
+**3. Type consistency:**
+- `record.approvalStatus`、`record.resultStatus`、`record.objectType` 均为 `LegacyLogRecord` 内部类字段，已存在于 ServiceImpl
+- 前端 `canRecoverBadDebt` 字段同时加入 `AccountingAdjustPageRespVO` 接口和 API 调用
+- 后端 `recoverBadDebt` API 接收 `{ adjustmentNo: string }`，与 `AdjustExecuteReqDTO` 匹配

docs/superpowers/plans/2026-06-14-account-log-frontend-params.md

@@ -0,0 +1,278 @@
+# 账务日志前端参数映射修正 Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 修正账务日志页 `buildQueryParams()` 发送给后端的参数名与 `AccountingAdjustLogPageReqVO` 不匹配的问题，使表单筛选真正生效；同步更新前端 `AccountLogPageReqVO` 类型定义。
+
+**Architecture:** 前端 `buildQueryParams()` 当前将表单字段映射为 `approvalStatus`/`objectType`/`resultStatus` 等前端旧命名，后端 `AccountingAdjustLogPageReqVO` 期望 `status`/`accountType`/`processMethod` 等字段名，且缺少 `deptId`/`custCode`/`createTime` 等关键字段。修正后筛选条件可正常下发，统计面板因后端已修复可直接显示。
+
+**Tech Stack:** Vue 3 + TypeScript, Element Plus, Axios
+
+---
+
+## 文件结构
+
+| 文件 | 职责 |
+|---|---|
+| `src/api/accountProcess/accountLog/index.ts` | API 类型定义，修正 `AccountLogPageReqVO` |
+| `src/views/accountProcess/accountLog/index.vue` | 页面组件，修正 `buildQueryParams()` 映射 |
+
+---
+
+## 参数映射对照表
+
+表单 `queryParams` → 后端期望字段 → 当前错误映射：
+
+| 表单字段 | queryParams key | 后端字段 | 当前前端发送 | 问题 |
+|---|---|---|---|---|
+| 营业站点 | `deptId` | `deptId` | ❌ 未发送 | 缺失 |
+| 客户编号 | `custCode` | `custCode` | ❌ 未发送 | 缺失 |
+| 状态 | `status` | `status` | `approvalStatus` | 名称错误 |
+| 账务年月 | `accountMonth` | `accountMonth` (List) | `accountMonthStart`/`End` | 缺少 `accountMonth` |
+| 账务类型 | `accountType` | `accountType` | `objectType` | 名称错误 |
+| 处理方式 | `processMethod` | `processMethod` | `resultStatus` + `writeBackStatus` | 名称错误+重复 |
+| 创建时间 | `createTime` | `createTime` | ❌ 未发送 | 缺失 |
+| 处理人 | `handler` | `handler` | ❌ 未发送 | 缺失 |
+| 处理时间 | `handleTime` | `handleTime` | `operationTime` | 名称错误 |
+| 目标户号 | `targetCustCode` | `targetCustCode` | ❌ 未发送 | 缺失 |
+| 缴费日期 | `paymentDate` | `paymentDate` | ❌ 未发送 | 缺失 |
+| 册本编号 | `bookCode` | `bookCode` | ❌ 未发送 | 缺失 |
+
+---
+
+### Task 1: 修正 AccountLogPageReqVO 类型定义
+
+**Files:**
+- Modify: `src/api/accountProcess/accountLog/index.ts`
+
+- [ ] **Step 1: 替换类型定义**
+
+将 `AccountLogPageReqVO` 接口替换为与后端 `AccountingAdjustLogPageReqVO` 对齐的版本：
+
+```typescript
+export interface AccountLogPageReqVO {
+  /**
+   * 调整单号
+   */
+  adjustmentNo?: string
+  /**
+   * 营业站点 ID
+   */
+  deptId?: number
+  /**
+   * 客户编号
+   */
+  custCode?: string
+  /**
+   * 页面状态（兼容前端：1-正常，2-已撤销）
+   */
+  status?: string
+  /**
+   * 账务年月范围（兼容前端 monthrange）
+   */
+  accountMonth?: string[]
+  /**
+   * 账务年月开始，格式 YYYYMM
+   */
+  accountMonthStart?: number
+  /**
+   * 账务年月结束，格式 YYYYMM
+   */
+  accountMonthEnd?: number
+  /**
+   * 账务类型
+   */
+  accountType?: string
+  /**
+   * 处理方式
+   */
+  processMethod?: string
+  /**
+   * 创建时间范围（兼容前端 daterange）
+   */
+  createTime?: string[]
+  /**
+   * 创建时间开始
+   */
+  createTimeStart?: string
+  /**
+   * 创建时间结束
+   */
+  createTimeEnd?: string
+  /**
+   * 处理人
+   */
+  handler?: string
+  /**
+   * 处理时间范围（兼容前端 daterange）
+   */
+  handleTime?: string[]
+  /**
+   * 处理时间开始
+   */
+  handleTimeStart?: string
+  /**
+   * 处理时间结束
+   */
+  handleTimeEnd?: string
+  /**
+   * 目标户号
+   */
+  targetCustCode?: string
+  /**
+   * 缴费日期范围（兼容前端 daterange）
+   */
+  paymentDate?: string[]
+  /**
+   * 缴费日期开始
+   */
+  paymentDateStart?: string
+  /**
+   * 缴费日期结束
+   */
+  paymentDateEnd?: string
+  /**
+   * 册本编号
+   */
+  bookCode?: string
+  /**
+   * 页码，从 1 开始
+   */
+  pageNo: number
+  /**
+   * 每页条数，最大值为 100
+   */
+  pageSize: number
+  [property: string]: any
+}
+```
+
+**设计要点：同时保留 `accountMonth`（数组）和 `accountMonthStart/accountMonthEnd`（数值），后端 `AccountingAdjustLogPageReqVO` 的 getter 方法会优先使用后者，但发送数组可保证 Spring 的日期格式兼容。**
+
+---
+
+### Task 2: 重写 buildQueryParams() 参数映射
+
+**Files:**
+- Modify: `src/views/accountProcess/accountLog/index.vue` (仅 `buildQueryParams` 函数)
+
+- [ ] **Step 1: 替换 buildQueryParams 函数**
+
+将当前的 `buildQueryParams`（约 15 行）替换为：
+
+```typescript
+const buildQueryParams = (): AccountLogPageReqVO => {
+  const [accountMonthStartRaw, accountMonthEndRaw] = queryParams.accountMonth || []
+  const [createTimeStartRaw, createTimeEndRaw] = queryParams.createTime || []
+  const [handleTimeStartRaw, handleTimeEndRaw] = queryParams.handleTime || []
+  const [paymentDateStartRaw, paymentDateEndRaw] = queryParams.paymentDate || []
+
+  return {
+    pageNo: queryParams.pageNo,
+    pageSize: queryParams.pageSize,
+    // 基础字段
+    deptId: queryParams.deptId ?? undefined,
+    custCode: queryParams.custCode || undefined,
+    // 状态：前端 select 值为 "1"/"2"，直接透传给后端 status
+    status: queryParams.status || undefined,
+    // 账务年月：同时发数组（后端 getAccountMonth() 会解析）+ 数值（后端优先取用）
+    accountMonth: queryParams.accountMonth?.length ? queryParams.accountMonth : undefined,
+    accountMonthStart: toMonthNumber(accountMonthStartRaw),
+    accountMonthEnd: toMonthNumber(accountMonthEndRaw),
+    // 账务类型
+    accountType: queryParams.accountType || undefined,
+    // 处理方式
+    processMethod: queryParams.processMethod || undefined,
+    // 创建时间
+    createTime: queryParams.createTime?.length ? queryParams.createTime : undefined,
+    createTimeStart: createTimeStartRaw || undefined,
+    createTimeEnd: createTimeEndRaw || undefined,
+    // 处理人
+    handler: queryParams.handler || undefined,
+    // 处理时间
+    handleTime: queryParams.handleTime?.length ? queryParams.handleTime : undefined,
+    handleTimeStart: handleTimeStartRaw || undefined,
+    handleTimeEnd: handleTimeEndRaw || undefined,
+    // 目标户号
+    targetCustCode: queryParams.targetCustCode || undefined,
+    // 缴费日期
+    paymentDate: queryParams.paymentDate?.length ? queryParams.paymentDate : undefined,
+    paymentDateStart: paymentDateStartRaw || undefined,
+    paymentDateEnd: paymentDateEndRaw || undefined,
+    // 册本编号
+    bookCode: queryParams.bookCode || undefined
+  }
+}
+```
+
+**关键修正点：**
+- `approvalStatus` → `status`
+- `objectType` → `accountType`
+- `resultStatus` / `writeBackStatus`（重复） → `processMethod`
+- `operationTime` → `handleTime`
+- 新增：`deptId`、`custCode`、`createTime`、`handler`、`targetCustCode`、`paymentDate`、`bookCode`
+- 时间字段同时发送数组形式（`createTime: ['2025-01-01','2026-01-29']`）和拆解形式（`createTimeStart`/`createTimeEnd`），后端 `normalizeQuery` 和 getter 均能处理
+
+- [ ] **Step 2: 验证 TypeScript 编译**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+npx vue-tsc --noEmit src/views/accountProcess/accountLog/index.vue 2>&1 | head -20
+```
+
+预期：无类型错误。
+
+---
+
+### Task 3: 端到端验证
+
+- [ ] **Step 1: 启动前端 dev server 验证页面**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+npx vite --port 5173 &
+sleep 3
+echo "Dev server running at http://localhost:5173"
+```
+
+- [ ] **Step 2: 验证统计面板**
+
+打开账务日志页面，确认统计值不再是全 0：
+- 金额汇总显示格式化货币值（如 `¥12,345.00`）
+- 各笔数按颜色区分（成功=绿、失败=红、待审批=橙、通过=蓝）
+
+- [ ] **Step 3: 验证筛选功能**
+
+分别测试以下筛选条件确认数据变化：
+- 切换"营业站点"下拉
+- 输入"客户编号"查询
+- 选择"状态"为"已撤销"
+
+- [ ] **Step 4: 提交**
+
+```bash
+cd /Volumes/Dpan/github/water-workspace/water-frontend
+git add src/api/accountProcess/accountLog/index.ts src/views/accountProcess/accountLog/index.vue
+git commit -m "fix: align account log query params with backend AccountingAdjustLogPageReqVO
+
+- Rewrite AccountLogPageReqVO interface to match backend field names
+  (status, accountType, processMethod, handleTime, etc.)
+- Add missing fields: deptId, custCode, createTime, handler,
+  targetCustCode, paymentDate, bookCode
+- Fix buildQueryParams() to send correct parameter names
+- Send both array and decomposed date formats for backend compatibility"
+```
+
+---
+
+## Self-Review
+
+**1. Spec coverage:** 所有 12 个表单字段的映射错误均已覆盖，TypeScript 类型定义同步更新。
+
+**2. Placeholder scan:** 无 TBD/TODO，所有步骤含具体代码和命令。
+
+**3. Type consistency:**
+- `buildQueryParams` 返回 `AccountLogPageReqVO`，所有字段名与 Task 1 中定义一致
+- 时间字段同时发送数组形式（`createTime: string[]`）和拆解形式（`createTimeStart: string`），匹配后端 VO 的 getter 逻辑
+- `deptId` 使用 `?? undefined` 处理 0 值（根站点），避免被 `||` 误判为 falsy
+- 其他字符串字段使用 `|| undefined` 将空字符串转为 undefined

specs/001-rev004-accounting/contracts/if-rev-007-accounting-request.md

@@ -1,71 +0,0 @@
-# Contract: IF-REV-007 账务调整接口
-
-## 1. 合同定位
-
-本合同用于固化 `IF-REV-007` 在 REV-004 一期中的统一接口口径，服务于后续正式接口文档修订、任务拆解与评审，不作为代码接口定义文件。
-
-## 2. 适用范围
-
-适用场景：
-- 水量调整
-- 金额调整
-- 退款
-- 冲正
-- 坏账申请
-
-不适用范围：
-- 发票申请与结果回写
-- 银行代收与结算协同
-- 新 BPM 流程模型扩展
-- 独立账务台账表族设计
-
-## 3. 请求合同
-
-| 字段 | 类型 | 必填 | 说明 | 约束 |
-|------|------|------|------|------|
-| chargeId | Long | 是 | 目标账单 ID | 必须存在于 `biz_charge.id` |
-| adjustType | String | 是 | 调整类型 | `USAGE` / `AMOUNT` / `REFUND` / `REVERSE` / `BAD_DEBT` |
-| adjustAmount | Decimal | 否 | 调整金额 | 金额类场景必填 |
-| adjustUsage | Decimal | 否 | 调整水量 | 水量类场景必填 |
-| sourceTradeNo | String | 否 | 原交易流水号 | `REFUND` / `REVERSE` 场景必填 |
-| reasonCode | String | 是 | 调整原因编码 | 需可追溯到业务字典 |
-| remark | String | 否 | 调整说明 | 进入操作留痕 |
-| attachmentList | Array<String> | 否 | 依据附件 | 进入依据引用 |
-| operatorId | Long | 是 | 操作人 ID | 必须可追溯责任归属 |
-
-## 4. 响应合同
-
-| 字段 | 类型 | 说明 | 约束 |
-|------|------|------|------|
-| adjustmentNo | String | 调整业务编号 | 用于后续追踪 |
-| chargeId | Long | 目标账单 ID | 与请求一致 |
-| resultStatus | String | 处理状态 | `SUCCESS` / `PENDING_APPROVAL` / `FAIL` |
-| writeBackStatus | String | 账单回写状态 | `SUCCESS` / `IGNORE_REPEAT` / `FAIL` |
-| approvalRequired | Boolean | 是否进入审批 | 一期仅保留能力位 |
-| msg | String | 处理说明 | 供调用方和评审使用 |
-
-## 5. 共性规则
-
-1. 所有场景必须定位到既有账单对象，不建立并行账务主对象。
-2. 所有场景必须保留处理依据、前后变化和责任归属。
-3. 退款、冲正必须校验原交易存在性、交易状态、回调结果与异常处理状态，不得只以 `bk_transaction` 主记录存在作为通过条件。
-4. 审批相关内容一期仅保留 `approvalRequired`、`PENDING_APPROVAL` 与审批边界说明，不展开完整 BPM 流程、流程节点、流转规则或审批回写实现细节。
-5. 接口结果必须能映射到 `biz_charge*`、`bk_transaction*`、`biz_operat_log*` 三类对象。
-6. `resultStatus` 与 `writeBackStatus` 必须分离表达：前者表示业务处理结论，后者表示账单状态回写结论。
-
-## 6. 物理承接口径
-
-| 逻辑对象 | 物理承接 |
-|---------|----------|
-| 账单主对象 | `biz_charge` |
-| 账单明细 | `biz_charge_detail` |
-| 原交易校验 | `bk_transaction*` |
-| 主日志 | `biz_operat_log` |
-| 差异明细日志 | `biz_operat_log_detail` |
-
-## 7. 验收关注点
-
-- 是否所有场景都仍挂靠 `IF-REV-007`
-- 是否未引入超范围接口编号
-- 是否未把审批/BPM 细化为一期必做实现
-- 是否未误写独立账务台账表族为在线新增对象

specs/001-rev004-accounting/contracts/rev004-scenario-matrix.md

@@ -1,33 +0,0 @@
-# Contract: REV-004 一期场景矩阵
-
-## 1. 目的
-
-用于统一 REV-004 一期各场景在输入依据、关键校验、结果表达和留痕要求上的差异，支撑后续 plan/tasks 拆解。
-
-## 2. 场景矩阵
-
-| 场景 | 主要输入 | 关键校验 | 结果表达 | 留痕重点 | 备注 |
-|------|----------|----------|----------|----------|------|
-| 水量调整 | `chargeId`、`adjustUsage`、`reasonCode` | 原抄表依据、账单状态可调 | `resultStatus`、`writeBackStatus` | 调整前后水量、依据附件 | 不新增跨周期水量独立表 |
-| 金额调整 | `chargeId`、`adjustAmount`、`reasonCode` | 差异金额合法性、账单状态可调 | `resultStatus`、`writeBackStatus` | 调整前后金额、原因、经办人 | 可涉及重算口径 |
-| 退款 | `chargeId`、`adjustAmount`、`sourceTradeNo` | 原交易存在、可退金额、幂等性 | `resultStatus`、`approvalRequired`、`writeBackStatus` | 原交易号、退款金额、处理结果 | 一期仅保留审批能力位 |
-| 冲正 | `chargeId`、`sourceTradeNo`、`reasonCode` | 原交易状态、账单状态、可冲正性 | `resultStatus`、`approvalRequired`、`writeBackStatus` | 原交易号、状态变化、处理原因 | 不强接 BPM |
-| 坏账申请 | `chargeId`、`reasonCode`、`remark` | 账龄、客户状态、业务条件 | `resultStatus`、`approvalRequired`、`writeBackStatus` | 申请原因、账单状态、审批边界 | 一期仅保留审批能力位与边界说明 |
-
-## 3. 共性能力
-
-所有场景共享以下能力：
-- 统一入口：`IF-REV-007`
-- 统一账单承接：`biz_charge` / `biz_charge_detail`
-- 统一原交易校验：`bk_transaction` / `bk_transaction_callback` / `bk_transaction_exception`
-- 统一留痕：`biz_operat_log` / `biz_operat_log_detail`
-- 统一结果表达：`resultStatus` / `writeBackStatus`（前者表示处理结论，后者表示账单回写结论）
-- 审批边界：只保留 `approvalRequired`、`PENDING_APPROVAL` 与边界说明，不展开完整 BPM 流程、节点、流转规则或审批回写实现细节
-
-## 4. 排除说明
-
-以下内容不在本矩阵覆盖范围内：
-- 独立账务细表设计
-- 发票、银行结算等其他接口族
-- backend 实施代码结构
-- 完整 BPM 审批流程定义

specs/001-rev004-accounting/contracts/rev004-traceability-matrix.md

@@ -1,23 +0,0 @@
-# Contract: REV-004 一期追溯矩阵
-
-## 1. 目的
-
-用于建立 `spec.md`、详细设计、接口设计、数据库设计之间的稳定追溯关系，确保后续正式文档修订与任务拆解基于同一口径。
-
-## 2. 追溯矩阵
-
-| 规格需求/场景 | 详细设计承接 | 接口设计承接 | 数据库承接 | 说明 |
-|--------------|--------------|--------------|------------|------|
-| 一期纳入范围：水量调整/金额调整/退款/冲正/坏账申请 | `12_REV_Detailed.md` REV-004 场景表 | `03_Interface_Design.md` `IF-REV-007` | `biz_charge*`、`biz_operat_log*` | 五类场景统一纳入一期，排除独立账务细表扩围 |
-| 统一接口入口 | REV-004 接口映射 | `IF-REV-007` 请求/响应定义 | 账单与日志对象 | 不扩展到 `IF-REV-008`、`IF-REV-011` 等其他接口族 |
-| 原交易校验 | REV-004 关键规则 | `sourceTradeNo` 字段 | `bk_transaction*` | 退款/冲正必须联动原交易主状态、回调结果与异常处理状态 |
-| 处理结果回写 | REV-004 业务流程/关键规则 | `writeBackStatus`、`resultStatus` | `biz_charge` 状态承接 | `resultStatus` 与 `writeBackStatus` 必须分离表达 |
-| 审批边界 | 审批留痕要求 | `approvalRequired`、`PENDING_APPROVAL` | 仅能力位，无独立审批表要求 | 一期不强接 BPM，仅保留边界说明 |
-| 留痕与依据 | 操作日志与审批留痕 | `remark`、`attachmentList` | `biz_operat_log` / `biz_operat_log_detail` | 必须覆盖处理类型、原交易引用、前后差异与附件依据 |
-| 旧系统细粒度台账承接 | 迁移补充表 | 历史查询与迁移校验口径 | 历史只读 + 在线主模型 | 不误写为在线新增实体 |
-
-## 3. 使用约束
-
-- 本矩阵只服务于文档规划与后续正式主文档修订。
-- 若某条追溯关系无法在三份正式文档中对齐，应先回写正式主文档，再继续 tasks 或实施讨论。
-- Archive 与执行手册可用于核对，但不得替代正式结论。

specs/001-rev004-accounting/data-model.md

@@ -1,167 +0,0 @@
-# Data Model: REV-004 账务处理一期
-
-## 建模原则
-
-- 以逻辑实体 + 物理承接对象双层表达，避免把未确认能力误写为已落地独立表。
-- 在线主模型优先复用 `biz_charge*`、`biz_operat_log*`、`bk_transaction*`。
-- 审批相关内容仅保留能力位，不展开完整 BPM 流程模型。
-
-## 实体一：AccountingRequest（账务处理申请）
-
-### 作用
-统一承接 `IF-REV-007` 的五类场景输入：水量调整、金额调整、退款、冲正、坏账申请。
-
-### 核心字段
-
-| 字段 | 类型 | 说明 |
-|------|------|------|
-| requestNo | String | 申请编号/调整业务编号 |
-| adjustType | Enum | `USAGE` / `AMOUNT` / `REFUND` / `REVERSE` / `BAD_DEBT` |
-| chargeId | Long | 目标账单 ID |
-| sourceTradeNo | String | 原交易流水号，退款/冲正场景使用 |
-| adjustAmount | Decimal | 调整金额 |
-| adjustUsage | Decimal | 调整水量 |
-| reasonCode | String | 调整原因编码 |
-| remark | String | 调整说明 |
-| attachmentList | Array<String> | 依据附件 |
-| operatorId | Long | 操作人 ID |
-| requestedAt | DateTime | 发起时间 |
-
-### 校验规则
-- `chargeId`、`adjustType`、`reasonCode`、`operatorId` 必填。
-- `REFUND` / `REVERSE` 场景必须具备 `sourceTradeNo`。
-- `adjustAmount` 与 `adjustUsage` 按场景二选一或组合使用，不允许无意义空提交。
-
-### 状态
-`submitted` → `accepted` / `rejected` → `processed` / `failed`
-
-## 实体二：AccountingResult（账务处理结果）
-
-### 作用
-统一承接处理结果、回写结果与是否需要审批。
-
-### 核心字段
-
-| 字段 | 类型 | 说明 |
-|------|------|------|
-| adjustmentNo | String | 调整业务编号 |
-| chargeId | Long | 目标账单 ID |
-| resultStatus | Enum | `SUCCESS` / `PENDING_APPROVAL` / `FAIL` |
-| writeBackStatus | Enum | `SUCCESS` / `IGNORE_REPEAT` / `FAIL` |
-| approvalRequired | Boolean | 是否进入审批 |
-| msg | String | 处理说明 |
-| processedAt | DateTime | 处理时间 |
-
-### 状态关系
-- `resultStatus` 表示业务处理结果。
-- `writeBackStatus` 表示账单回写结果。
-- `approvalRequired=true` 时允许 `resultStatus=PENDING_APPROVAL`。
-
-## 实体三：ChargeAggregate（账单聚合对象）
-
-### 作用
-作为 REV-004 调整、退款、冲正的主要业务承接对象。
-
-### 物理承接
-- `biz_charge`
-- `biz_charge_detail`
-
-### 核心字段
-
-| 字段 | 来源 | 说明 |
-|------|------|------|
-| chargeId | `biz_charge.id` | 账单主键 |
-| chargeStatus | `biz_charge` | 账单状态 |
-| receivableAmount | `biz_charge` / `biz_charge_detail` | 应收金额 |
-| paidAmount | 业务汇总 | 已收金额 |
-| remainAmount | 业务汇总 | 剩余待支付金额 |
-| detailItems | `biz_charge_detail` | 费用明细集合 |
-
-### 关键关系
-- 1 个 `ChargeAggregate` 对应多条 `biz_charge_detail`。
-- 1 个 `AccountingRequest` 必须定位到 1 个 `ChargeAggregate`。
-
-## 实体四：Transaction（原交易流水）
-
-### 作用
-为退款、冲正等场景提供原交易事实依据。
-
-### 物理承接
-- `bk_transaction`
-- 关联扩展：`bk_transaction_callback`（异步回调结果核对）
-- 关联扩展：`bk_transaction_exception`（异常处理状态核对）
-
-### 核心字段
-
-| 字段 | 说明 |
-|------|------|
-| tradeNo | 渠道交易流水号 |
-| tradeStatus | 原交易状态 |
-| tradeAmount | 原交易金额 |
-| channelCode | 渠道编码 |
-| occurredAt | 交易发生时间 |
-
-### 关键规则
-- `REFUND` / `REVERSE` 必须关联 `tradeNo`。
-- 原交易状态必须满足“可退款/可冲正”业务前提。
-- 原交易校验应同时覆盖交易主状态、回调结果与异常处理状态，不得只校验交易主表存在性。
-
-## 实体五：OperationLog（操作留痕）
-
-### 作用
-记录账务处理前后变化、处理依据与责任归属。
-
-### 物理承接
-- `biz_operat_log`
-- `biz_operat_log_detail`
-
-### 核心字段
-
-| 字段 | 说明 |
-|------|------|
-| bizType | 业务类型 |
-| bizId | 业务对象 ID |
-| operateUser | 操作人 |
-| operateTime | 操作时间 |
-| remark | 处理说明 |
-| beforeValue | 调整前值 |
-| afterValue | 调整后值 |
-| fieldName | 字段级差异项 |
-
-### 关键规则
-- 所有 REV-004 一期场景都必须写入主日志。
-- 涉及金额/水量/状态变化时应写入字段级差异明细。
-
-## 实体六：AccountingEvidence（处理依据）
-
-### 作用
-统一描述原账单、原交易、附件、文字说明等处理依据。
-
-### 核心字段
-
-| 字段 | 说明 |
-|------|------|
-| evidenceType | 原账单 / 原交易 / 附件 / 说明 |
-| sourceRef | 依据引用标识 |
-| snapshotRef | 快照引用 |
-| attachmentList | 附件集合 |
-
-### 说明
-该实体是逻辑约束，不要求本阶段新增物理表；由既有对象引用、附件系统与日志共同承接。
-
-## 关系总览
-
-```text
-AccountingRequest --> ChargeAggregate
-AccountingRequest --> Transaction (REFUND/REVERSE only)
-AccountingRequest --> AccountingEvidence
-AccountingRequest --> AccountingResult
-AccountingRequest --> OperationLog
-ChargeAggregate --> biz_charge_detail (1:N)
-OperationLog --> biz_operat_log_detail (1:N)
-```
-
-## 状态与边界说明
-
-- 一期仅保留审批能力位，不定义完整审批状态机。
-- 旧系统精细账务对象如预存退款明细、价差调整明细、分账调整明细等，不作为一期新增实体表；仅保留业务场景、历史只读与日志承接口径。

specs/001-rev004-accounting/plan.md

@@ -20,7 +20,7 @@
 - `docs/design/03_Technical_Design/03_Interface_Design.md`
 - `docs/design/03_Technical_Design/01_Database_Design.md`
 **Reference Sources**:
-- `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
+- `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
 - `docs/design/00_Management/01_Project_Progress.md`
 - `docs/design/00_Management/02_Delivery_Standards.md`
 - `docs/design/00_Management/03_Task_Checklist.md`
@@ -99,7 +99,7 @@ docs/design/
 └── 04_Appendix/Archive/
 
 .specify/memory/constitution.md
-docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md
+docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md
 CLAUDE.md
 ```
 

specs/001-rev004-accounting/quickstart.md

@@ -65,7 +65,7 @@
 
 ### 步骤六：独立验收入口校验
 确认审阅者仅通过以下文件即可完成 US3 验收：
-- `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
+- `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
 - `docs/design/00_Management/01_Project_Progress.md`
 - `docs/design/00_Management/03_Task_Checklist.md`
 
@@ -82,7 +82,7 @@
 ## 3. 最小校验命令
 
 ```bash
-make validate-file FILE=docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md
+make validate-file FILE=docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md
 make validate-file FILE=docs/design/00_Management/01_Project_Progress.md
 make validate-file FILE=docs/design/00_Management/03_Task_Checklist.md
 make check-links

specs/001-rev004-accounting/spec.md

@@ -11,7 +11,7 @@
   - `docs/design/02_Detailed_Design/12_REV_Detailed.md`
   - `docs/design/03_Technical_Design/03_Interface_Design.md`
   - `docs/design/03_Technical_Design/01_Database_Design.md`
-  - `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
+  - `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
   - `docs/design/00_Management/01_Project_Progress.md`
   - `docs/design/00_Management/03_Task_Checklist.md`
 - **Primary source of truth**:
@@ -21,7 +21,7 @@
   - `docs/design/03_Technical_Design/01_Database_Design.md`
   - `.specify/memory/constitution.md`
 - **Reference sources**:
-  - `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
+  - `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
   - `docs/design/00_Management/15_Legacy_Migration_Gap_Analysis.md`
   - `docs/design/04_Appendix/Archive/03_Design_Docs/营业收费管理系统-概要设计说明书20250912.md`
 - **Scope decision**: In scope。该需求属于既有 `REV-004` 模块范围内的账务处理一期收敛任务，允许在现有正式文档体系内补齐范围、接口、数据口径和执行约束，并输出后续实施计划所需的边界、任务拆解与验收依据；本轮不直接进入 backend 代码修改，不包含超出一期边界的新业务域扩展。

specs/001-rev004-accounting/tasks.md

@@ -27,7 +27,7 @@
 - [X] T001 Read prerequisite governance documents `docs/design/00_Management/01_Project_Progress.md`, `docs/design/00_Management/02_Delivery_Standards.md`, and `docs/design/00_Management/03_Task_Checklist.md` before formal document edits
 - [X] T002 Confirm target chapters and intended updates in `specs/001-rev004-accounting/spec.md`, `specs/001-rev004-accounting/plan.md`, `docs/design/02_Detailed_Design/12_REV_Detailed.md`, `docs/design/03_Technical_Design/03_Interface_Design.md`, and `docs/design/03_Technical_Design/01_Database_Design.md`
 - [X] T003 [P] Confirm source-of-truth and allowed references using `.specify/memory/constitution.md`, `docs/design/01_Overview/03_Summary_Design.md`, `docs/design/02_Detailed_Design/12_REV_Detailed.md`, `docs/design/03_Technical_Design/03_Interface_Design.md`, and `docs/design/03_Technical_Design/01_Database_Design.md`
-- [X] T004 [P] Confirm scope boundary, exclusions, traceability anchors, and impacted files in `specs/001-rev004-accounting/research.md`, `specs/001-rev004-accounting/contracts/rev004-scenario-matrix.md`, `specs/001-rev004-accounting/contracts/rev004-traceability-matrix.md`, and `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
+- [X] T004 [P] Confirm scope boundary, exclusions, traceability anchors, and impacted files in `specs/001-rev004-accounting/research.md`, `specs/001-rev004-accounting/contracts/rev004-scenario-matrix.md`, `specs/001-rev004-accounting/contracts/rev004-traceability-matrix.md`, and `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
 
 ---
 
@@ -46,16 +46,16 @@
 
 **Goal**: 在正式详细设计与执行手册中明确 REV-004 一期纳入范围、排除项、共性能力优先顺序与审批边界。
 
-**Independent Test**: 审阅者仅通过 `docs/design/02_Detailed_Design/12_REV_Detailed.md` 与 `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`，即可确认一期纳入场景、排除项、审批边界和“共性能力先统一、场景能力再分批”的组织方式一致。
+**Independent Test**: 审阅者仅通过 `docs/design/02_Detailed_Design/12_REV_Detailed.md` 与 `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`，即可确认一期纳入场景、排除项、审批边界和“共性能力先统一、场景能力再分批”的组织方式一致。
 
 ### Implementation for User Story 1
 
 - [X] T009 [US1] Update REV-004 一期范围、排除项、共性能力顺序和审批边界 in `docs/design/02_Detailed_Design/12_REV_Detailed.md`
-- [X] T010 [US1] Sync REV-004 执行范围、验收入口和后续实施组织方式 in `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
+- [X] T010 [US1] Sync REV-004 执行范围、验收入口和后续实施组织方式 in `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
 - [X] T011 [P] [US1] Sync REV-004 一期范围摘要 and cross-references in `docs/design/01_Overview/03_Summary_Design.md`
 - [X] T012 [US1] Update traceability note for scoped scenarios in `specs/001-rev004-accounting/contracts/rev004-traceability-matrix.md`
 - [X] T013 [US1] Run `make validate-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md` and capture result for `docs/design/02_Detailed_Design/12_REV_Detailed.md`
-- [X] T014 [US1] Run `make validate-file FILE=docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md` and capture result for `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
+- [X] T014 [US1] Run `make validate-file FILE=docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md` and capture result for `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
 - [X] T015 [US1] Run `make check-links` and capture cross-document link result for US1 file changes
 - [X] T016 [US1] Update important progress note in `docs/design/00_Management/01_Project_Progress.md` if US1 produces an important formal document change after validation passes
 - [X] T017 [US1] Update REV-004 scope task status in `docs/design/00_Management/03_Task_Checklist.md` if US1 completes a tracked task or materially changes its closure condition
@@ -93,16 +93,16 @@
 
 **Goal**: 在执行手册与管理台账中固化 REV-004 的后续实施顺序、验收入口、最小校验动作与台账更新触发条件。
 
-**Independent Test**: 审阅者仅通过 `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`、`docs/design/00_Management/01_Project_Progress.md` 与 `docs/design/00_Management/03_Task_Checklist.md`，即可确认 REV-004 后续 tasks 的拆解依据、验收入口、最小校验动作和台账同步方式已经明确。
+**Independent Test**: 审阅者仅通过 `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`、`docs/design/00_Management/01_Project_Progress.md` 与 `docs/design/00_Management/03_Task_Checklist.md`，即可确认 REV-004 后续 tasks 的拆解依据、验收入口、最小校验动作和台账同步方式已经明确。
 
 ### Implementation for User Story 3
 
-- [X] T030 [US3] Update REV-004 execution sequence, independent acceptance entry, and validation steps in `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
+- [X] T030 [US3] Update REV-004 execution sequence, independent acceptance entry, and validation steps in `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
 - [X] T031 [US3] Record REV-004 planning milestone and next-step entry in `docs/design/00_Management/01_Project_Progress.md` if US3 forms an important governance or formal delivery milestone
 - [X] T032 [US3] Update REV-004 tracked checklist items and completion criteria in `docs/design/00_Management/03_Task_Checklist.md` if US3 completes or materially redefines a tracked task
 - [X] T033 [P] [US3] Sync quick review and validation wording in `specs/001-rev004-accounting/quickstart.md`
 - [X] T034 [P] [US3] Sync task-splitting and closure assumptions in `specs/001-rev004-accounting/plan.md`
-- [X] T035 [US3] Run `make validate-file FILE=docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md` and capture result for execution playbook changes
+- [X] T035 [US3] Run `make validate-file FILE=docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md` and capture result for execution playbook changes
 - [X] T036 [US3] Run `make validate-file FILE=docs/design/00_Management/01_Project_Progress.md` and capture result for project progress changes
 - [X] T037 [US3] Run `make validate-file FILE=docs/design/00_Management/03_Task_Checklist.md` and capture result for task checklist changes
 - [X] T038 [US3] Run `make check-links` and capture cross-document link result for US3 file changes
@@ -115,7 +115,7 @@
 
 **Purpose**: Ensure repository-wide consistency after all story slices are complete.
 
-- [X] T039 [P] Re-check source-of-truth alignment across `docs/design/02_Detailed_Design/12_REV_Detailed.md`, `docs/design/03_Technical_Design/03_Interface_Design.md`, `docs/design/03_Technical_Design/01_Database_Design.md`, and `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
+- [X] T039 [P] Re-check source-of-truth alignment across `docs/design/02_Detailed_Design/12_REV_Detailed.md`, `docs/design/03_Technical_Design/03_Interface_Design.md`, `docs/design/03_Technical_Design/01_Database_Design.md`, and `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`
 - [X] T040 [P] Re-check relative links, traceability rows, and Mermaid consistency across `docs/design/01_Overview/03_Summary_Design.md`, `docs/design/00_Management/01_Project_Progress.md`, `docs/design/00_Management/03_Task_Checklist.md`, and `specs/001-rev004-accounting/contracts/rev004-traceability-matrix.md`
 - [X] T041 Prepare final change summary with modified files, validation results, remaining risks, and next-step suggestions in the final response for `/specs/001-rev004-accounting/tasks.md`
 
@@ -160,7 +160,7 @@
 
 ```text
 # After T009 completes, run in parallel:
-- T010 Update docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md
+- T010 Update docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md
 - T011 Update docs/design/01_Overview/03_Summary_Design.md
 ```
 
@@ -186,7 +186,7 @@
 
 ### MVP First (User Story 1 only)
 
-先完成 US1，把 REV-004 一期范围、排除项、审批边界和共性能力顺序稳定下来。只要 `docs/design/02_Detailed_Design/12_REV_Detailed.md` 与 `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md` 已可独立评审并完成最小校验，就可以形成第一版可评审增量。
+先完成 US1，把 REV-004 一期范围、排除项、审批边界和共性能力顺序稳定下来。只要 `docs/design/02_Detailed_Design/12_REV_Detailed.md` 与 `docs/evidence/rev004-accounting/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md` 已可独立评审并完成最小校验，就可以形成第一版可评审增量。
 
 ### Incremental Delivery
 

specs/002-rev005-invoice-flow/contracts/if-rev-008-invoice-application.md

@@ -1,68 +0,0 @@
-# Contract: IF-REV-008 发票申请接口
-
-## 1. 合同定位
-
-本合同用于固化 REV-005 一期后台发票申请 / 单笔与批量开票接口口径，服务于后续正式接口文档修订、任务拆解与 backend 实施。
-
-## 2. 适用范围
-
-适用场景：
-- 后台营业收费员 / 财务人员发起单笔开票
-- 后台按已收费账单集合批量发起开票
-- 生成发票申请记录并提交 `SYS-008`
-
-不适用范围：
-- 客户侧直接申请开票
-- 原始单账单直接任意部分金额开票
-- 复杂拆分/合并开票策略配置
-
-## 3. 请求合同
-
-| 字段 | 类型 | 必填 | 说明 | 约束 |
-|------|------|------|------|------|
-| applicationNo | String | 否 | 发票申请单号 | 服务端生成，作为幂等主键之一 |
-| chargeIds | Array<Long> | 是 | 关联账单 ID 列表 | 所有账单必须已收费且未开票 |
-| custId | Long | 是 | 客户 ID | 必须存在可用开票信息 |
-| invoiceType | String | 是 | 发票类型 | `ELECTRONIC` / `PAPER` |
-| invoiceTitle | String | 是 | 发票抬头 | 来自 `biz_cust_invoice` 或后台确认输入 |
-| taxNo | String | 否 | 纳税人识别号 | 企业抬头场景建议必填 |
-| email | String | 否 | 接收邮箱 | 电子发票场景优先使用 |
-| mobile | String | 否 | 接收手机号 | 推送或通知场景使用 |
-| sourceChannel | String | 是 | 来源渠道 | `COUNTER` / `FINANCE_BACKOFFICE` |
-| remark | String | 否 | 申请备注 | 进入操作留痕 |
-
-## 4. 响应合同
-
-| 字段 | 类型 | 说明 | 约束 |
-|------|------|------|------|
-| invoiceId | Long | 发票申请记录 ID | 对应 `biz_invoice.id` |
-| applicationNo | String | 发票申请单号 | 后续查询与幂等主键 |
-| invoiceStatus | String | 当前状态 | `SUBMITTED` / `PENDING` / `REJECTED` |
-| sysRequestNo | String | `SYS-008` 受理号 | 异步查询主键 |
-| msg | String | 处理说明 | 不可开票时返回明确原因 |
-
-## 5. 共性规则
-
-1. 所有账单必须处于“已收费、未开票、未作废”状态。
-2. 一期不支持对原始单账单直接任意部分金额开票。
-3. 如需多张发票，需来源于拆账/分账后的账单集合。
-4. 幂等控制可采用 `applicationNo` 或 `custId + chargeIds` 组合。
-5. 申请成功后必须生成查询补偿任务，不可依赖回调作为唯一结果来源。
-6. 所有申请动作必须写入操作留痕。
-
-## 6. 物理承接口径
-
-| 逻辑对象 | 物理承接 |
-|---------|----------|
-| 发票申请主对象 | `biz_invoice` |
-| 客户开票信息 | `biz_cust_invoice` |
-| 税率配置 | `biz_invoice_taxrate` |
-| 关联账单 | `biz_charge*` |
-| 操作留痕 | `biz_operat_log*` |
-
-## 7. 验收关注点
-
-- 是否支持后台单笔 / 批量已收费账单开票
-- 是否拒绝原始单账单直接部分金额开票
-- 是否生成申请单号与查询主键
-- 是否与 `SYS-008` 查询兜底模式一致

specs/002-rev005-invoice-flow/contracts/if-rev-009-invoice-query.md

@@ -1,65 +0,0 @@
-# Contract: IF-REV-009 发票结果查询与客户侧消费接口
-
-## 1. 合同定位
-
-本合同用于固化 REV-005 一期发票结果查询、查询兜底补偿以及客户侧查看/下载/推送已开票电子发票的统一口径。
-
-## 2. 适用范围
-
-适用场景：
-- 后台按申请单号 / 受理号查询发票最终状态
-- 系统定时轮询 `SYS-008` 获取开票结果
-- 客户侧查看已开具电子发票
-- 客户侧下载、推送电子发票
-
-不适用范围：
-- 客户侧直接发起开票申请
-- 发票作废 / 红冲全流程深度处理
-
-## 3. 查询请求合同
-
-| 字段 | 类型 | 必填 | 说明 | 约束 |
-|------|------|------|------|------|
-| applicationNo | String | 否 | 发票申请单号 | 与 `sysRequestNo` 二选一 |
-| sysRequestNo | String | 否 | 外部受理号 | 与 `applicationNo` 二选一 |
-| custId | Long | 否 | 客户 ID | 客户侧查询时使用 |
-| querySource | String | 是 | 查询来源 | `SYSTEM_JOB` / `ADMIN` / `CUSTOMER` |
-| pushEmail | String | 否 | 推送邮箱 | 客户侧推送时使用 |
-
-## 4. 查询响应合同
-
-| 字段 | 类型 | 说明 | 约束 |
-|------|------|------|------|
-| invoiceId | Long | 发票记录 ID | 对应 `biz_invoice.id` |
-| applicationNo | String | 发票申请单号 | 幂等主键 |
-| invoiceStatus | String | 发票状态 | `PENDING` / `SUCCESS` / `FAIL` / `INVALID` / `RED_INK` |
-| invoiceCode | String | 发票代码 | 成功后返回 |
-| invoiceNumber | String | 发票号码 | 成功后返回 |
-| fileUrl | String | 电子票下载地址 | 成功后返回 |
-| failReason | String | 失败原因 | 失败时返回 |
-| pushStatus | String | 推送状态 | `NONE` / `PUSHED` / `FAIL` |
-| lastQueryTime | DateTime | 最近查询时间 | 用于补偿追踪 |
-
-## 5. 共性规则
-
-1. 查询兜底是开票结果获取的必备路径，不可省略。
-2. 已成功开票状态不得被后续失败结果覆盖。
-3. 客户侧只允许查询、下载、推送属于当前客户的已开票电子发票。
-4. 下载/推送前必须校验发票状态为 `SUCCESS` 且存在 `fileUrl`。
-5. 查询补偿任务需记录 `lastTryTime`、`nextTryTime`、`tryCount` 等信息。
-
-## 6. 物理承接口径
-
-| 逻辑对象 | 物理承接 |
-|---------|----------|
-| 发票结果主对象 | `biz_invoice` |
-| 客户查询身份与资料 | `biz_cust_invoice` |
-| 查询补偿与结果留痕 | `biz_invoice` 扩展字段 + `biz_operat_log*` |
-| 账单发票摘要展示 | `biz_charge*` + 历史关系快照 |
-
-## 7. 验收关注点
-
-- 是否支持后台按申请单号 / 受理号查询结果
-- 是否支持系统任务轮询补偿
-- 是否支持客户侧查看、下载、推送已开票电子发票
-- 是否避免客户侧越权查询和重复推送

specs/002-rev005-invoice-flow/data-model.md

@@ -1,170 +0,0 @@
-# Data Model: REV-005 发票业务流实现
-
-## 建模原则
-
-- 以“逻辑实体 + 现有在线主表承接 + 历史关系快照”三层表达，避免把旧系统全部 IV_* 细表误写为当前已落地在线表。
-- 后台开票、客户侧查询下载、`SYS-008` 查询兜底、结果回写统一围绕单一发票申请主线建模。
-- 一期不支持原始单账单直接任意部分开票，但关系模型需兼容拆账/分账后的多账单、多发票映射扩展。
-
-## 实体一：InvoiceApplication（发票申请单）
-
-### 作用
-统一承接后台单笔/批量已收费账单的发票申请输入，是 `IF-REV-008` 的主业务对象。
-
-### 核心字段
-
-| 字段 | 类型 | 说明 |
-|------|------|------|
-| applicationNo | String | 发票申请单号 / 协同请求号 |
-| chargeIds | Array<Long> | 关联账单 ID 列表 |
-| custId | Long | 客户 ID |
-| invoiceType | Enum | `ELECTRONIC` / `PAPER` |
-| invoiceTitle | String | 发票抬头 |
-| taxNo | String | 纳税人识别号 |
-| invoiceAmount | Decimal | 本次申请开票总金额 |
-| receiverEmail | String | 电子票接收邮箱 |
-| receiverMobile | String | 电子票接收手机号 |
-| sourceChannel | Enum | `COUNTER` / `FINANCE_BACKOFFICE` |
-| applyStatus | Enum | `SUBMITTED` / `ACCEPTED` / `REJECTED` |
-| appliedAt | DateTime | 申请时间 |
-
-### 校验规则
-- `chargeIds`、`custId`、`invoiceType`、`invoiceTitle` 必填。
-- 账单必须满足“已收费、未开票、未作废”。
-- 原始单账单不允许直接任意部分金额开票；如需多张发票应来源于拆账/分账后的账单集合。
-- 对同一账单组合的重复申请需按 `applicationNo` 或 `custId + chargeIds` 做幂等控制。
-
-### 物理承接
-- 主承接：`biz_invoice`
-- 关联输入：`biz_cust_invoice`、`biz_charge*`
-
-## 实体二：InvoiceRecord（发票记录）
-
-### 作用
-描述发票服务受理、开具成功/失败、票号回写、电子票文件地址等结果信息。
-
-### 核心字段
-
-| 字段 | 类型 | 说明 |
-|------|------|------|
-| invoiceId | Long | 发票记录 ID |
-| applicationNo | String | 对应申请单号 |
-| sysRequestNo | String | `SYS-008` 受理号 / 外部请求号 |
-| invoiceStatus | Enum | `PENDING` / `SUCCESS` / `FAIL` / `INVALID` / `RED_INK` |
-| invoiceCode | String | 发票代码 |
-| invoiceNumber | String | 发票号码 |
-| invoiceDate | DateTime | 开票日期 |
-| fileUrl | String | 电子发票下载地址 |
-| failReason | String | 开票失败原因 |
-| pushStatus | Enum | `NONE` / `PUSHED` / `FAIL` |
-| updatedAt | DateTime | 最近状态更新时间 |
-
-### 状态关系
-- `PENDING` 表示已提交给 `SYS-008` 但尚未确认最终结果。
-- `SUCCESS` 后允许客户侧查询、下载、推送电子发票。
-- `FAIL` 记录失败原因并进入异常核查或人工重试。
-
-### 物理承接
-- 主承接：`biz_invoice`
-- 历史参照：旧 `IV_INVOICE_INFOS`
-
-## 实体三：ChargeInvoiceRelation（账单-发票关联）
-
-### 作用
-承接账单与发票的映射关系，支持单票对应多账单、拆账后分别开票和后续合并开票扩展。
-
-### 核心字段
-
-| 字段 | 类型 | 说明 |
-|------|------|------|
-| relationId | Long | 关联记录 ID |
-| chargeId | Long | 账单 ID |
-| invoiceId | Long | 发票 ID |
-| applicationNo | String | 申请单号 |
-| relationType | Enum | `FULL_AMOUNT` / `SPLIT_BILL` / `MERGED_BILL` |
-| invoiceAmount | Decimal | 当前账单对应开票金额 |
-| relationStatus | Enum | `PENDING` / `BOUND` / `FAILED` |
-| snapshotVersion | String | 开票配置/税率快照版本 |
-
-### 关键规则
-- 一期默认 `relationType=FULL_AMOUNT` 或 `SPLIT_BILL`（来自拆账后的账单），不支持对原始单账单直接自由部分金额开票。
-- 发票成功后必须把关系状态更新为 `BOUND`，并可供账单详情查询。
-
-### 物理承接
-- 在线主承接：`biz_invoice` + 历史关系快照
-- 历史参照：旧 `IV_CHARGE_INVOICES`、`IV_CHARGE_INVOICE_MAPPINGS`
-
-## 实体四：InvoiceQueryTask（开票查询补偿任务）
-
-### 作用
-支持异步申请后的轮询查询、超时补偿和人工兜底查询，是“查询兜底”模式的核心对象。
-
-### 核心字段
-
-| 字段 | 类型 | 说明 |
-|------|------|------|
-| queryTaskId | Long | 查询任务 ID |
-| applicationNo | String | 申请单号 |
-| sysRequestNo | String | 外部受理号 |
-| lastTryTime | DateTime | 最后一次查询时间 |
-| nextTryTime | DateTime | 下一次查询时间 |
-| tryCount | Integer | 已查询次数 |
-| queryStatus | Enum | `WAITING` / `RUNNING` / `DONE` / `FAILED` |
-| latestResult | String | 最近一次查询结果摘要 |
-| latestError | String | 最近一次查询错误 |
-
-### 关键规则
-- 申请成功后默认生成查询任务。
-- 查询到终态后任务进入 `DONE`。
-- 查询异常不应覆盖已成功开票状态，只记录异常并等待人工或系统补偿。
-
-### 物理承接
-- 主承接：`biz_invoice` 扩展字段或关联查询日志对象
-- 历史参照：旧发票表中的 `last_try_time`、`next_try_time`、`try_count`
-
-## 实体五：InvoiceResultWriteBack（结果回写）
-
-### 作用
-统一描述 `SYS-008` 查询结果或主动回传结果进入营收域后的状态变更、幂等控制和操作留痕。
-
-### 核心字段
-
-| 字段 | 类型 | 说明 |
-|------|------|------|
-| writeBackNo | String | 回写流水号 |
-| applicationNo | String | 申请单号 |
-| invoiceStatus | Enum | 发票状态 |
-| writeBackStatus | Enum | `SUCCESS` / `IGNORE_REPEAT` / `FAIL` |
-| invoiceCode | String | 发票代码 |
-| invoiceNumber | String | 发票号码 |
-| fileUrl | String | 下载地址 |
-| rawPayload | String | 原始回写/查询响应 |
-| processedAt | DateTime | 处理时间 |
-| processedBy | String | 系统任务 / 人工处理人 |
-
-### 关键规则
-- 按 `applicationNo + invoiceStatus` 做幂等控制。
-- 已成功开票后收到失败结果，不覆盖成功状态，转入异常核查。
-- 所有回写处理必须记录到操作留痕对象。
-
-### 物理承接
-- 主承接：`biz_invoice` + `biz_operat_log*`
-
-## 关系总览
-
-```text
-InvoiceApplication --> InvoiceRecord
-InvoiceApplication --> ChargeInvoiceRelation
-InvoiceApplication --> InvoiceQueryTask
-InvoiceRecord --> InvoiceResultWriteBack
-ChargeInvoiceRelation --> biz_charge* (N:1)
-InvoiceApplication --> biz_cust_invoice
-InvoiceApplication --> biz_invoice_taxrate
-InvoiceResultWriteBack --> biz_operat_log*
-```
-
-## 状态与边界说明
-
-- 一期默认后台申请、客户侧结果消费，不定义客户侧直接申请状态机。
-- 作废、红冲作为 REV-005 后续能力保留在数据模型中，但 implement 时优先保证正常开票闭环。
-- 旧发票明细、营业账开票关系、配置快照对象在当前阶段仅作为历史参照和追溯来源，不表述为已确认新增在线独立表。

specs/003-rev006-reminder-event-design/data-model.md

@@ -1,159 +1,125 @@
-# Data Model: REV-006 催缴事件与通知协同设计
+# Data Model: REV-006 催缴与通知事件设计收口
 
 ## 1. Reminder Candidate
 
-### Purpose
+**说明**: 催缴任务的输入对象，由欠费账单和客户上下文组合形成。  
 
-表示进入催缴评估范围的欠费账单或客户对象集合，是催缴任务生成的输入对象。
+| 字段 | 类型 | 说明 | 约束 |
+|------|------|------|------|
+| candidateId | String | 候选对象标识 | 可由任务生成阶段派生，不要求独立持久化主键 |
+| custId | String | 客户标识 | 必填 |
+| accountId | String | 账户标识 | 必填 |
+| chargeIds | List<String> | 命中的欠费账单集合 | 至少 1 条 |
+| billPeriods | List<String> | 账期集合 | 必填 |
+| arrearsAmount | Decimal | 欠费总金额 | 必须大于 0 |
+| agingBucket | String | 账龄分组 | 必填 |
+| custCategory | String | 客户类别 | 必填 |
+| preferredChannels | List<String> | 渠道偏好 | 至少 1 个渠道 |
+| strategyCode | String | 命中的催缴策略编码 | 必填 |
+| frequencyWindow | String | 频控窗口 | 用于重复触达拦截 |
 
-### Key Fields
+**关系**:
 
-| Field | Description | Rule |
-|---|---|---|
-| `custId` | 客户标识 | 必填；关联客户主档 |
-| `chargeId` | 账单标识 | 必填；关联欠费账单 |
-| `billPeriod` | 账期 | 必填；用于催缴分组和历史查询 |
-| `arrearsAmount` | 欠费金额 | 必填；用于策略匹配 |
-| `agingBucket` | 欠费账龄分组 | 必填；用于策略筛选 |
-| `customerCategory` | 客户类别 | 必填；用于差异化催缴 |
-| `contactChannelSet` | 可用联系方式集合 | 至少存在一个有效触达渠道 |
-| `strategyCode` | 命中的催缴策略编码 | 必填；来源于策略规则 |
-
-### Relationships
-
-- 来自 `biz_charge` / `biz_charge_detail`
-- 关联客户主档与联系方式
-- 可生成一个或多个 `Reminder Task`
+- 一个 `Reminder Candidate` 可生成一个或多个 `Reminder Task`
+- `Reminder Candidate` 来源于 `biz_charge`、`biz_charge_detail` 等营业账对象
 
 ## 2. Reminder Strategy
 
-### Purpose
+**说明**: 约束候选对象筛选、任务分组和渠道优先级的规则集合。  
 
-定义催缴对象筛选、任务分组、触达渠道和频控约束的业务规则。
+| 字段 | 类型 | 说明 | 约束 |
+|------|------|------|------|
+| strategyCode | String | 策略编码 | 唯一 |
+| strategyName | String | 策略名称 | 必填 |
+| agingRule | String | 账龄规则 | 必填 |
+| amountRule | String | 金额规则 | 必填 |
+| custCategoryRule | String | 客户类别规则 | 可为空，表示不限 |
+| channelPriority | List<String> | 渠道优先级 | 至少 1 项 |
+| frequencyControl | String | 频控规则 | 必填 |
+| disposalAttentionFlag | Boolean | 是否关注后续处置 | 必填 |
 
-### Key Fields
+**状态转换**:
 
-| Field | Description | Rule |
-|---|---|---|
-| `strategyCode` | 策略编码 | 唯一 |
-| `agingRule` | 账龄匹配规则 | 必填 |
-| `amountRule` | 金额匹配规则 | 必填 |
-| `customerCategoryRule` | 客户类别匹配规则 | 可为空；为空表示通用 |
-| `channelPriority` | 触达渠道优先级 | 必填；至少 1 个渠道 |
-| `dedupeWindow` | 重复触达拦截窗口 | 必填 |
-| `escalationFlag` | 是否触发后续处置关注 | 必填 |
-
-### Relationships
-
-- 一个 `Reminder Strategy` 可匹配多个 `Reminder Candidate`
-- 一个 `Reminder Strategy` 可驱动多个 `Reminder Task`
+- 启用
+- 停用
 
 ## 3. Reminder Task
 
-### Purpose
+**说明**: 正式催缴执行单元，是 `IF-REV-013` 的核心业务对象。  
 
-表示一次正式催缴执行单元，负责承接业务触发、协同下发和结果回写。
+| 字段 | 类型 | 说明 | 约束 |
+|------|------|------|------|
+| taskNo | String | 催缴任务号 | 唯一、必填 |
+| eventNo | String | 业务事件号 | 唯一、必填 |
+| strategyCode | String | 策略编码 | 必填 |
+| channelType | String | 执行渠道 | 必填 |
+| triggerType | String | 触发类型 | 自动 / 人工 |
+| status | String | 当前状态 | 仅允许 `PENDING` / `SUCCESS` / `FAIL` / `MANUAL_VERIFIED` |
+| chargeIds | List<String> | 关联账单 | 至少 1 条 |
+| receiver | String | 触达对象 | 可为手机号、微信标识或站内账号 |
+| sendTime | Datetime | 发送发起时间 | 可空，待触发后填写 |
+| lastCallbackTime | Datetime | 最近结果回写时间 | 可空 |
+| failReason | String | 失败原因 | `FAIL` 时建议记录 |
+| manualVerifyNote | String | 人工核查说明 | `MANUAL_VERIFIED` 时建议记录 |
 
-### Key Fields
+**状态转换**:
 
-| Field | Description | Rule |
-|---|---|---|
-| `taskNo` | 催缴任务号 | 唯一；正式业务主键 |
-| `interfaceCode` | 正式接口编号 | 固定使用 `IF-REV-013` |
-| `eventNo` | 业务事件号 | 唯一；用于与 `SYS-010` 协同 |
-| `custId` | 客户标识 | 必填 |
-| `chargeId` | 账单标识 | 必填 |
-| `strategyCode` | 策略编码 | 必填 |
-| `channelType` | 触达渠道 | 必填；短信/微信公众号/站内信等 |
-| `triggerType` | 触发方式 | 必填；自动/人工 |
-| `status` | 当前任务状态 | 必填；`PENDING` / `SUCCESS` / `FAIL` / `MANUAL_VERIFIED` |
-| `sourceType` | 任务来源 | 必填；系统任务/人工补发/核查回补 |
-| `createdTime` | 创建时间 | 必填 |
-| `lastResultTime` | 最近结果时间 | 可为空；初次发送前为空 |
-
-### State Transitions
-
-| From | To | Condition |
-|---|---|---|
-| 新建 | `PENDING` | 已生成任务并发起协同 |
-| `PENDING` | `SUCCESS` | 收到成功回写 |
-| `PENDING` | `FAIL` | 收到失败回写或确认失败 |
-| `PENDING` | `MANUAL_VERIFIED` | 人工核查后确认结果 |
-| `FAIL` | `MANUAL_VERIFIED` | 人工核查补记结果 |
-
-### Relationships
-
-- 由一个 `Reminder Candidate` 和一个 `Reminder Strategy` 组合产生
-- 关联一个或多个 `Reminder Result`
-- 可关联一个 `Disposal Link`
+1. 新建任务后进入 `PENDING`
+2. 外部触达成功后进入 `SUCCESS`
+3. 外部明确失败后进入 `FAIL`
+4. 外部结果长期未定或人工补记后进入 `MANUAL_VERIFIED`
 
 ## 4. Reminder Result
 
-### Purpose
+**说明**: 承接 `SYS-010` 回写结果与业务侧最终状态语义。  
 
-表示 `SYS-010` 回传或人工核查得到的触达结果。
+| 字段 | 类型 | 说明 | 约束 |
+|------|------|------|------|
+| taskNo | String | 对应任务号 | 必填 |
+| eventNo | String | 对应事件号 | 必填 |
+| status | String | 四态结果 | 必填 |
+| channelType | String | 渠道类型 | 必填 |
+| externalResultCode | String | 外部结果码 | 可空 |
+| externalResultMessage | String | 外部结果说明 | 可空 |
+| failReason | String | 业务失败原因 | `FAIL` 时可必填 |
+| callbackTime | Datetime | 回写时间 | 必填 |
+| sourceSystem | String | 回写来源系统 | 默认 `SYS-010` |
 
-### Key Fields
+## 5. Disposal Link
 
-| Field | Description | Rule |
-|---|---|---|
-| `eventNo` | 业务事件号 | 必填；与 `Reminder Task` 对应 |
-| `status` | 结果状态 | 必填；仅允许四态 |
-| `failureReason` | 失败原因 | `FAIL` 时必填 |
-| `resultChannel` | 实际触达渠道 | 必填 |
-| `resultTime` | 结果时间 | 必填 |
-| `verifiedBy` | 核查人 | `MANUAL_VERIFIED` 时必填 |
-| `verifiedNote` | 核查说明 | `MANUAL_VERIFIED` 时建议填写 |
+**说明**: 催缴任务与停水、复水、工单、人工跟进之间的追溯引用。  
 
-### Relationships
+| 字段 | 类型 | 说明 | 约束 |
+|------|------|------|------|
+| taskNo | String | 关联催缴任务号 | 必填 |
+| disposalType | String | 处置类型 | 停水 / 复水 / 工单 / 人工跟进 |
+| disposalRefNo | String | 处置引用号 | 必填 |
+| disposalStatus | String | 处置状态摘要 | 可空 |
+| linkedAt | Datetime | 建联时间 | 必填 |
+| note | String | 追溯说明 | 可空 |
 
-- 归属于一个 `Reminder Task`
-- 结果会回写到任务状态与历史查询记录
+## 6. Governance Record
 
-## 5. Reminder History Record
+**说明**: 用于治理台账登记本轮设计收口结论与后续研发建议。  
 
-### Purpose
+| 字段 | 类型 | 说明 | 约束 |
+|------|------|------|------|
+| reqCode | String | 需求编号 | 固定为 `SYS002-REQ-011` |
+| featureName | String | Speckit feature 名称 | 固定为 `rev003-rev006-reminder-event-design` |
+| implementationStatus | String | 当前实现判断 | `未见实现` |
+| docStatus | String | 文档状态 | 设计已收口 / 待同步 / 待验证 |
+| nextAction | String | 后续动作 | 研发立项 / 文档补证 / 治理同步 |
+| evidenceRefs | List<String> | 证据来源 | 必填 |
 
-为历史查询和迁移验收提供最小保留信息集合。
+## 7. 关系总览
 
-### Key Fields
-
-| Field | Description | Rule |
-|---|---|---|
-| `custId` | 客户标识 | 必填 |
-| `billPeriod` | 账期 | 必填 |
-| `channelType` | 催缴方式 | 必填 |
-| `messageContentRef` | 触达内容引用 | 必填；可为模板或摘要引用 |
-| `receiver` | 接收目标 | 必填；手机号/OpenID/站内信对象 |
-| `status` | 执行结果 | 必填；使用四态或历史映射值 |
-| `sendTime` | 发送时间 | 必填 |
-| `operatorSource` | 操作来源 | 必填；自动/人工/历史迁移 |
-| `relatedChargeId` | 关联账单 | 必填 |
-| `relatedDisposalRef` | 关联处置引用 | 可为空；用于停复水/工单追溯 |
-
-### Relationships
-
-- 可由 `Reminder Task` 和 `Reminder Result` 聚合生成
-- 同时承接历史催缴记录、停水记录、预存短信记录的查询口径
-
-## 6. Disposal Link
-
-### Purpose
-
-记录催缴结果与停水、复水、工单或人工处置之间的追溯关系。
-
-### Key Fields
-
-| Field | Description | Rule |
-|---|---|---|
-| `eventNo` | 关联业务事件号 | 必填 |
-| `disposalType` | 处置类型 | 必填；停水/复水/工单/人工跟进 |
-| `triggerCondition` | 触发条件摘要 | 必填 |
-| `disposalRefNo` | 下游处置引用号 | 可为空；未创建时为空 |
-| `disposalStatus` | 下游处置状态 | 可为空；仅作追溯，不定义内部流程 |
-| `linkedTime` | 建立关联时间 | 必填 |
-
-### Relationships
-
-- 一个 `Reminder Task` 最多关联一个当前生效的 `Disposal Link`
-- 不替代下游业务对象，只做引用和追溯
+```text
+Reminder Strategy
+  -> Reminder Candidate
+  -> Reminder Task
+Reminder Task
+  -> Reminder Result
+  -> Disposal Link
+Governance Record
+  -> 引用 Reminder Task / Reminder Result 的设计结论与实现判断
+```

specs/003-rev006-reminder-event-design/plan.md

@@ -1,109 +1,108 @@
-# Implementation Plan: REV-006 催缴事件与通知协同设计
+# Plan: REV-006 催缴与通知事件设计收口
 
-**Branch**: `003-rev006-reminder-event-design` | **Date**: 2026-03-18 | **Spec**: [/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/spec.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/spec.md)
-**Input**: Feature specification from `/specs/003-rev006-reminder-event-design/spec.md`
-
-**Note**: This template is filled in by the `/speckit.plan` command. See `.specify/templates/plan-template.md` for the execution workflow.
+**Branch**: `003-rev003-rev006-reminder-event-design` | **Date**: 2026-03-19 | **Spec**: [spec.md](./spec.md)
+**Input**: Feature specification from `/specs/003-rev003-rev006-reminder-event-design/spec.md`（合并自 `003` 与 `006` 双会话）
 
 ## Summary
 
-本 feature 用于补齐 `REV-006` 在正式文档体系中的设计闭环，重点收口催缴对象生成、催缴任务触发、`SYS-010` 消息协同结果回写、停复水联动边界以及历史查询最小保留集。实施方式以修订既有主文档和治理台账为主，不进入 backend 代码实现；同时将现有接口冲突纠正为 `REV-006` 使用新的独立正式接口编号，发票查询继续保留 `IF-REV-009`。
+本计划将 `REV-006` 催缴与通知事件的正式设计收口拆分为 4 个可验证的阶段：详细设计主文档对齐、接口与协同边界文档化、治理同步和实现切入点评估。每个阶段完成后需通过独立的文档校验和台账回写。
 
-## Technical Context
+## Technical Approach
 
-<!--
-  ACTION REQUIRED: Replace this section with the real project context.
-  For this repository, prefer documenting document-system context rather than
-  inventing software implementation context.
--->
-
-**Primary Work Product**: Markdown 设计文档、接口/数据库专题文档、管理台账文档
-**Source of Truth Documents**:
- - `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md`
- - `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/03_Interface_Design.md`
- - `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/01_Database_Design.md`
- - `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/04_Writing_Guide.md`
- - `/Volumes/Dpan/github/fujian_water_biz_doc/AGENTS.md`
-**Reference Sources**:
- - `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
- - `/Volumes/Dpan/github/fujian_water_biz_doc/docs/guides/BACKEND_CURRENT_STATUS.md`
- - `/Volumes/Dpan/github/fujian_water_biz_doc/docs/guides/BACKEND_TABLE_MAPPING.md`
- - `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/04_Appendix/Archive/05_Data_Dictionary/营收数据字典.md`
- - `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/04_Appendix/Archive/01_Requirements/`
-**Validation Commands**:
- - `make validate-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md`
- - `make validate-file FILE=docs/design/03_Technical_Design/03_Interface_Design.md`
- - `make validate-file FILE=docs/design/03_Technical_Design/01_Database_Design.md`
- - `make validate-file FILE=docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
- - `make validate-file FILE=docs/design/00_Management/01_Project_Progress.md`
- - `make validate-file FILE=docs/design/00_Management/03_Task_Checklist.md`
- - `make check-links`
-**Target Scope**:
- - `12_REV_Detailed.md` 中 `REV-006` 正文、流程、规则、落地边界
- - `03_Interface_Design.md` 中 `REV-006` 与 `SYS-010` 的接口编号、接口定义、时序、映射表、异常码、幂等策略
- - `01_Database_Design.md` 中催缴/停复水/预存短信历史只读口径与在线主模型承接边界
- - `15_SYS002_Requirement_Breakdown.md` 中实现评估和 Story/Task 建议
- - `01_Project_Progress.md`、`03_Task_Checklist.md` 的治理回写
-**Project Type**: 文档治理仓库
-**Constraints**:
- - 不新增平行正式主稿，所有正式内容回写既有主文档
- - 不臆造 backend 已实现事实，只能写“已实现 / 部分实现 / 文档先行 / 历史只读”
- - 仓库内引用保持相对路径
- - 停复水只定义联动边界，不展开内部处置流程
- - `REV-006` 必须使用独立正式接口编号，不再复用 `IF-REV-009`
- - 催缴结果状态固定为 `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED`
-**Scale/Scope**: 跨文档专题收口，涉及详细设计、接口设计、数据库设计与治理台账四类文档
+- **Design-first, implementation-later**: 本轮仅收口正式设计文档，不在 backend 中新增业务代码。
+- **Single source of truth**: 所有修订回写到 `docs/design/` 主文档，不创建平行版本。
+- **Contract-driven**: 以 `contracts/if-rev-013.md` 和 `contracts/if-ext-008.md` 作为接口协同边界契约，驱动正式接口文档修订。
+- **Gated by validation**: 每次文档修订后必须执行 `make validate-file`、`make check-links`、`make validate-mermaid` 中适用的校验命令。
 
 ## Constitution Check
 
-*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
-
-- [x] **主文档归属已确认**：改动落点限定为 `12_REV_Detailed.md`、`03_Interface_Design.md`、`01_Database_Design.md` 与治理台账，不新增平行正式稿。
-- [x] **范围基线已确认**：`REV-006` 已存在于 `03_Summary_Design.md`、`12_REV_Detailed.md` 和 `15_SYS002_Requirement_Breakdown.md`，本轮仅补齐既有范围内的设计与接口口径，不引入超范围新模块。
-- [x] **Archive 使用方式合规**：Archive 仅用于核对旧“催缴记录/停水记录/预存短信”来源与历史只读口径，不直接作为正式结论输出。
-- [x] **一致性影响已列出**：受影响项包括 `REV-006` 接口编号、结果状态术语、催缴/停复水边界、历史只读查询口径、时序图与映射表。
-- [x] **校验与台账动作已规划**：已规划单文件校验、链接校验，并要求同步更新 `01_Project_Progress.md` 与 `03_Task_Checklist.md`。
+- **Single source of truth**: ✅ 只编辑现有主文档（`12_REV_Detailed.md`、`03_Interface_Design.md`），不创建平行版本
+- **Traceability**: ✅ 所有变更可追溯到本 spec 和 governance records
+- **Validation required**: ✅ 每个阶段包含明确的验证任务
 
 ## Project Structure
 
 ### Documentation (this feature)
 
 ```text
-specs/[###-feature]/
-├── plan.md              # This file (/speckit.plan command output)
-├── research.md          # Phase 0 output (/speckit.plan command)
-├── data-model.md        # Optional: document entities/traceability objects
-├── quickstart.md        # Optional: validation or review quickstart
-├── contracts/           # Optional: interface or section-level artifacts
-└── tasks.md             # Phase 2 output (/speckit.tasks command)
+specs/003-rev003-rev006-reminder-event-design/
+├── spec.md              # 功能规格（合并自 003 与 006）
+├── plan.md              # 本文件
+├── research.md          # 调研与现有基线评估
+├── data-model.md        # REV-006 涉及的实体与字段分析
+├── quickstart.md        # 快速开始指南
+├── tasks.md             # 任务拆解
+├── contracts/
+│   ├── rev006-interface-contract.md  # REV-006 接口契约（来自原 003）
+│   ├── if-rev-013.md                 # IF-REV-013 正式接口契约（来自原 006）
+│   └── if-ext-008.md                 # IF-EXT-008 外部协同契约（来自原 006）
+└── checklists/
+    └── requirements.md  # 需求审查清单
 ```
 
-### Repository Touchpoints
+### Source of Truth (upstream/downstream)
 
 ```text
 docs/design/
-├── 00_Management/
-├── 01_Overview/
-├── 02_Detailed_Design/
-├── 03_Technical_Design/
-└── 04_Appendix/Archive/
-
-README.md
-AGENTS.md
-.specify/templates/
+├── 02_Detailed_Design/12_REV_Detailed.md          # REV 模块详细设计（本 feature 的主要编辑目标）
+├── 03_Technical_Design/03_Interface_Design.md      # 接口设计（IF-REV-013、IF-EXT-008 的正式落点）
+└── 00_Management/
+    ├── 01_Project_Progress.md                      # 项目进度同步
+    ├── 03_Task_Checklist.md                        # 任务清单同步
+    └── 15_SYS002_Requirement_Breakdown.md          # 需求拆解同步
 ```
 
-**Structure Decision**:
- - 更新 `docs/design/02_Detailed_Design/12_REV_Detailed.md`：补齐 `REV-006` 详细设计正文与落地边界。
- - 更新 `docs/design/03_Technical_Design/03_Interface_Design.md`：修正接口编号冲突，补齐 `REV-006` 正式接口、协同时序、异常码和幂等策略。
- - 更新 `docs/design/03_Technical_Design/01_Database_Design.md`：明确在线承接与历史只读查询口径，不把旧菜单机械映射为新表。
- - 更新 `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`：同步实现评估、TAPD/Speckit 建议和后续任务入口。
- - 更新 `docs/design/00_Management/01_Project_Progress.md` 与 `docs/design/00_Management/03_Task_Checklist.md`：完成治理闭环。
+## Phase 1: Scope Confirmation
 
-## Complexity Tracking
+**Goal**: 确认本 feature 的确切编辑范围、主文档影响面和验证要求。
 
-> **Fill ONLY if Constitution Check has violations that must be justified**
+- 确认 `12_REV_Detailed.md` 的 `REV-006` 章节需要新增/修订的具体小节
+- 确认 `03_Interface_Design.md` 的 `IF-REV-013` 和 `IF-EXT-008` 需要新增/修订的具体内容
+- 确认治理类文档的同步范围（`01_Project_Progress.md`、`03_Task_Checklist.md`、`15_SYS002_Requirement_Breakdown.md`）
 
-| Violation | Why Needed | Simpler Alternative Rejected Because |
-|-----------|------------|-------------------------------------|
-| 无 | - | - |
+## Phase 2: Detailed Design Alignment
+
+**Goal**: 将 `REV-006` 催缴事件设计的正式描述写入 `12_REV_Detailed.md`。
+
+关键内容：
+- 催缴对象生成规则（欠费条件、账龄、金额、客户类别、渠道偏好）
+- 策略分组与任务生成维度
+- 四态结果语义（`PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED`）
+- 停复水/工单联动边界（只定义追溯接口，不展开内部流程）
+- 历史查询与导出口径
+
+## Phase 3: Interface & Contract Documentation
+
+**Goal**: 将 `IF-REV-013` 和 `IF-EXT-008` 的正式定义写入 `03_Interface_Design.md`。
+
+关键内容：
+- `IF-REV-013`：任务生成、任务查询、人工核查、结果承接
+- `IF-EXT-008`：外部消息触达协同（`SYS-010` 负责执行，`SYS-002` 保留业务控制）
+- 四态回写字段定义
+- 失败原因与处置引用字段
+
+## Phase 4: Governance Sync
+
+**Goal**: 同步治理台账，明确 `REV-006` 的当前结论、最小实现切入点和后续行动。
+
+关键动作：
+- 更新 `01_Project_Progress.md` 通报本轮收口结论
+- 更新 `03_Task_Checklist.md` 登记本轮文档治理任务完成情况
+- 更新 `15_SYS002_Requirement_Breakdown.md` 中 `SYS002-REQ-011` 的状态为"设计已收口"
+
+## Phase 5: Implementation Entry-Point Assessment
+
+**Goal**: 为后续研发立项提供最小实现切入点评估，不直接实现。
+
+关键输出：
+- 识别 backend 中是否存在 `Reminder/Message/Notice` 相关控制器或服务骨架
+- 评估最小实现入口（如从简单查询端点开始逐步扩展）
+- 输出结论建议（保留为"文档已收口、实现待立项"）
+
+## Risks
+
+| Risk | Mitigation |
+|------|------------|
+| 治理台账同步时遗漏条目 | 每阶段完成后立即检查 `01_Project_Progress.md` 和 `03_Task_Checklist.md` |
+| 接口编号冲突（IF-REV-009 误关联） | 本 feature 明确 IF-REV-013 为 REV-006 专用编号 |
+| 超出本 feature 范围展开实现 | 严守"设计收口、实现待立项"约束，不新增业务代码 |

specs/003-rev006-reminder-event-design/quickstart.md

@@ -1,57 +1,69 @@
-# Quickstart: REV-006 催缴事件与通知协同设计
+# Quickstart: REV-006 催缴与通知事件设计收口
 
-## 目标
+## 1. 使用目标
 
-本 quickstart 用于指导评审者和文档维护者快速完成 `REV-006` 设计补齐的检查，不涉及 backend 实施。
+本 quickstart 用于指导评审者或文档维护者快速完成 `REV-006` 的正式文档收口验证，不用于验证 backend 运行功能。
 
-## 步骤 1：阅读规格与研究结论
+## 2. 建议执行顺序
 
-1. 阅读 `spec.md`，确认三项澄清已固定：
-   - 停复水仅定义联动边界
-   - `REV-006` 使用独立接口编号 `IF-REV-013`
-   - 结果状态固定为四态
-2. 阅读 `research.md`，确认所有关键设计决策已有依据和备选方案说明。
+1. 打开 [spec.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/spec.md)，确认范围、四态状态和治理结论。
+2. 对照 [plan.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/plan.md)，确认本轮只修改既有主文档与管理台账。
+3. 对照 [data-model.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/data-model.md)，检查催缴候选对象、任务、结果和处置引用的最小字段是否齐全。
+4. 对照 `contracts/if-rev-013.md` 与 `contracts/if-ext-008.md`，确认 `SYS-002` / `SYS-010` 分工、输入输出和失败语义一致。
 
-## 步骤 2：执行文档改动时的目标落点
+## 3. 正式文档修订检查点
 
-1. 在 `docs/design/02_Detailed_Design/12_REV_Detailed.md` 补齐 `REV-006`：
-   - 任务生成规则
-   - 结果回写规则
-   - 停复水联动边界
-   - 历史查询最小保留集
-2. 在 `docs/design/03_Technical_Design/03_Interface_Design.md`：
-   - 新增或替换 `IF-REV-013`
-   - 保留 `IF-EXT-008`
-   - 删除 `REV-006` 对 `IF-REV-009` 的错误引用
-3. 在 `docs/design/03_Technical_Design/01_Database_Design.md`：
-   - 明确在线主模型和历史只读查询口径
-4. 在治理台账中回写：
-   - `01_Project_Progress.md`
-   - `03_Task_Checklist.md`
+- `12_REV_Detailed.md`
+  - 是否写清催缴对象来源、策略分组、频控和四态状态
+  - 是否明确停复水/工单只作为联动边界和追溯引用
+- `03_Interface_Design.md`
+  - 是否统一 `IF-REV-013` 为正式业务接口编号
+  - 是否区分 `IF-REV-013` 与 `IF-EXT-008` 的责任边界
+- `15_SYS002_Requirement_Breakdown.md`
+  - 是否保持 `SYS002-REQ-011` 为“未见实现”
+  - 是否明确“文档已收口，backend 未见明确实现骨架”
+- `01_Project_Progress.md` / `03_Task_Checklist.md`
+  - 是否登记本轮文档收口与验证动作
 
-## 步骤 3：建议校验命令
+## 4. 最小验证命令
 
 ```bash
 make validate-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md
 make validate-file FILE=docs/design/03_Technical_Design/03_Interface_Design.md
-make validate-file FILE=docs/design/03_Technical_Design/01_Database_Design.md
 make validate-file FILE=docs/design/00_Management/15_SYS002_Requirement_Breakdown.md
-make validate-file FILE=docs/design/00_Management/01_Project_Progress.md
-make validate-file FILE=docs/design/00_Management/03_Task_Checklist.md
 make check-links
+make validate-mermaid
 ```
 
-## 步骤 4：验收检查点
+## 5. 完成判定
 
-- `REV-006` 不再复用 `IF-REV-009`
-- 正式文档中统一使用四态结果集
-- 停复水只写联动边界，不扩写内部流程
-- 历史“催缴记录 / 停水记录 / 预存短信”不被误写成新在线主表
-- 台账和正式文档同步更新
+满足以下条件即可进入 `/speckit.tasks`：
 
-## 步骤 5：本轮实现摘要
+- `REV-006` 的业务规则、接口边界、历史查询和处置追溯口径已统一
+- `SYS002-REQ-011` 的实现判断与后续研发切入点已写入治理台账
+- 验证命令已纳入计划，且无新增平行正式稿
 
-- 已完成 `12_REV_Detailed.md`、`03_Interface_Design.md`、`01_Database_Design.md`、`15_SYS002_Requirement_Breakdown.md`、`01_Project_Progress.md`、`03_Task_Checklist.md` 的正式文档回写。
-- `REV-006` 的正式业务接口编号已固定为 `IF-REV-013`，`IF-REV-009` 继续保留给 `REV-005` 发票结果查询。
-- 催缴结果已统一为 `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED` 四态；数据库与历史查询口径同步收口。
-- 已执行并通过全部单文件校验与 `make check-links`。
+## 6. 2026-03-19 实施结果
+
+### 已完成文档
+
+- `docs/design/02_Detailed_Design/12_REV_Detailed.md`
+- `docs/design/03_Technical_Design/03_Interface_Design.md`
+- `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
+- `docs/design/00_Management/01_Project_Progress.md`
+- `docs/design/00_Management/03_Task_Checklist.md`
+
+### 验证结果
+
+- `make validate-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md`：通过，0 个问题
+- `make validate-file FILE=docs/design/03_Technical_Design/03_Interface_Design.md`：通过，0 个问题
+- `make validate-file FILE=docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`：通过，0 个问题
+- `make check-links`：通过，当前检查范围内未发现断链
+- `make check-mermaid-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md`：已确认目标文件存在 6 个 Mermaid 图表
+- `make validate-mermaid`：已执行两次，但在当前环境下未返回最终结果；结合 Makefile 逻辑，该目标只校验仓库根目录 `*.md`，未直接覆盖本轮主要修改文件，后续如需全仓 Mermaid 终态结果，应单独排查该目标在当前环境中的阻塞原因
+
+### 当前结论
+
+- `REV-006` 已完成 implement 阶段的正式文档二次收口
+- `SYS002-REQ-011` 继续维持“未见实现”，但 Speckit 工件链、正式文档口径与治理台账已对齐
+- 当前剩余风险不是文档口径缺失，而是后续 backend 立项与 `make validate-mermaid` 全仓目标在本环境中的执行阻塞

specs/003-rev006-reminder-event-design/research.md

@@ -1,58 +1,46 @@
-# Phase 0 Research: REV-006 催缴事件与通知协同设计
+# Phase 0 Research: REV-006 催缴与通知事件设计收口
 
-## 决策 1：`REV-006` 使用新的独立正式接口编号
+## Decision 1: 以既有主文档承载 `REV-006` 收口
 
-- **Decision**: `REV-006` 使用新的独立正式接口编号 `IF-REV-013` 作为“催缴任务生成与结果查询/回写承接”的正式业务接口编号；`IF-REV-009` 保留给 `REV-005` 发票结果查询。
-- **Rationale**:
-  - 当前 `03_Interface_Design.md` 已明确 `IF-REV-009` 属于 `REV-005` 发票结果查询，继续复用会造成接口总表、异常码、幂等策略和时序图冲突。
-  - 现有 `IF-REV-*` 编号已经覆盖到 `IF-REV-012`，顺延 `IF-REV-013` 是最小改动且最不易误解的做法。
-  - 该决策能直接消除 `12_REV_Detailed.md` 中 `REV-006` 与接口主文档的冲突口径。
-- **Alternatives considered**:
-  - 继续复用 `IF-REV-009`：被否决，因为与发票查询主口径冲突。
-  - 暂不落编号，只写业务能力：被否决，因为会推迟核心冲突到实施阶段。
-  - 改用 `IF-EXT-*`：被否决，因为 `REV-006` 的业务接口主责仍属于 `SYS-002`，`IF-EXT-008` 只适用于与 `SYS-010` 的外部协同。
+**Decision**: 正式设计收口继续落在 `12_REV_Detailed.md`、`03_Interface_Design.md` 与 `15_SYS002_Requirement_Breakdown.md`，不新建平行正式稿。  
+**Rationale**: `REV-006` 已在概要、详设、接口与治理台账中具备入口，当前问题是规则与边界不够收敛，而不是缺少载体。继续使用主文档符合单一真源原则。  
+**Alternatives considered**:
 
-## 决策 2：催缴结果状态固定为四态
+- 新建独立“催缴设计说明书”：会制造平行正式稿，违背宪章。
+- 仅在 spec 工件中描述：无法替代正式交付文档与治理台账。
 
-- **Decision**: `REV-006` 正式状态集固定为 `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED`。
-- **Rationale**:
-  - 四态足以覆盖“待回写/待核查”“成功触达”“失败”“人工核查确认”四类评审和实施必需场景。
-  - 过少状态会导致补偿与人工核查无法落地；过多状态会在当前未实现阶段引入不必要的细粒度设计。
-  - 四态同时便于后续接口、数据库和台账统一。
-- **Alternatives considered**:
-  - 两态（成功/失败）：无法表达未回写和人工核查状态。
-  - 三态（待处理/成功/失败）：无法区分人工核查后的确认结果。
-  - 更细状态（已送达/已阅读/已补发）：当前阶段超出设计收口所需。
+## Decision 2: `SYS-002` 与 `SYS-010` 按“业务侧任务控制 / 渠道侧触达执行”分界
 
-## 决策 3：停复水仅定义联动边界，不展开内部流程
+**Decision**: `SYS-002` 负责催缴对象筛选、任务生成、事件编号、四态状态承接、历史查询与处置引用；`SYS-010` 负责短信、微信、站内信等渠道触达及结果回传。  
+**Rationale**: 该分界已在 `12_REV_Detailed.md` 与 `03_Interface_Design.md` 形成一致表达，能够避免“催缴任务生成”和“消息发送执行”职责混写。  
+**Alternatives considered**:
 
-- **Decision**: 本 feature 仅定义催缴结果与停复水之间的联动边界、触发条件、查询字段和追溯关系，不展开停复水内部处置流程、审批节点或现场执行细节。
-- **Rationale**:
-  - 停复水属于后续业务处置链，深入展开会把当前专题扩展到工单/现场作业子系统。
-  - 当前 `REV-006` 的首要目标是把催缴闭环范围和责任边界收口，而不是设计全部后置处置流程。
-  - 这样既能满足历史查询和审计追溯，又不破坏范围控制。
-- **Alternatives considered**:
-  - 把停复水完整流程纳入 `REV-006`：被否决，因为会扩大到非本轮范围。
-  - 完全不写停复水联动：被否决，因为会留下历史查询和后续处置链断点。
+- 由 `SYS-010` 同时负责催缴任务控制：会让外部系统承担业务主控，不符合现有模块分工。
+- 由 `SYS-002` 同时负责所有消息发送：会弱化 `IF-EXT-008` 的外部协同边界。
 
-## 决策 4：历史“催缴记录/停水记录/预存短信”按历史只读口径承接
+## Decision 3: 正式状态集固定为四态
 
-- **Decision**: 旧系统“催缴记录、停水记录、预存短信记录”继续按历史只读查询对象承接，不新增同名在线主表；在线主模型以 `biz_charge`、操作留痕和消息协同结果为主。
-- **Rationale**:
-  - `01_Database_Design.md` 已对这些对象给出“历史只读保留”口径，且当前 backend 未见明确独立表族。
-  - 直接新增同名新表会违反“不得臆造已实现事实”和“单一真源”的原则。
-  - 历史只读策略既能满足迁移验收，也不影响后续按业务链逐步演进。
-- **Alternatives considered**:
-  - 为每个旧菜单新增在线主表：被否决，因为没有实现证据且破坏当前主模型。
-  - 完全不保留历史查询口径：被否决，因为不满足迁移验收和追溯要求。
+**Decision**: `REV-006` 状态集固定为 `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED`。  
+**Rationale**: 四态已在详设与接口文档中同步表达，且足以覆盖受理中、成功、失败、人工补记三类核心语义。增加更多细粒度状态会放大实现假设。  
+**Alternatives considered**:
 
-## 决策 5：`REV-006` 与 `SYS-010` 的职责分界
+- 增加“已阅读”“已补发”等状态：超出当前正式口径，也缺少 backend 证据支持。
+- 仅保留成功/失败二态：不足以表达异步回写与人工核查场景。
 
-- **Decision**: `SYS-002/REV-006` 负责催缴对象筛选、任务分组、业务事件生成、状态承接、历史查询和处置关联；`SYS-010` 负责短信、微信公众号、站内信等触达执行与结果回传。
-- **Rationale**:
-  - 该分界与 `03_Interface_Design.md` 中跨系统协同表一致。
-  - 业务筛选和状态归属留在 `SYS-002`，能保证催缴逻辑与账单口径一致。
-  - 触达能力放在 `SYS-010`，避免 `REV-006` 越权扩展到消息平台实现。
-- **Alternatives considered**:
-  - 让 `SYS-010` 负责催缴对象筛选：被否决，因为会削弱营收主系统对账单规则的控制。
-  - 让 `SYS-002` 直接承担全部消息发送：被否决，因为与既有系统边界不一致。
+## Decision 4: 历史催缴、停水、预存短信按只读查询口径承接
+
+**Decision**: 旧系统催缴记录、停水记录、预存短信记录统一作为历史查询和追溯范围承接，不默认扩展为新系统已确认在线主表。  
+**Rationale**: 当前 backend 未确认独立催缴台账、停水汇总表等实体；保守表达可同时满足迁移查询需求和事实一致性。  
+**Alternatives considered**:
+
+- 直接定义新在线主表：缺少代码和数据库证据。
+- 完全忽略历史场景：会让迁移核查、客户历史查询和处置追溯失去正式口径。
+
+## Decision 5: 当前实施结论维持“文档已收口，backend 未见明确实现骨架”
+
+**Decision**: 计划阶段保留 `SYS002-REQ-011` 为“未见实现”，并把本轮产出定位为文档收口和后续研发立项输入。  
+**Rationale**: 现有治理文档已经给出相同结论，且当前未检索到明确的 `Reminder/Message/Notice` controller/service 骨架。  
+**Alternatives considered**:
+
+- 升级为“部分实现”：会放大现有消息协同或历史查询描述，和证据不匹配。
+- 直接按“已实现”处理：与仓库现状冲突。

specs/003-rev006-reminder-event-design/spec.md

@@ -1,32 +1,29 @@
-# Feature Specification: REV-006 催缴事件与通知协同设计
+# Feature Specification: REV-006 催缴与通知事件设计收口
 
-**Feature Branch**: `003-rev006-reminder-event-design`
+**Feature Branch**: `003-rev003-rev006-reminder-event-design`
 **Created**: 2026-03-18
-**Status**: Draft
-**Input**: User description: "为 REV-006 催缴与通知补齐 spec-kit 规格，明确催缴任务生成、消息协同结果回写、停复水联动和历史查询边界"
+**Status**: Ready for Planning
+**Input**: 收口自 `003-rev003-rev006-reminder-event-design`（原设计会话）与 `003-rev006-reminder-event-design`（收口会话），合并后以本目录为准。
 
 ## Document Scope & Sources *(mandatory)*
 
 - **Target documents**:
   - `docs/design/02_Detailed_Design/12_REV_Detailed.md`
   - `docs/design/03_Technical_Design/03_Interface_Design.md`
-  - `docs/design/03_Technical_Design/01_Database_Design.md`
   - `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
   - `docs/design/00_Management/01_Project_Progress.md`
   - `docs/design/00_Management/03_Task_Checklist.md`
 - **Primary source of truth**:
   - `docs/design/02_Detailed_Design/12_REV_Detailed.md`
   - `docs/design/03_Technical_Design/03_Interface_Design.md`
-  - `docs/design/03_Technical_Design/01_Database_Design.md`
-  - `docs/design/00_Management/04_Writing_Guide.md`
+  - `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
+  - `docs/design/01_Overview/03_Summary_Design.md`
   - `AGENTS.md`
 - **Reference sources**:
-  - `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
   - `docs/guides/BACKEND_CURRENT_STATUS.md`
-  - `docs/guides/BACKEND_TABLE_MAPPING.md`
-  - `docs/design/04_Appendix/Archive/01_Requirements/`
-  - `docs/design/04_Appendix/Archive/05_Data_Dictionary/营收数据字典.md`
-- **Scope decision**: In scope. This feature is limited to补齐 `REV-006` 的正式设计口径、接口边界、数据承接边界和后续任务拆解依据；不扩展到 `SYS-010` 的内部实现，不重写其他 `REV-*` 模块，不新建平行正式主稿。
+  - `docs/design/04_Appendix/Archive/02_Manuals/营收系统_用户操作手册.md`
+  - `docs/design/04_Appendix/Archive/03_Design_Docs/营业收费管理系统-概要设计说明书20250912.md`
+- **Scope decision**: In scope. 本 feature 聚焦 `REV-006` 催缴与通知的正式设计收口，补齐催缴对象生成、任务分组、`IF-REV-013` / `IF-EXT-008` 协同边界、四态状态语义、历史查询口径、停复水/工单联动追溯和后续研发立项输入；不在本轮直接承诺 backend 已落地催缴业务实现。
 
 ## Clarifications
 
@@ -38,104 +35,100 @@
 
 ## User Scenarios & Testing *(mandatory)*
 
-### User Story 1 - 定义催缴闭环范围 (Priority: P1)
+### User Story 1 - 收口催缴任务生成规则 (Priority: P1)
 
-作为文档维护者，我需要把 `REV-006` 的催缴生成、消息触达、结果回写和后续处置边界写清楚，使评审者能明确该模块到底负责什么、不负责什么，并据此开展后续设计与研发；其中停复水仅定义联动边界，不展开内部处置流程。
+作为文档维护者，我需要把 `REV-006` 的催缴触发时机、催缴对象筛选条件、策略分组规则和四态状态定义写清楚，使评审者能够明确欠费账单如何进入催缴任务，以及哪些场景属于自动催缴、人工补发或人工核查补记。
 
-**Why this priority**: `REV-006` 当前在仓库内被判定为“未见实现”，如果范围和边界不先收敛，后续 `plan/tasks` 会直接失焦。
+**Why this priority**: 当前 `REV-006` 已有第一轮场景描述，但后续研发立项仍依赖更清晰的触发规则、筛选条件和状态语义。
 
-**Independent Test**: 单独评审 `12_REV_Detailed.md` 中 `REV-006` 章节，应能独立回答“催缴任务如何产生、结果如何回写、停复水与工单如何衔接、哪些内容不在本轮范围内”。
+**Independent Test**: 单独评审 `12_REV_Detailed.md` 中 `REV-006` 章节，应能明确催缴对象来源、触发规则、四态状态和人工核查边界。
 
 **Acceptance Scenarios**:
 
-1. **Given** 当前 `REV-006` 只有概要级描述， **When** 评审者阅读更新后的详细设计， **Then** 能明确催缴对象来源、任务生成维度、自动与人工催缴边界以及停复水联动触发入口。
-2. **Given** 后续需要把 `REV-006` 拆成开发任务， **When** 维护者依据该规格开展计划拆解， **Then** 不需要再回到 Archive 才能判断本轮范围和排除项。
+1. **Given** 当前文档只概括"按策略分组催缴任务"， **When** 评审者阅读补齐后的详细设计， **Then** 能明确欠费账单、账龄、金额、客户类别、渠道偏好和频控规则如何形成催缴对象与任务。
+2. **Given** 后续需要据此拆解研发任务， **When** 维护者依据该规格评估实现切入点， **Then** 能区分自动催缴、人工补发、人工核查补记和停复水联动的边界。
 
 ---
 
-### User Story 2 - 统一消息协同与结果回写口径 (Priority: P2)
+### User Story 2 - 统一 IF-REV-013 与消息协同边界 (Priority: P2)
 
-作为接口与系统集成评审者，我需要看到 `SYS-002` 与 `SYS-010` 之间关于催缴事件、触达结果、失败重试和状态回写的统一口径，并为 `REV-006` 使用独立正式接口编号和明确的 4 态结果集，以便避免与发票查询接口混淆。
+作为接口设计评审者，我需要看到 `IF-REV-013` 和 `IF-EXT-008` 的职责分工、请求输出、回写字段和四态结果承接口径，使 `SYS-002` 与 `SYS-010` 的边界不再停留在抽象表述。
 
-**Why this priority**: `REV-006` 的业务价值高度依赖消息协同结果，若回写与状态语义不清，会直接影响催缴结果查询、后续催办和停复水判断。
+**Why this priority**: `REV-006` 的核心风险在于业务筛选、任务状态承接和外部通知执行边界不清，容易出现"任务生成"和"消息发送"职责混写。
 
-**Independent Test**: 单独评审接口设计相关章节，应能独立确认触发方、回写方、关键状态、失败语义和查询/补偿责任分界。
+**Independent Test**: 单独评审接口主文档和需求拆解台账，应能确认 `IF-REV-013` 的业务侧职责、`IF-EXT-008` 的外部协同职责以及四态回写字段。
 
 **Acceptance Scenarios**:
 
-1. **Given** `SYS-002` 需要向 `SYS-010` 发送催缴事件， **When** 评审者查看规格， **Then** 能明确独立接口编号、事件生成条件、发送前置校验和最小回写字段集。
-2. **Given** 消息发送失败或结果迟迟未回写， **When** 评审者查看规格， **Then** 能明确 `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED` 的适用边界，以及重试/补偿归属和人工核查入口。
+1. **Given** 评审者查看接口设计， **When** 阅读 `IF-REV-013` 章节， **Then** 能明确任务生成、任务查询、人工核查和结果承接的请求路径、字段与状态语义。
+2. **Given** 评审者查看需求拆解文档， **When** 阅读 `SYS002-REQ-011` 对应内容， **Then** 能明确当前属于"设计已收口、实现未见骨架"的状态，而不是误判为已实现。
 
 ---
 
-### User Story 3 - 明确历史查询与停复水联动边界 (Priority: P3)
+### User Story 3 - 形成治理与研发切入结论 (Priority: P3)
 
-作为后续实施和验收人员，我需要知道催缴记录、预存短信、停水记录等历史口径如何在当前体系中承接，避免为了追求“完整”而无依据地新增平行模型。
+作为后续立项和治理跟踪人员，我需要在台账和进度记录中看到 `REV-006` 的当前结论、最小实现切入点和校验动作，避免文档收口后仍无法指导后续研发排期。
 
-**Why this priority**: 旧系统相关对象较多，如果不先定义“最小保留集”和联动边界，后续很容易把历史菜单直接平移成新模块。
+**Why this priority**: `REV-006` 当前在治理台账中属于未见实现，需要通过本轮 feature 明确"文档先行、实现待立项"的真实结论和后续切入点。
 
-**Independent Test**: 单独检查规格中的迁移/历史查询要求，应能判断哪些历史信息必须可查、哪些仅保留映射说明、哪些应转交工单或外部协同模块承接。
+**Independent Test**: 单独检查治理文档，应能定位 `REV-006` 当前状态、最小研发切入点、台账同步动作和验证要求。
 
 **Acceptance Scenarios**:
 
-1. **Given** 需要追查某次催缴或停水处置历史， **When** 评审者阅读规格， **Then** 能明确最少需要保留的查询字段与关联对象。
-2. **Given** Archive 中存在旧“停水记录”“预存短信”等入口， **When** 评审者执行范围判断， **Then** 能明确这些内容在新体系中属于催缴协同能力还是外部协同能力，而不是新增独立正式模块。
+1. **Given** 项目需要安排后续研发排期， **When** 查看需求拆解和项目进度， **Then** 能明确 `REV-006` 当前是设计收口完成、backend 未见明确实现骨架、可继续立项推进的状态。
+2. **Given** 本轮完成正式文档修订， **When** 查看进度与任务清单， **Then** 能定位本次 `REV-006` 文档治理动作及其最小校验结果。
 
 ---
 
 ### Edge Cases
 
-- 当欠费账单满足多条催缴策略时，如何确定任务分组、优先级和避免重复触达？
-- 当 `SYS-010` 返回失败、超时或迟迟不回写时，如何稳定映射到 `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED`，而不再扩展更多细分状态？
-- 当同一客户既存在催缴事件又进入停水/复水处置时，如何保证催缴记录与工单处置链路可追溯但不互相覆盖状态，且本 feature 不承担停复水内部流程定义？
-- 当旧系统存在催缴记录、停水记录、预存短信历史数据，但当前后端未见独立表族时，如何定义最小保留查询口径而不臆造新模型？
-- 当 `REV-006` 改用独立正式接口编号后，如何保证 `12_REV_Detailed.md`、`03_Interface_Design.md`、`01_Database_Design.md` 和管理台账同步更新且不保留旧冲突口径？
+- 当欠费账单已被收费、作废或进入其他处置流程时，催缴对象是否仍可进入任务生成，文档必须如何表达排除条件？
+- 当 `SYS-010` 只返回发送受理结果而未立即返回终态时，四态状态如何在 `SYS-002` 侧保持一致？
+- 当旧系统存在催缴记录、停水记录和预存短信等历史查询场景，但当前 backend 未确认独立落表时，文档如何保持"历史只读承接"而不误写为现成在线表？
+- 当人工核查补记场景发生时，哪些字段必须记录核查说明、关联任务号和后续处置引用？
 
 ## Requirements *(mandatory)*
 
 ### Functional Requirements
 
-- **FR-001**: Specification MUST identify `REV-006` 的精确目标文档，并说明每份文档承担的职责。
-- **FR-002**: Specification MUST identify `12_REV_Detailed.md`、`03_Interface_Design.md`、`01_Database_Design.md` 作为本 feature 的主约束来源。
-- **FR-003**: Specification MUST record that the feature is in scope only for `REV-006` 的设计与任务拆解准备，不扩展到 `SYS-010` 内部实现或其他 `REV-*` 模块重写。
-- **FR-004**: Specification MUST preserve the single-source-of-truth model and MUST NOT introduce a new parallel formal design document for reminder/notice capability.
-- **FR-005**: Specification MUST define reminder object sources based on overdue billing data and customer attributes, including at minimum arrears status, amount, aging, customer category, and applicable reminder strategy dimensions.
-- **FR-006**: Specification MUST define the business flow for reminder generation, task grouping, message dispatch request, result writeback, and follow-up handling.
-- **FR-007**: Specification MUST distinguish automatic reminder, manual reminder, and subsequent disposal linkage, including what belongs to `SYS-002`, what is coordinated by `SYS-010`, and what is handled through downstream disposal processes.
-- **FR-008**: Specification MUST define exactly four formal result states for reminder collaboration: `PENDING`, `SUCCESS`, `FAIL`, and `MANUAL_VERIFIED`, with unambiguous transition intent and usage boundaries.
-- **FR-008a**: Specification MUST require a dedicated formal interface identifier for `REV-006` reminder task generation and result handling, and MUST prohibit continued reuse of `IF-REV-009` for this feature because `IF-REV-009` remains reserved for invoice result query.
-- **FR-009**: Specification MUST define the minimum historical query retention scope for reminder records, stop-water related records, and prepaid-balance reminder events, including the fields needed to trace content, channel, target, time, result, operator/source, and related billing object.
-- **FR-010**: Specification MUST define how stop-water and recovery handling relate to reminder outcomes without collapsing them into the same business object, and MUST limit this feature to linkage conditions and traceability rather than internal disposal workflow details.
-- **FR-011**: Specification MUST state the exclusions for this feature, including that historical menu names and Archive structures are reference material only and not direct targets for formal document reconstruction.
-- **FR-012**: Specification MUST capture cross-document consistency impacts for interfaces, data retention, terminology, result states, and downstream ledger updates.
-- **FR-013**: Specification MUST list the validation actions required after document updates, including single-file validation for impacted docs and link consistency checks.
-- **FR-014**: Specification MUST state that formal document changes under this feature require synchronized updates to `01_Project_Progress.md` and `03_Task_Checklist.md`.
+- **FR-001**: Specification MUST identify the exact target documents for `REV-006` reminder-event alignment and governance sync.
+- **FR-002**: Specification MUST identify `12_REV_Detailed.md`、`03_Interface_Design.md`、`15_SYS002_Requirement_Breakdown.md` as the main source-of-truth set for this feature.
+- **FR-003**: Specification MUST record that this feature is in scope only for reminder-candidate generation, task rules, `IF-REV-013` / `IF-EXT-008` interface boundary, four-state result semantics, historical query boundary, and governance sync.
+- **FR-004**: Specification MUST preserve the single-source-of-truth model and MUST NOT create a parallel formal design document for `REV-006`.
+- **FR-005**: Specification MUST define reminder-candidate selection conditions, including arrears status, aging, amount, customer category, channel preference, strategy grouping, and frequency-control boundary.
+- **FR-006**: Specification MUST define the formal four-state reminder result set as `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED`, including the intended meaning of each state.
+- **FR-007**: Specification MUST define the exact business boundary of `IF-REV-013`, including task generation, task query, manual verification, result acceptance, and historical query support.
+- **FR-008**: Specification MUST define the external collaboration boundary of `IF-EXT-008`, clarifying that `SYS-010` is responsible for channel delivery while `SYS-002` retains business-side task and state control.
+- **FR-009**: Specification MUST define the minimum write-back and traceability fields for reminder results, including task number, event number, strategy code, channel type, trigger type, status, failure reason, and disposal reference.
+- **FR-010**: Specification MUST define how reminder results link to stop-water, restore-water, work-order, or manual follow-up references without expanding those downstream internal workflows.
+- **FR-011**: Specification MUST define historical query and export expectations for reminder records, including customer, bill period, reminder channel, target receiver, send time, execution result, related bills, and disposal references.
+- **FR-012**: Specification MUST explicitly capture the current implementation judgment as "文档已收口，backend 未见明确催缴/通知业务实现骨架" unless stronger evidence is found later.
+- **FR-013**: Specification MUST identify the minimum validation actions after document updates, including affected file validation, link checks, and Mermaid checks where flows are updated.
+- **FR-014**: Specification MUST state that important formal document changes under this feature require synchronized updates to `01_Project_Progress.md` and `03_Task_Checklist.md`.
 
 ### Assumptions
 
-- 本 feature 以正式文档补齐和后续立项准备为目标，默认不在本轮直接修改 backend 代码。
-- `SYS-010` 继续作为消息发送能力提供方，`SYS-002` 负责业务事件生成、状态承接和历史查询口径。
-- `REV-006` 将在正式文档中使用新的独立接口编号；现有 `IF-REV-009` 继续保留给发票结果查询，不再混用。
-- 催缴结果状态默认收敛为 `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED` 四态，本轮不再细分为“已送达”“已阅读”“已补发”等更细粒度状态。
-- 旧系统“催缴记录”“预存短信”“停水记录”等历史入口默认先按查询能力和映射口径承接，不默认要求新建同名独立主表。
-- 停水/复水属于后续业务处置链的一部分，本 feature 只要求定义与催缴结果的联动边界、触发条件和追溯关系，不展开其内部节点、审批或执行流程。
+- 本 feature 以正式文档收口和后续研发立项准备为目标，默认不在本轮直接承诺 backend 业务代码实现。
+- `IF-REV-013` 继续作为 `REV-006` 的正式业务接口编号，不复用其他 `IF-REV-*` 编号。
+- `SYS-010` 负责短信、微信公众号、站内信等触达执行；`SYS-002` 保留催缴对象筛选、任务生成、四态状态承接和历史查询职责。
+- 当前 backend 中未见明确的 `Reminder/Message/Notice` 业务控制器或服务骨架，因此实现状态保持"未见实现"。
+- 催缴记录、停复水记录和预存短信等历史场景在本轮按"历史只读查询口径"承接，不默认要求新建平行在线主表。
 
 ### Key Entities *(include if feature involves data)*
 
-- **Reminder Candidate**: 满足欠费、账龄、客户类别等条件、可进入催缴流程的账单或客户对象集合。
-- **Reminder Strategy**: 决定催缴触发条件、分组规则、触达渠道和优先级的业务规则集。
-- **Reminder Task**: 一次可追溯的催缴执行单元，包含催缴对象、触达渠道、生成来源、执行状态和后续处置指向。
-- **Reminder Result**: 由消息协同或人工核查产生的结果记录，反映发送状态、失败原因、回写时间和后续动作建议。
-- **Reminder History Record**: 支撑历史查询的最小记录集合，至少覆盖触达内容、目标对象、渠道、发送时间、结果状态、关联账单和操作来源。
-- **Disposal Link**: 催缴结果与停水、复水、工单或人工处置之间的关联关系，用于追溯后续业务动作，但不替代下游业务对象。
-- **Ledger Update**: 当 `REV-006` 正式文档完成补齐后，需要同步回写到项目进度和任务清单的治理记录。
+- **Reminder Candidate**: 由欠费账单、账龄、欠费金额、客户类别、联系方式和命中策略组成的催缴输入对象。
+- **Reminder Strategy**: 定义账龄规则、金额规则、客户类别规则、渠道优先级、频控策略和后续联动关注条件的策略对象。
+- **Reminder Task**: 一次正式催缴执行单元，至少包含 `taskNo`、`eventNo`、`strategyCode`、`channelType`、`triggerType`、`status` 和关联账单集合。
+- **Reminder Result**: 催缴任务的四态结果及其失败原因、执行时间、外部回写摘要和业务侧处置引用。
+- **Disposal Link**: 催缴结果与停复水、工单、人工核查等后续处置之间的追溯引用对象。
+- **Governance Record**: 用于在需求拆解、项目进度和任务清单中登记本轮 `REV-006` 收口结论和后续研发建议的治理记录。
 
 ## Success Criteria *(mandatory)*
 
 ### Measurable Outcomes
 
-- **SC-001**: 评审者可在 5 分钟内从规格中定位 `REV-006` 的目标文档、主约束来源、范围边界和排除项。
-- **SC-002**: 规格中覆盖至少 3 类独立可评审场景：催缴任务生成、消息结果回写、历史查询/停复水联动。
-- **SC-003**: `REV-006` 的状态语义、协同边界和历史查询最小保留集在规格中均有明确表述，且不存在未解析的 `[NEEDS CLARIFICATION]` 标记。
-- **SC-004**: 后续执行 `/speckit.plan` 时，规划者无需新增范围澄清即可把工作拆分为文档对齐、接口补齐、数据口径补齐和台账更新四类任务。
-- **SC-005**: 规格明确列出全部必要验证动作，审阅者可直接据此执行至少 4 项文档校验或一致性检查而无需二次猜测。
+- **SC-001**: 评审者可在 5 分钟内从规格中定位 `REV-006` 的目标文档、催缴对象生成规则、接口边界和排除项。
+- **SC-002**: 规格中至少覆盖 3 类独立可评审内容：催缴任务生成规则、`IF-REV-013` / `IF-EXT-008` 边界、治理与研发切入结论。
+- **SC-003**: 规格明确区分至少 6 项关键任务或结果要素，如 `taskNo`、`eventNo`、`strategyCode`、`channelType`、`triggerType`、`status`、失败原因、处置引用。
+- **SC-004**: 后续执行 `/speckit.plan` 时，规划者无需再补充范围澄清即可将工作拆分为详细设计收口、接口收口、治理同步和实现切入点评估四类任务。
+- **SC-005**: 规格明确列出全部必要验证动作，审阅者可直接据此执行至少 4 项文档校验或一致性检查。

specs/003-rev006-reminder-event-design/tasks.md

@@ -1,6 +1,6 @@
 # Tasks: REV-006 催缴事件与通知协同设计
 
-**Input**: Design documents from `/specs/003-rev006-reminder-event-design/`
+**Input**: Design documents from `/specs/003-rev003-rev006-reminder-event-design/`
 **Prerequisites**: plan.md (required), spec.md (required), research.md, data-model.md, contracts/
 
 **Validation**: Validation tasks are NOT optional in this repository. Every document change task set MUST include the applicable validation and ledger-sync tasks.
@@ -24,10 +24,10 @@
 
 **Purpose**: Confirm the source-of-truth set and impact boundary before editing.
 
-- [X] T001 Confirm target documents and exact `REV-006` touchpoints in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/spec.md`
-- [X] T002 Confirm governing source-of-truth and allowed reference sources in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/plan.md`
-- [X] T003 [P] Record final scope judgment for `REV-006` and exclusions in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/research.md`
-- [X] T004 [P] Identify cross-document impacts for `IF-REV-013`、四态结果集、停复水联动边界和历史只读口径 in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/contracts/rev006-interface-contract.md`
+- [X] T001 Confirm target documents and exact `REV-006` touchpoints in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev003-rev006-reminder-event-design/spec.md`
+- [X] T002 Confirm governing source-of-truth and allowed reference sources in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev003-rev006-reminder-event-design/plan.md`
+- [X] T003 [P] Record final scope judgment for `REV-006` and exclusions in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev003-rev006-reminder-event-design/research.md`
+- [X] T004 [P] Identify cross-document impacts for `IF-REV-013`、四态结果集、停复水联动边界和历史只读口径 in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev003-rev006-reminder-event-design/contracts/rev006-interface-contract.md`
 
 ---
 
@@ -35,7 +35,7 @@
 
 **Purpose**: Prepare the cross-document baseline that all user stories depend on.
 
-- [X] T005 Consolidate `REV-006` decisions, entities, and contract fields from `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/research.md`, `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/data-model.md`, and `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/contracts/rev006-interface-contract.md`
+- [X] T005 Consolidate `REV-006` decisions, entities, and contract fields from `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev003-rev006-reminder-event-design/research.md`, `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev003-rev006-reminder-event-design/data-model.md`, and `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev003-rev006-reminder-event-design/contracts/rev006-interface-contract.md`
 - [X] T006 [P] Cross-check current conflicting references to `IF-REV-009` and `REV-006` in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md` and `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/03_Interface_Design.md`
 - [X] T007 [P] Cross-check historical-only retention rules for 催缴记录/停水记录/预存短信 in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/01_Database_Design.md` and `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/04_Appendix/Archive/05_Data_Dictionary/营收数据字典.md`
 - [X] T008 Confirm ledger update expectations for this feature in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`, `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/01_Project_Progress.md`, and `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/03_Task_Checklist.md`
@@ -105,7 +105,7 @@
 
 - [X] T027 [P] Re-check source-of-truth alignment across `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md`, `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/03_Interface_Design.md`, `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/01_Database_Design.md`, and `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
 - [X] T028 [P] Run `make check-links` after all document changes and capture result
-- [X] T029 Prepare final summary with modified files, validation results, remaining risks, and next-step suggestions in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev006-reminder-event-design/quickstart.md`
+- [X] T029 Prepare final summary with modified files, validation results, remaining risks, and next-step suggestions in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/003-rev003-rev006-reminder-event-design/quickstart.md`
 
 ---
 

specs/006-reminder-event-design/checklists/requirements.md

@@ -1,35 +0,0 @@
-# Specification Quality Checklist: REV-006 催缴与通知事件设计收口
-
-**Purpose**: Validate specification completeness and quality before proceeding to planning
-**Created**: 2026-03-18
-**Feature**: [/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/spec.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/spec.md)
-
-## Content Quality
-
-- [x] No implementation details (languages, frameworks, APIs)
-- [x] Focused on user value and business needs
-- [x] Written for non-technical stakeholders
-- [x] All mandatory sections completed
-
-## Requirement Completeness
-
-- [x] No [NEEDS CLARIFICATION] markers remain
-- [x] Requirements are testable and unambiguous
-- [x] Success criteria are measurable
-- [x] Success criteria are technology-agnostic (no implementation details)
-- [x] All acceptance scenarios are defined
-- [x] Edge cases are identified
-- [x] Scope is clearly bounded
-- [x] Dependencies and assumptions identified
-
-## Feature Readiness
-
-- [x] All functional requirements have clear acceptance criteria
-- [x] User scenarios cover primary flows
-- [x] Feature meets measurable outcomes defined in Success Criteria
-- [x] No implementation details leak into specification
-
-## Notes
-
-- Validated against `spec.md` on 2026-03-18; no outstanding clarification markers or blocking quality gaps were found.
-- Items marked incomplete require spec updates before `/speckit.clarify` or `/speckit.plan`

specs/006-reminder-event-design/data-model.md

@@ -1,125 +0,0 @@
-# Data Model: REV-006 催缴与通知事件设计收口
-
-## 1. Reminder Candidate
-
-**说明**: 催缴任务的输入对象，由欠费账单和客户上下文组合形成。  
-
-| 字段 | 类型 | 说明 | 约束 |
-|------|------|------|------|
-| candidateId | String | 候选对象标识 | 可由任务生成阶段派生，不要求独立持久化主键 |
-| custId | String | 客户标识 | 必填 |
-| accountId | String | 账户标识 | 必填 |
-| chargeIds | List<String> | 命中的欠费账单集合 | 至少 1 条 |
-| billPeriods | List<String> | 账期集合 | 必填 |
-| arrearsAmount | Decimal | 欠费总金额 | 必须大于 0 |
-| agingBucket | String | 账龄分组 | 必填 |
-| custCategory | String | 客户类别 | 必填 |
-| preferredChannels | List<String> | 渠道偏好 | 至少 1 个渠道 |
-| strategyCode | String | 命中的催缴策略编码 | 必填 |
-| frequencyWindow | String | 频控窗口 | 用于重复触达拦截 |
-
-**关系**:
-
-- 一个 `Reminder Candidate` 可生成一个或多个 `Reminder Task`
-- `Reminder Candidate` 来源于 `biz_charge`、`biz_charge_detail` 等营业账对象
-
-## 2. Reminder Strategy
-
-**说明**: 约束候选对象筛选、任务分组和渠道优先级的规则集合。  
-
-| 字段 | 类型 | 说明 | 约束 |
-|------|------|------|------|
-| strategyCode | String | 策略编码 | 唯一 |
-| strategyName | String | 策略名称 | 必填 |
-| agingRule | String | 账龄规则 | 必填 |
-| amountRule | String | 金额规则 | 必填 |
-| custCategoryRule | String | 客户类别规则 | 可为空，表示不限 |
-| channelPriority | List<String> | 渠道优先级 | 至少 1 项 |
-| frequencyControl | String | 频控规则 | 必填 |
-| disposalAttentionFlag | Boolean | 是否关注后续处置 | 必填 |
-
-**状态转换**:
-
-- 启用
-- 停用
-
-## 3. Reminder Task
-
-**说明**: 正式催缴执行单元，是 `IF-REV-013` 的核心业务对象。  
-
-| 字段 | 类型 | 说明 | 约束 |
-|------|------|------|------|
-| taskNo | String | 催缴任务号 | 唯一、必填 |
-| eventNo | String | 业务事件号 | 唯一、必填 |
-| strategyCode | String | 策略编码 | 必填 |
-| channelType | String | 执行渠道 | 必填 |
-| triggerType | String | 触发类型 | 自动 / 人工 |
-| status | String | 当前状态 | 仅允许 `PENDING` / `SUCCESS` / `FAIL` / `MANUAL_VERIFIED` |
-| chargeIds | List<String> | 关联账单 | 至少 1 条 |
-| receiver | String | 触达对象 | 可为手机号、微信标识或站内账号 |
-| sendTime | Datetime | 发送发起时间 | 可空，待触发后填写 |
-| lastCallbackTime | Datetime | 最近结果回写时间 | 可空 |
-| failReason | String | 失败原因 | `FAIL` 时建议记录 |
-| manualVerifyNote | String | 人工核查说明 | `MANUAL_VERIFIED` 时建议记录 |
-
-**状态转换**:
-
-1. 新建任务后进入 `PENDING`
-2. 外部触达成功后进入 `SUCCESS`
-3. 外部明确失败后进入 `FAIL`
-4. 外部结果长期未定或人工补记后进入 `MANUAL_VERIFIED`
-
-## 4. Reminder Result
-
-**说明**: 承接 `SYS-010` 回写结果与业务侧最终状态语义。  
-
-| 字段 | 类型 | 说明 | 约束 |
-|------|------|------|------|
-| taskNo | String | 对应任务号 | 必填 |
-| eventNo | String | 对应事件号 | 必填 |
-| status | String | 四态结果 | 必填 |
-| channelType | String | 渠道类型 | 必填 |
-| externalResultCode | String | 外部结果码 | 可空 |
-| externalResultMessage | String | 外部结果说明 | 可空 |
-| failReason | String | 业务失败原因 | `FAIL` 时可必填 |
-| callbackTime | Datetime | 回写时间 | 必填 |
-| sourceSystem | String | 回写来源系统 | 默认 `SYS-010` |
-
-## 5. Disposal Link
-
-**说明**: 催缴任务与停水、复水、工单、人工跟进之间的追溯引用。  
-
-| 字段 | 类型 | 说明 | 约束 |
-|------|------|------|------|
-| taskNo | String | 关联催缴任务号 | 必填 |
-| disposalType | String | 处置类型 | 停水 / 复水 / 工单 / 人工跟进 |
-| disposalRefNo | String | 处置引用号 | 必填 |
-| disposalStatus | String | 处置状态摘要 | 可空 |
-| linkedAt | Datetime | 建联时间 | 必填 |
-| note | String | 追溯说明 | 可空 |
-
-## 6. Governance Record
-
-**说明**: 用于治理台账登记本轮设计收口结论与后续研发建议。  
-
-| 字段 | 类型 | 说明 | 约束 |
-|------|------|------|------|
-| reqCode | String | 需求编号 | 固定为 `SYS002-REQ-011` |
-| featureName | String | Speckit feature 名称 | 固定为 `rev006-reminder-event-design` |
-| implementationStatus | String | 当前实现判断 | `未见实现` |
-| docStatus | String | 文档状态 | 设计已收口 / 待同步 / 待验证 |
-| nextAction | String | 后续动作 | 研发立项 / 文档补证 / 治理同步 |
-| evidenceRefs | List<String> | 证据来源 | 必填 |
-
-## 7. 关系总览
-
-```text
-Reminder Strategy
-  -> Reminder Candidate
-  -> Reminder Task
-Reminder Task
-  -> Reminder Result
-  -> Disposal Link
-Governance Record
-  -> 引用 Reminder Task / Reminder Result 的设计结论与实现判断
-```

specs/006-reminder-event-design/plan.md

@@ -1,150 +0,0 @@
-# Implementation Plan: REV-006 催缴与通知事件设计收口
-
-**Branch**: `006-reminder-event-design` | **Date**: 2026-03-18 | **Spec**: [/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/spec.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/spec.md)
-**Input**: Feature specification from `/specs/006-reminder-event-design/spec.md`
-
-## Summary
-
-本次计划聚焦 `REV-006` 的正式文档收口，而非直接编写 backend 业务代码。目标是在既有主文档中补齐催缴对象生成规则、`IF-REV-013` / `IF-EXT-008` 的职责边界、四态结果语义、历史查询与处置追溯口径，并同步治理台账，使后续研发可基于统一口径继续立项。
-
-目标文档包括：
-
-- `docs/design/02_Detailed_Design/12_REV_Detailed.md`
-- `docs/design/03_Technical_Design/03_Interface_Design.md`
-- `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
-- `docs/design/00_Management/01_Project_Progress.md`
-- `docs/design/00_Management/03_Task_Checklist.md`
-
-## Technical Context
-
-**Primary Work Product**: Markdown 正式设计文档、治理台账与 Speckit 规划工件  
-**Source of Truth Documents**:
-
-- `docs/design/02_Detailed_Design/12_REV_Detailed.md`
-- `docs/design/03_Technical_Design/03_Interface_Design.md`
-- `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
-- `docs/design/01_Overview/03_Summary_Design.md`
-- `AGENTS.md`
-
-**Reference Sources**:
-
-- `docs/guides/BACKEND_CURRENT_STATUS.md`
-- `docs/design/04_Appendix/Archive/02_Manuals/营收系统_用户操作手册.md`
-- `docs/design/04_Appendix/Archive/03_Design_Docs/营业收费管理系统-概要设计说明书20250912.md`
-
-**Validation Commands**:
-
-- `make validate-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md`
-- `make validate-file FILE=docs/design/03_Technical_Design/03_Interface_Design.md`
-- `make validate-file FILE=docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
-- `make check-links`
-- `make validate-mermaid`
-
-**Target Scope**:
-
-- 收口 `REV-006` 详细设计章节
-- 收口 `IF-REV-013` 与 `IF-EXT-008` 承接口径
-- 回写 `SYS002-REQ-011` 的状态判断、后续研发切入点与治理结论
-- 规划 `01_Project_Progress.md` 与 `03_Task_Checklist.md` 的同步更新动作
-
-**Project Type**: 文档治理仓库  
-**Constraints**:
-
-- 不新增平行正式稿，只回写既有主文档或治理文档
-- 不臆造 backend 已实现能力
-- Archive 仅作为来源核对，不直接替代正式口径
-- 编号、术语、相对路径、Mermaid 图与正文必须一致
-- 正式系统名称统一为“福建水务营收系统”
-
-**Scale/Scope**: 跨文档设计收口与治理同步，覆盖详设、接口、管理台账三类文档
-
-## Constitution Check
-
-*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
-
-- [x] **主文档归属已确认**：本次改动只落在 `12_REV_Detailed.md`、`03_Interface_Design.md`、`15_SYS002_Requirement_Breakdown.md` 及管理台账，不新增平行正式稿。
-- [x] **范围基线已确认**：`REV-006` 已同时出现在 `03_Summary_Design.md`、`12_REV_Detailed.md` 与 Archive 范围内，属于可直接推进的交集范围。
-- [x] **Archive 使用方式合规**：Archive 仅作为旧系统催缴记录、停水记录、预存短信场景的来源核对，不直接作为正式文档替身。
-- [x] **一致性影响已列出**：受影响项包括 `REV-006` 模块编号、`IF-REV-013` / `IF-EXT-008` 编号边界、四态状态集、催缴/停复水术语、历史查询口径与 Mermaid 流程图。
-- [x] **校验与台账动作已规划**：已明确单文件校验、全仓链接校验、Mermaid 校验，并规划同步更新 `01_Project_Progress.md` 与 `03_Task_Checklist.md`。
-
-## Project Structure
-
-### Documentation (this feature)
-
-```text
-specs/006-reminder-event-design/
-├── plan.md
-├── research.md
-├── data-model.md
-├── quickstart.md
-├── contracts/
-│   ├── if-rev-013.md
-│   └── if-ext-008.md
-└── tasks.md
-```
-
-### Repository Touchpoints
-
-```text
-docs/design/
-├── 00_Management/01_Project_Progress.md
-├── 00_Management/03_Task_Checklist.md
-├── 00_Management/15_SYS002_Requirement_Breakdown.md
-├── 01_Overview/03_Summary_Design.md
-├── 02_Detailed_Design/12_REV_Detailed.md
-├── 03_Technical_Design/03_Interface_Design.md
-└── 04_Appendix/Archive/
-```
-
-**Structure Decision**:
-
-- `12_REV_Detailed.md`：承载 `REV-006` 的业务流程、规则、核心数据与落地边界
-- `03_Interface_Design.md`：承载 `IF-REV-013` / `IF-EXT-008` 的业务接口定义与边界说明
-- `15_SYS002_Requirement_Breakdown.md`：承载 `SYS002-REQ-011` 的实现判断、建议粒度与推进说明
-- `01_Project_Progress.md`：登记本轮正式文档收口动作与验证结果
-- `03_Task_Checklist.md`：登记 `REV-006` 相关治理任务的完成状态
-
-## Phase 0: Outline & Research
-
-### Research Inputs
-
-- 既有 `REV-006` 章节是否已足够承载催缴对象生成、四态结果和联动边界
-- `IF-REV-013` / `IF-EXT-008` 的职责拆分是否与 `SYS-002` / `SYS-010` 边界一致
-- 当前 backend 未见实现骨架的结论，如何在正式文档与治理台账中保守表达
-
-### Phase 0 Deliverable
-
-- [/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/research.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/research.md)
-
-### Research Conclusion
-
-- 无额外 `NEEDS CLARIFICATION` 留存。
-- 计划阶段可直接以“文档先行、实现待立项”为结论进入设计与合同化表达。
-
-## Phase 1: Design & Contracts
-
-### Planned Artifacts
-
-- [/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/data-model.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/data-model.md)
-- [/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/contracts/if-rev-013.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/contracts/if-rev-013.md)
-- [/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/contracts/if-ext-008.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/contracts/if-ext-008.md)
-- [/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/quickstart.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/quickstart.md)
-
-### Design Decisions
-
-- 以“催缴候选对象 -> 催缴任务 -> 消息协同 -> 四态回写 -> 处置追溯”的业务链路组织文档，而非按旧系统页面零散堆砌。
-- 历史催缴、停水、预存短信统一按“历史只读查询口径”承接，不额外承诺独立在线主表。
-- 合同化产物只描述接口业务语义、字段边界和责任划分，不写成 backend API 已实现证明。
-
-## Post-Design Constitution Check
-
-- [x] **主文档归属保持不变**：Phase 1 产物用于规划与任务拆解，正式结论仍回流既有主文档。
-- [x] **范围未外溢**：设计仍限定在 `REV-006` 催缴与通知收口，不扩展到停复水审批或独立消息中心建设。
-- [x] **Archive 仍为引用源**：未把 Archive 内容直接升级为独立正式稿。
-- [x] **一致性风险已收敛**：四态状态集、接口编号、协同边界和历史查询术语已统一。
-- [x] **校验闭环已具备**：已有明确验证命令、管理台账更新点和后续 tasks 拆解基础。
-
-## Complexity Tracking
-
-本次计划无宪章违例项，无需额外豁免。

specs/006-reminder-event-design/quickstart.md

@@ -1,69 +0,0 @@
-# Quickstart: REV-006 催缴与通知事件设计收口
-
-## 1. 使用目标
-
-本 quickstart 用于指导评审者或文档维护者快速完成 `REV-006` 的正式文档收口验证，不用于验证 backend 运行功能。
-
-## 2. 建议执行顺序
-
-1. 打开 [spec.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/spec.md)，确认范围、四态状态和治理结论。
-2. 对照 [plan.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/plan.md)，确认本轮只修改既有主文档与管理台账。
-3. 对照 [data-model.md](/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/data-model.md)，检查催缴候选对象、任务、结果和处置引用的最小字段是否齐全。
-4. 对照 `contracts/if-rev-013.md` 与 `contracts/if-ext-008.md`，确认 `SYS-002` / `SYS-010` 分工、输入输出和失败语义一致。
-
-## 3. 正式文档修订检查点
-
-- `12_REV_Detailed.md`
-  - 是否写清催缴对象来源、策略分组、频控和四态状态
-  - 是否明确停复水/工单只作为联动边界和追溯引用
-- `03_Interface_Design.md`
-  - 是否统一 `IF-REV-013` 为正式业务接口编号
-  - 是否区分 `IF-REV-013` 与 `IF-EXT-008` 的责任边界
-- `15_SYS002_Requirement_Breakdown.md`
-  - 是否保持 `SYS002-REQ-011` 为“未见实现”
-  - 是否明确“文档已收口，backend 未见明确实现骨架”
-- `01_Project_Progress.md` / `03_Task_Checklist.md`
-  - 是否登记本轮文档收口与验证动作
-
-## 4. 最小验证命令
-
-```bash
-make validate-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md
-make validate-file FILE=docs/design/03_Technical_Design/03_Interface_Design.md
-make validate-file FILE=docs/design/00_Management/15_SYS002_Requirement_Breakdown.md
-make check-links
-make validate-mermaid
-```
-
-## 5. 完成判定
-
-满足以下条件即可进入 `/speckit.tasks`：
-
-- `REV-006` 的业务规则、接口边界、历史查询和处置追溯口径已统一
-- `SYS002-REQ-011` 的实现判断与后续研发切入点已写入治理台账
-- 验证命令已纳入计划，且无新增平行正式稿
-
-## 6. 2026-03-19 实施结果
-
-### 已完成文档
-
-- `docs/design/02_Detailed_Design/12_REV_Detailed.md`
-- `docs/design/03_Technical_Design/03_Interface_Design.md`
-- `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
-- `docs/design/00_Management/01_Project_Progress.md`
-- `docs/design/00_Management/03_Task_Checklist.md`
-
-### 验证结果
-
-- `make validate-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md`：通过，0 个问题
-- `make validate-file FILE=docs/design/03_Technical_Design/03_Interface_Design.md`：通过，0 个问题
-- `make validate-file FILE=docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`：通过，0 个问题
-- `make check-links`：通过，当前检查范围内未发现断链
-- `make check-mermaid-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md`：已确认目标文件存在 6 个 Mermaid 图表
-- `make validate-mermaid`：已执行两次，但在当前环境下未返回最终结果；结合 Makefile 逻辑，该目标只校验仓库根目录 `*.md`，未直接覆盖本轮主要修改文件，后续如需全仓 Mermaid 终态结果，应单独排查该目标在当前环境中的阻塞原因
-
-### 当前结论
-
-- `REV-006` 已完成 implement 阶段的正式文档二次收口
-- `SYS002-REQ-011` 继续维持“未见实现”，但 Speckit 工件链、正式文档口径与治理台账已对齐
-- 当前剩余风险不是文档口径缺失，而是后续 backend 立项与 `make validate-mermaid` 全仓目标在本环境中的执行阻塞

specs/006-reminder-event-design/research.md

@@ -1,46 +0,0 @@
-# Phase 0 Research: REV-006 催缴与通知事件设计收口
-
-## Decision 1: 以既有主文档承载 `REV-006` 收口
-
-**Decision**: 正式设计收口继续落在 `12_REV_Detailed.md`、`03_Interface_Design.md` 与 `15_SYS002_Requirement_Breakdown.md`，不新建平行正式稿。  
-**Rationale**: `REV-006` 已在概要、详设、接口与治理台账中具备入口，当前问题是规则与边界不够收敛，而不是缺少载体。继续使用主文档符合单一真源原则。  
-**Alternatives considered**:
-
-- 新建独立“催缴设计说明书”：会制造平行正式稿，违背宪章。
-- 仅在 spec 工件中描述：无法替代正式交付文档与治理台账。
-
-## Decision 2: `SYS-002` 与 `SYS-010` 按“业务侧任务控制 / 渠道侧触达执行”分界
-
-**Decision**: `SYS-002` 负责催缴对象筛选、任务生成、事件编号、四态状态承接、历史查询与处置引用；`SYS-010` 负责短信、微信、站内信等渠道触达及结果回传。  
-**Rationale**: 该分界已在 `12_REV_Detailed.md` 与 `03_Interface_Design.md` 形成一致表达，能够避免“催缴任务生成”和“消息发送执行”职责混写。  
-**Alternatives considered**:
-
-- 由 `SYS-010` 同时负责催缴任务控制：会让外部系统承担业务主控，不符合现有模块分工。
-- 由 `SYS-002` 同时负责所有消息发送：会弱化 `IF-EXT-008` 的外部协同边界。
-
-## Decision 3: 正式状态集固定为四态
-
-**Decision**: `REV-006` 状态集固定为 `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED`。  
-**Rationale**: 四态已在详设与接口文档中同步表达，且足以覆盖受理中、成功、失败、人工补记三类核心语义。增加更多细粒度状态会放大实现假设。  
-**Alternatives considered**:
-
-- 增加“已阅读”“已补发”等状态：超出当前正式口径，也缺少 backend 证据支持。
-- 仅保留成功/失败二态：不足以表达异步回写与人工核查场景。
-
-## Decision 4: 历史催缴、停水、预存短信按只读查询口径承接
-
-**Decision**: 旧系统催缴记录、停水记录、预存短信记录统一作为历史查询和追溯范围承接，不默认扩展为新系统已确认在线主表。  
-**Rationale**: 当前 backend 未确认独立催缴台账、停水汇总表等实体；保守表达可同时满足迁移查询需求和事实一致性。  
-**Alternatives considered**:
-
-- 直接定义新在线主表：缺少代码和数据库证据。
-- 完全忽略历史场景：会让迁移核查、客户历史查询和处置追溯失去正式口径。
-
-## Decision 5: 当前实施结论维持“文档已收口，backend 未见明确实现骨架”
-
-**Decision**: 计划阶段保留 `SYS002-REQ-011` 为“未见实现”，并把本轮产出定位为文档收口和后续研发立项输入。  
-**Rationale**: 现有治理文档已经给出相同结论，且当前未检索到明确的 `Reminder/Message/Notice` controller/service 骨架。  
-**Alternatives considered**:
-
-- 升级为“部分实现”：会放大现有消息协同或历史查询描述，和证据不匹配。
-- 直接按“已实现”处理：与仓库现状冲突。

specs/006-reminder-event-design/spec.md

@@ -1,126 +0,0 @@
-# Feature Specification: REV-006 催缴与通知事件设计收口
-
-**Feature Branch**: `006-reminder-event-design`
-**Created**: 2026-03-18
-**Status**: Ready for Planning
-**Input**: User description: "rev006-reminder-event-design"
-
-## Document Scope & Sources *(mandatory)*
-
-- **Target documents**:
-  - `docs/design/02_Detailed_Design/12_REV_Detailed.md`
-  - `docs/design/03_Technical_Design/03_Interface_Design.md`
-  - `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
-  - `docs/design/00_Management/01_Project_Progress.md`
-  - `docs/design/00_Management/03_Task_Checklist.md`
-- **Primary source of truth**:
-  - `docs/design/02_Detailed_Design/12_REV_Detailed.md`
-  - `docs/design/03_Technical_Design/03_Interface_Design.md`
-  - `docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
-  - `docs/design/01_Overview/03_Summary_Design.md`
-  - `AGENTS.md`
-- **Reference sources**:
-  - `docs/guides/BACKEND_CURRENT_STATUS.md`
-  - `docs/design/04_Appendix/Archive/02_Manuals/营收系统_用户操作手册.md`
-  - `docs/design/04_Appendix/Archive/03_Design_Docs/营业收费管理系统-概要设计说明书20250912.md`
-- **Scope decision**: In scope. 本 feature 聚焦 `REV-006` 催缴与通知的正式设计收口，补齐催缴对象生成、任务分组、`IF-REV-013` / `IF-EXT-008` 协同边界、四态状态语义、历史查询口径、停复水/工单联动追溯和后续研发立项输入；不在本轮直接承诺 backend 已落地催缴业务实现。
-
-## User Scenarios & Testing *(mandatory)*
-
-### User Story 1 - 收口催缴任务生成规则 (Priority: P1)
-
-作为文档维护者，我需要把 `REV-006` 的催缴触发时机、催缴对象筛选条件、策略分组规则和四态状态定义写清楚，使评审者能够明确欠费账单如何进入催缴任务，以及哪些场景属于自动催缴、人工补发或人工核查补记。
-
-**Why this priority**: 当前 `REV-006` 已有第一轮场景描述，但后续研发立项仍依赖更清晰的触发规则、筛选条件和状态语义。
-
-**Independent Test**: 单独评审 `12_REV_Detailed.md` 中 `REV-006` 章节，应能明确催缴对象来源、触发规则、四态状态和人工核查边界。
-
-**Acceptance Scenarios**:
-
-1. **Given** 当前文档只概括“按策略分组催缴任务”， **When** 评审者阅读补齐后的详细设计， **Then** 能明确欠费账单、账龄、金额、客户类别、渠道偏好和频控规则如何形成催缴对象与任务。
-2. **Given** 后续需要据此拆解研发任务， **When** 维护者依据该规格评估实现切入点， **Then** 能区分自动催缴、人工补发、人工核查补记和停复水联动的边界。
-
----
-
-### User Story 2 - 统一 IF-REV-013 与消息协同边界 (Priority: P2)
-
-作为接口设计评审者，我需要看到 `IF-REV-013` 和 `IF-EXT-008` 的职责分工、请求输出、回写字段和四态结果承接口径，使 `SYS-002` 与 `SYS-010` 的边界不再停留在抽象表述。
-
-**Why this priority**: `REV-006` 的核心风险在于业务筛选、任务状态承接和外部通知执行边界不清，容易出现“任务生成”和“消息发送”职责混写。
-
-**Independent Test**: 单独评审接口主文档和需求拆解台账，应能确认 `IF-REV-013` 的业务侧职责、`IF-EXT-008` 的外部协同职责以及四态回写字段。
-
-**Acceptance Scenarios**:
-
-1. **Given** 评审者查看接口设计， **When** 阅读 `IF-REV-013` 章节， **Then** 能明确任务生成、任务查询、人工核查和结果承接的请求路径、字段与状态语义。
-2. **Given** 评审者查看需求拆解文档， **When** 阅读 `SYS002-REQ-011` 对应内容， **Then** 能明确当前属于“设计已收口、实现未见骨架”的状态，而不是误判为已实现。
-
----
-
-### User Story 3 - 形成治理与研发切入结论 (Priority: P3)
-
-作为后续立项和治理跟踪人员，我需要在台账和进度记录中看到 `REV-006` 的当前结论、最小实现切入点和校验动作，避免文档收口后仍无法指导后续研发排期。
-
-**Why this priority**: `REV-006` 当前在治理台账中属于未见实现，需要通过本轮 feature 明确“文档先行、实现待立项”的真实结论和后续切入点。
-
-**Independent Test**: 单独检查治理文档，应能定位 `REV-006` 当前状态、最小研发切入点、台账同步动作和验证要求。
-
-**Acceptance Scenarios**:
-
-1. **Given** 项目需要安排后续研发排期， **When** 查看需求拆解和项目进度， **Then** 能明确 `REV-006` 当前是设计收口完成、backend 未见明确实现骨架、可继续立项推进的状态。
-2. **Given** 本轮完成正式文档修订， **When** 查看进度与任务清单， **Then** 能定位本次 `REV-006` 文档治理动作及其最小校验结果。
-
----
-
-### Edge Cases
-
-- 当欠费账单已被收费、作废或进入其他处置流程时，催缴对象是否仍可进入任务生成，文档必须如何表达排除条件？
-- 当 `SYS-010` 只返回发送受理结果而未立即返回终态时，四态状态如何在 `SYS-002` 侧保持一致？
-- 当旧系统存在催缴记录、停水记录和预存短信等历史查询场景，但当前 backend 未确认独立落表时，文档如何保持“历史只读承接”而不误写为现成在线表？
-- 当人工核查补记场景发生时，哪些字段必须记录核查说明、关联任务号和后续处置引用？
-
-## Requirements *(mandatory)*
-
-### Functional Requirements
-
-- **FR-001**: Specification MUST identify the exact target documents for `REV-006` reminder-event alignment and governance sync.
-- **FR-002**: Specification MUST identify `12_REV_Detailed.md`、`03_Interface_Design.md`、`15_SYS002_Requirement_Breakdown.md` as the main source-of-truth set for this feature.
-- **FR-003**: Specification MUST record that this feature is in scope only for reminder-candidate generation, task rules, `IF-REV-013` / `IF-EXT-008` interface boundary, four-state result semantics, historical query boundary, and governance sync.
-- **FR-004**: Specification MUST preserve the single-source-of-truth model and MUST NOT create a parallel formal design document for `REV-006`.
-- **FR-005**: Specification MUST define reminder-candidate selection conditions, including arrears status, aging, amount, customer category, channel preference, strategy grouping, and frequency-control boundary.
-- **FR-006**: Specification MUST define the formal four-state reminder result set as `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED`, including the intended meaning of each state.
-- **FR-007**: Specification MUST define the exact business boundary of `IF-REV-013`, including task generation, task query, manual verification, result acceptance, and historical query support.
-- **FR-008**: Specification MUST define the external collaboration boundary of `IF-EXT-008`, clarifying that `SYS-010` is responsible for channel delivery while `SYS-002` retains business-side task and state control.
-- **FR-009**: Specification MUST define the minimum write-back and traceability fields for reminder results, including task number, event number, strategy code, channel type, trigger type, status, failure reason, and disposal reference.
-- **FR-010**: Specification MUST define how reminder results link to stop-water, restore-water, work-order, or manual follow-up references without expanding those downstream internal workflows.
-- **FR-011**: Specification MUST define historical query and export expectations for reminder records, including customer, bill period, reminder channel, target receiver, send time, execution result, related bills, and disposal references.
-- **FR-012**: Specification MUST explicitly capture the current implementation judgment as “文档已收口，backend 未见明确催缴/通知业务实现骨架” unless stronger evidence is found later.
-- **FR-013**: Specification MUST identify the minimum validation actions after document updates, including affected file validation, link checks, and Mermaid checks where flows are updated.
-- **FR-014**: Specification MUST state that important formal document changes under this feature require synchronized updates to `01_Project_Progress.md` and `03_Task_Checklist.md`.
-
-### Assumptions
-
-- 本 feature 以正式文档收口和后续研发立项准备为目标，默认不在本轮直接承诺 backend 业务代码实现。
-- `IF-REV-013` 继续作为 `REV-006` 的正式业务接口编号，不复用其他 `IF-REV-*` 编号。
-- `SYS-010` 负责短信、微信公众号、站内信等触达执行；`SYS-002` 保留催缴对象筛选、任务生成、四态状态承接和历史查询职责。
-- 当前 backend 中未见明确的 `Reminder/Message/Notice` 业务控制器或服务骨架，因此实现状态保持“未见实现”。
-- 催缴记录、停复水记录和预存短信等历史场景在本轮按“历史只读查询口径”承接，不默认要求新建平行在线主表。
-
-### Key Entities *(include if feature involves data)*
-
-- **Reminder Candidate**: 由欠费账单、账龄、欠费金额、客户类别、联系方式和命中策略组成的催缴输入对象。
-- **Reminder Strategy**: 定义账龄规则、金额规则、客户类别规则、渠道优先级、频控策略和后续联动关注条件的策略对象。
-- **Reminder Task**: 一次正式催缴执行单元，至少包含 `taskNo`、`eventNo`、`strategyCode`、`channelType`、`triggerType`、`status` 和关联账单集合。
-- **Reminder Result**: 催缴任务的四态结果及其失败原因、执行时间、外部回写摘要和业务侧处置引用。
-- **Disposal Link**: 催缴结果与停复水、工单、人工核查等后续处置之间的追溯引用对象。
-- **Governance Record**: 用于在需求拆解、项目进度和任务清单中登记本轮 `REV-006` 收口结论和后续研发建议的治理记录。
-
-## Success Criteria *(mandatory)*
-
-### Measurable Outcomes
-
-- **SC-001**: 评审者可在 5 分钟内从规格中定位 `REV-006` 的目标文档、催缴对象生成规则、接口边界和排除项。
-- **SC-002**: 规格中至少覆盖 3 类独立可评审内容：催缴任务生成规则、`IF-REV-013` / `IF-EXT-008` 边界、治理与研发切入结论。
-- **SC-003**: 规格明确区分至少 6 项关键任务或结果要素，如 `taskNo`、`eventNo`、`strategyCode`、`channelType`、`triggerType`、`status`、失败原因、处置引用。
-- **SC-004**: 后续执行 `/speckit.plan` 时，规划者无需再补充范围澄清即可将工作拆分为详细设计收口、接口收口、治理同步和实现切入点评估四类任务。
-- **SC-005**: 规格明确列出全部必要验证动作，审阅者可直接据此执行至少 4 项文档校验或一致性检查。

specs/006-reminder-event-design/tasks.md

@@ -1,164 +0,0 @@
-# Tasks: REV-006 催缴与通知事件设计收口
-
-**Input**: Design documents from `/specs/006-reminder-event-design/`
-**Prerequisites**: `plan.md` (required), `spec.md` (required), `research.md`, `data-model.md`, `contracts/`, `quickstart.md`
-
-**Validation**: Validation tasks are NOT optional in this repository. Every document change task set includes applicable validation and ledger-sync tasks.
-
-**Organization**: Tasks are grouped by user story so each document-maintenance slice can be completed, reviewed, and validated independently.
-
-## Format: `[ID] [P?] [Story] Description`
-
-- **[P]**: Can run in parallel (different files, no dependencies)
-- **[Story]**: Which user story this task belongs to (`US1`, `US2`, `US3`)
-- Every task names the exact file path to update or validate
-
-## Phase 1: Setup
-
-**Purpose**: Confirm the working boundary, source-of-truth set, and impacted files before editing formal documents.
-
-- [x] T001 Confirm target files and impacted chapters in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/spec.md`
-- [x] T002 Confirm source-of-truth and allowed references in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/plan.md` and `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/research.md`
-- [x] T003 [P] Confirm entity and contract inputs in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/data-model.md`, `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/contracts/if-rev-013.md`, and `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/contracts/if-ext-008.md`
-- [x] T004 [P] Confirm governance sync targets in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/01_Project_Progress.md`, `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/03_Task_Checklist.md`, and `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
-
----
-
-## Phase 2: Foundational
-
-**Purpose**: Establish the shared editing baseline that all user stories depend on.
-
-- [x] T005 Normalize `REV-006`, `IF-REV-013`, `IF-EXT-008`, and four-state terminology alignment notes in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/plan.md`
-- [x] T006 Identify exact `REV-006` anchors, Mermaid scope, and cross-reference touchpoints in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md` and `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/03_Interface_Design.md`
-- [x] T007 Map governance evidence and current implementation conclusion for `SYS002-REQ-011` in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
-
----
-
-## Phase 3: User Story 1 - 收口催缴任务生成规则 (Priority: P1) 🎯 MVP
-
-**Goal**: 补齐 `REV-006` 在详细设计中的催缴对象生成、策略分组、频控边界、四态状态和历史只读承接口径。
-
-**Independent Test**: 单独评审 `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md` 的 `REV-006` 章节，应能明确催缴对象来源、排除条件、四态状态、人工核查边界和停复水联动追溯关系。
-
-### Implementation for User Story 1
-
-- [x] T008 [US1] Update `REV-006` rules, candidate selection, frequency-control, and exclusion conditions in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md`
-- [x] T009 [US1] Sync `Reminder Candidate`, `Reminder Task`, `Reminder Result`, and `Disposal Link` field coverage in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md` using `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/data-model.md`
-- [x] T010 [US1] Align historical reminder, stop-water, and prestored-message read-only boundary wording in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md`
-- [x] T011 [US1] Run `make validate-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md` and record the result in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/quickstart.md`
-- [x] T012 [US1] Run `make validate-mermaid` for `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md` flow updates and record the result in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/quickstart.md`
-
-**Checkpoint**: User Story 1 is reviewable and validated independently.
-
----
-
-## Phase 4: User Story 2 - 统一 IF-REV-013 与消息协同边界 (Priority: P2)
-
-**Goal**: 在接口主文档中统一 `IF-REV-013` 与 `IF-EXT-008` 的职责分工、输入输出、四态回写和失败阻断语义。
-
-**Independent Test**: 单独评审 `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/03_Interface_Design.md`，应能区分 `SYS-002` 的业务任务控制职责与 `SYS-010` 的渠道触达职责，并定位最小回写字段。
-
-### Implementation for User Story 2
-
-- [x] T013 [US2] Update `IF-REV-013` business boundary, request paths, and state semantics in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/03_Interface_Design.md`
-- [x] T014 [US2] Update `IF-EXT-008` collaboration boundary, acceptance/callback semantics, and failure mapping in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/03_Interface_Design.md`
-- [x] T015 [US2] [P] Sync minimum traceability fields and manual-verify/write-back semantics in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/03_Interface_Design.md` using `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/contracts/if-rev-013.md`
-- [x] T016 [US2] Run `make validate-file FILE=docs/design/03_Technical_Design/03_Interface_Design.md` and record the result in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/quickstart.md`
-- [x] T017 [US2] Run `make check-links` after interface document updates and record the result in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/quickstart.md`
-
-**Checkpoint**: User Story 2 is reviewable and validated independently.
-
----
-
-## Phase 5: User Story 3 - 形成治理与研发切入结论 (Priority: P3)
-
-**Goal**: 在需求拆解和管理台账中沉淀 `REV-006` 的当前状态、最小研发切入点、文档收口动作和验证结论。
-
-**Independent Test**: 单独评审 `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`、`/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/01_Project_Progress.md`、`/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/03_Task_Checklist.md`，应能定位 `SYS002-REQ-011` 的“未见实现”判断、本轮文档收口和后续研发建议。
-
-### Implementation for User Story 3
-
-- [x] T018 [US3] Update `SYS002-REQ-011` implementation judgment, evidence wording, and next-step recommendation in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
-- [x] T019 [US3] Update the REV-006 change record and validation summary in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/01_Project_Progress.md`
-- [x] T020 [US3] Update the REV-006 governance completion items in `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/03_Task_Checklist.md`
-- [x] T021 [US3] Run `make validate-file FILE=docs/design/00_Management/15_SYS002_Requirement_Breakdown.md` and record the result in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/quickstart.md`
-- [x] T022 [US3] Re-check that `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/01_Project_Progress.md` and `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/03_Task_Checklist.md` reflect the same REV-006 closure status
-
-**Checkpoint**: User Story 3 is reviewable and validated independently.
-
----
-
-## Final Phase: Polish & Cross-Cutting Concerns
-
-**Purpose**: Ensure repository-wide consistency after all story slices are complete.
-
-- [x] T023 [P] Re-check `REV-006`, `IF-REV-013`, `IF-EXT-008`, and four-state terminology consistency across `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md`, `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/03_Interface_Design.md`, and `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/15_SYS002_Requirement_Breakdown.md`
-- [x] T024 [P] Re-check relative links, anchors, and Mermaid consistency across `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/02_Detailed_Design/12_REV_Detailed.md`, `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/03_Technical_Design/03_Interface_Design.md`, `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/01_Project_Progress.md`, and `/Volumes/Dpan/github/fujian_water_biz_doc/docs/design/00_Management/03_Task_Checklist.md`
-- [x] T025 Prepare final delivery summary and remaining-risk note in `/Volumes/Dpan/github/fujian_water_biz_doc/specs/006-reminder-event-design/quickstart.md`
-
----
-
-## Dependencies & Execution Order
-
-### Phase Dependencies
-
-- **Setup**: No dependencies; must finish before document edits
-- **Foundational**: Depends on Setup and must finish before user story execution
-- **US1**: Depends on Foundational and is the MVP slice
-- **US2**: Depends on US1 terminology and boundary baseline
-- **US3**: Depends on US1 and US2 conclusions so governance wording can reflect final design state
-- **Final Phase**: Depends on all selected user stories being complete
-
-### User Story Dependency Graph
-
-```text
-US1 -> US2 -> US3
- \______________-> Final Phase
-```
-
-### Within Each User Story
-
-- Update target document content before running validation
-- Complete validation before marking governance sync as done
-- Complete ledger sync before final cross-check
-
-## Parallel Execution Examples
-
-### US1
-
-```text
-T008 -> T009
-T010 can run after T008 in parallel with T009
-```
-
-### US2
-
-```text
-T013 -> T014
-T015 can run in parallel once T013 and T014 establish the final interface wording
-```
-
-### US3
-
-```text
-T019 and T020 can run in parallel after T018
-```
-
-## Implementation Strategy
-
-### MVP First
-
-先完成 US1，只收口 `12_REV_Detailed.md` 的 `REV-006` 规则与状态语义，形成最小可评审增量。
-
-### Incremental Delivery
-
-1. 用 US1 固化催缴对象、四态状态和历史只读边界。
-2. 用 US2 固化 `IF-REV-013` / `IF-EXT-008` 的接口职责与回写语义。
-3. 用 US3 回写治理台账和后续研发切入点。
-4. 最后统一做跨文档一致性复核和交付摘要。
-
-## Notes
-
-- 所有任务均保持“主文档单一真源”原则，不新增平行正式稿。
-- Archive 只用于核对来源，不作为正式结论直接输出。
-- 本任务清单面向文档实施，不默认包含 backend 代码开发任务。