fujian_water_biz_doc/docs/guides/SYSTEM_CAPABILITY_CLOSURE_MAP.md

营收系统能力地图与闭环进度图

1. 文档目的

本文用于回答三个实际问题：

1. 当前 REV-004、REV-005、REV-006、REV-007 分别在补系统的哪一块能力？
2. 这些 feature 当前各自走到了 spec / plan / tasks / implement / verify / 回写 的哪一步？
3. 如果目标是“继续把系统实现出来”，下一轮最应该优先闭哪一块？

这份图不是替代 specs/，而是把多个 feature 的局部闭环放到同一张系统视角里，帮助统一判断整体推进顺序。

---

2. 一张总图

福建水务营收系统
  ↓
收费与账单主链
  - REV-002 开账计费与账单生成
  - REV-003 收费核销处理
  ↓
账后控制与结果链
  - REV-004 账务处理一期
  - REV-005 发票业务流
  - REV-006 催缴与通知
  - REV-007 营收统计查询
  ↓
主文档 / 接口设计 / 数据库设计 / 台账 / evidence 持续统一
  ↓
系统级大闭环

这条链的意思不是“后面的 feature 必须等前面的全做完才能动”，而是：

• REV-004、REV-005、REV-006、REV-007 都属于收费后处理与经营结果链条
• 它们既可以分阶段推进，也必须最终回到统一的主文档、接口、数据库和治理台账上

---

3. 当前能力地图

3.1 feature 与系统能力的对应关系

Feature	系统能力类型	核心目标	当前角色
REV-004	账后控制能力	统一账务调整、退款、冲正、坏账申请的一期边界、接口、留痕和状态口径	底座型闭环
REV-005	发票结果链能力	打通发票申请、外部协同、查询兜底、结果回写与客户侧消费	流程型闭环
REV-006	催缴协同能力	打通催缴对象生成、通知协同、结果回写、停复水边界和历史查询口径	协同型闭环
REV-007	经营观察能力	明确统计主题、指标口径、查询维度、接口边界和数据承接口径	观察型闭环

3.2 这四块能力在业务链上的位置

账单 / 收费结果
  ├─ REV-004：账后调整与异常处理
  ├─ REV-005：发票申请、开具、回写、客户消费
  ├─ REV-006：欠费提醒、通知协同、结果承接
  └─ REV-007：经营统计、收费统计、欠费统计、渠道分析

因此这四个 feature 不是平级替代关系，而是共同围绕“收费后的业务控制、结果消费、消息协同、经营观察”形成系统后半段。

---

4. 闭环进度图

4.1 统一阶段定义

为了避免“已经做了很多”但说不清做到哪，下面统一用六段来标识每个 feature 的阶段：

1. spec：范围和验收口径已锁定
2. plan：结构、依赖、接口/数据设计已组织
3. tasks：任务拆解已能直接指导执行
4. implement：文档或代码已进入实际落地
5. verify：已有验证证据或待补证据边界已明确
6. ledger sync：主文档、进度台账、任务台账已统一回写

4.2 当前 feature 闭环进度

Feature	spec	plan	tasks	implement	verify	ledger sync	当前判断
REV-004	已完成	已完成	已完成	文档 implement 已完成	文档校验已完成	已完成	文档闭环完成，代码闭环未启动
REV-005	已完成	已完成	已完成	已进入 backend implement 并完成 US1~US4	Verification Pending	已完成	实现态闭环基本完成，运行态证据待补
REV-006	已完成	已完成	已完成	implement 阶段文档收口已完成	文档校验已完成	已完成	治理闭环完成，backend 仍未见明确实现
REV-007	已完成	已完成	已完成	implement 阶段正式文档收口推进中	文档校验与治理校验为主	已完成	设计闭环已建立，代码入口未见明确实现

4.3 用符号再看一遍

REV-004: spec ✓ -> plan ✓ -> tasks ✓ -> implement(文档) ✓ -> verify(文档) ✓ -> ledger ✓
REV-005: spec ✓ -> plan ✓ -> tasks ✓ -> implement(代码+文档) ✓ -> verify(运行态待补) △ -> ledger ✓
REV-006: spec ✓ -> plan ✓ -> tasks ✓ -> implement(文档) ✓ -> verify(文档) ✓ -> ledger ✓
REV-007: spec ✓ -> plan ✓ -> tasks ✓ -> implement(文档) ✓ -> verify(设计/治理) ✓ -> ledger ✓

最关键的区别是：

• REV-004 / REV-006 / REV-007 当前主要是“文档与治理闭环”
• REV-005 已经进入“代码实现闭环”

这决定了后续系统推进的优先级不能一刀切。

---

5. 依赖关系图

5.1 业务依赖

REV-002/REV-003 产出账单与收费结果
  ↓
REV-004 处理账后调整、退款、冲正、坏账
  ↓
REV-005 消费收费/账单结果形成发票闭环
  ↓
REV-006 基于欠费/催缴对象形成通知协同闭环
  ↓
REV-007 对账单、收费、欠费、渠道、客户结果做统计观察

5.2 方法依赖

REV-004 先统一账务状态、留痕、原交易校验口径
  ↓
有助于 REV-005 / REV-006 / REV-007 在状态、日志、追溯上保持一致

因此：

• REV-004 更像后续 feature 的控制骨架
• REV-005 更像当前最接近真实交付的结果链
• REV-006 更像待转实现的协同链
• REV-007 更像待转实现的观察链

---

6. 从“小闭环”到“系统大闭环”的拼接方式

6.1 feature 内部怎么闭

每个 feature 先把自己内部的小闭环闭起来。

REV-004

• 范围闭环：五类场景收敛
• 合同闭环：IF-REV-007
• 共性能力闭环：留痕、原始依据、结果状态、审批边界
• 治理闭环：执行手册、项目进度、任务清单回写

REV-005

• 申请闭环：后台发票申请与校验
• 协同闭环：SYS-008 异步申请与查询兜底
• 回写闭环：发票状态、账单关联、客户侧消费
• 二期入口闭环：作废与红冲最小入口
• 验证闭环：实现态证据已补，运行态样本待补

REV-006

• 设计闭环：催缴对象、通知事件、结果状态四态、停复水边界
• 接口闭环：IF-REV-013 与 IF-EXT-008
• 治理闭环：implement 阶段文档收口与台账回写

REV-007

• 设计闭环：统计主题、维度、指标与排除项
• 接口闭环：IF-REV-010
• 数据闭环：聚合来源与承接口径
• 治理闭环：实现评估与正式台账回写

6.2 feature 之间怎么拼

系统大闭环不是再额外建一个“超级文档”，而是依靠四类统一机制把它们接起来：

1. 主文档统一
   所有结论最终回到 12_REV_Detailed.md、03_Interface_Design.md、01_Database_Design.md

2. 台账统一
   重要动作回写 01_Project_Progress.md、03_Task_Checklist.md

3. 接口统一
   各 feature 都落到同一套 IF-* 体系中

4. 数据承接口径统一
   不让每个 feature 各自发明自己的状态、日志、承接模型

这四类统一机制的作用就是：

让上一个闭环的输出，自动成为下一个闭环的稳定输入。

---

7. 当前系统视角下的真实判断

7.1 哪些 feature 已经是“稳定能力块”

• REV-004：是，文档与治理层面已稳定
• REV-005：是，已形成实现态稳定能力块
• REV-006：是，设计与治理层面已稳定
• REV-007：是，设计与治理层面已稳定

7.2 哪些 feature 还不是“完整业务闭环”

• REV-004：还不是完整实现闭环，因为代码侧尚未启动
• REV-006：还不是完整实现闭环，因为 backend 仍未见明确实现
• REV-007：还不是完整实现闭环，因为代码入口仍未见明确实现
• REV-005：最接近完整业务闭环，但仍缺运行态样本、联调统计与物理 DDL 风险闭合

7.3 当前系统最大的断点在哪里

当前最大的断点不是设计断点，而是：

设计闭环与实现闭环之间的转换断点。

换句话说：

• REV-006 和 REV-007 都已经具备进入实现的前置条件
• 但还没有真正转成 backend 可验证的实现链

这说明现在系统推进的主矛盾，已经不是“要不要继续补文档”，而是：

哪一块设计基线应当最先转成实现闭环。

---

8. 面向“系统实现”为目标的优先级建议

8.1 第一优先级：完成 REV-005 的 verify 收口

原因：

• 它是四个 feature 里唯一已经深入到 backend implement 的
• 再补少量运行态证据，就能形成最完整的一条真实业务闭环
• 这会给后续 feature 提供一个“设计如何转实现、实现如何转验证”的标准样板

建议优先补：

• 运行态联调样本
• T055、T060 ~ T063 对应的验证记录
• biz_invoice 物理 DDL / migration 风险的最终判断

8.2 第二优先级：启动 REV-006 的 backend 最小实现闭环

原因：

• REV-006 已完成 spec -> plan -> tasks -> implement(文档) 全链条
• 它适合作为“从设计闭环转实现闭环”的下一块
• 相比 REV-007，它更直接落在业务控制与消息协同链上，更贴近真实业务运行

最小切入建议：

• 先做催缴对象生成
• 再做通知事件触发
• 再做结果回写
• 最后做停复水边界联动

8.3 第三优先级：评估 REV-004 二期还是 REV-007 实现入口

这一步要看你的系统目标偏哪边：

• 如果更偏“业务控制完善”，优先 REV-004
• 如果更偏“经营观察与管理看板”，优先 REV-007

当前从系统运行价值看，我更建议：

REV-004 优先于 REV-007。

原因是：

• REV-004 会影响退款、冲正、坏账、账务状态与留痕一致性
• 这是多个后续流程共享的控制骨架
• REV-007 的价值也高，但它更偏“看清系统”，不是“先让系统可控”

---

9. 一个可以直接执行的推进顺序

如果以“尽快把系统大闭环往前推”为目标，建议按下面顺序推进：

第一步：补完 REV-005 verify 收口
  目标：形成第一条最完整的实现态业务闭环

第二步：启动 REV-006 backend 最小实现
  目标：把设计闭环成功转成协同实现闭环

第三步：启动 REV-004 二期实现
  目标：把账务控制骨架从文档闭环转成实现闭环

第四步：启动 REV-007 最小查询实现
  目标：让经营观察能力从“设计已定义”进入“查询可验证”

这条顺序的逻辑是：

• 先拿 REV-005 固化“实现闭环样板”
• 再拿 REV-006 证明“设计闭环可转实现闭环”
• 再拿 REV-004 固化系统控制骨架
• 最后拿 REV-007 打开经营观察能力

---

10. 结论

当前仓库已经不是“还在摸索 feature 是什么”，而是已经形成了四块明确的系统能力板块。

真实状态可以概括为：

• REV-004：账务控制骨架已闭合，待转实现
• REV-005：实现链最完整，待补运行态证据
• REV-006：协同设计已闭合，待转实现
• REV-007：统计设计已闭合，待转实现

因此，从系统大闭环视角看，下一阶段最重要的事情不是继续横向铺更多 spec，而是：

把已经完成设计闭环的能力块，逐步转成实现闭环。

这就是当前从“文档治理阶段”走向“系统实现阶段”的真正分水岭。

---

11. 参考依据

本文基于以下仓内工件整理：

• specs/001-rev004-accounting/
• specs/002-rev005-invoice-flow/
• specs/003-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/design/00_Management/15_SYS002_Requirement_Breakdown.md