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

## 1. 文档目的

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

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

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

---

## 2. 一张总图

```text
福建水务营收系统
  ↓
收费与账单主链
  - 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 这四块能力在业务链上的位置

```text
账单 / 收费结果
  ├─ 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 用符号再看一遍

```text
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 业务依赖

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

## 5.2 方法依赖

```text
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. 一个可以直接执行的推进顺序

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

```text
第一步：补完 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`