# Phase 0 Research: REV-006 催缴事件与通知协同设计

## 决策 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` 的外部协同。

## 决策 2：催缴结果状态固定为四态

- **Decision**: `REV-006` 正式状态集固定为 `PENDING`、`SUCCESS`、`FAIL`、`MANUAL_VERIFIED`。
- **Rationale**:
  - 四态足以覆盖“待回写/待核查”“成功触达”“失败”“人工核查确认”四类评审和实施必需场景。
  - 过少状态会导致补偿与人工核查无法落地；过多状态会在当前未实现阶段引入不必要的细粒度设计。
  - 四态同时便于后续接口、数据库和台账统一。
- **Alternatives considered**:
  - 两态（成功/失败）：无法表达未回写和人工核查状态。
  - 三态（待处理/成功/失败）：无法区分人工核查后的确认结果。
  - 更细状态（已送达/已阅读/已补发）：当前阶段超出设计收口所需。

## 决策 3：停复水仅定义联动边界，不展开内部流程

- **Decision**: 本 feature 仅定义催缴结果与停复水之间的联动边界、触发条件、查询字段和追溯关系，不展开停复水内部处置流程、审批节点或现场执行细节。
- **Rationale**:
  - 停复水属于后续业务处置链，深入展开会把当前专题扩展到工单/现场作业子系统。
  - 当前 `REV-006` 的首要目标是把催缴闭环范围和责任边界收口，而不是设计全部后置处置流程。
  - 这样既能满足历史查询和审计追溯，又不破坏范围控制。
- **Alternatives considered**:
  - 把停复水完整流程纳入 `REV-006`：被否决，因为会扩大到非本轮范围。
  - 完全不写停复水联动：被否决，因为会留下历史查询和后续处置链断点。

## 决策 4：历史“催缴记录/停水记录/预存短信”按历史只读口径承接

- **Decision**: 旧系统“催缴记录、停水记录、预存短信记录”继续按历史只读查询对象承接，不新增同名在线主表；在线主模型以 `biz_charge`、操作留痕和消息协同结果为主。
- **Rationale**:
  - `01_Database_Design.md` 已对这些对象给出“历史只读保留”口径，且当前 backend 未见明确独立表族。
  - 直接新增同名新表会违反“不得臆造已实现事实”和“单一真源”的原则。
  - 历史只读策略既能满足迁移验收，也不影响后续按业务链逐步演进。
- **Alternatives considered**:
  - 为每个旧菜单新增在线主表：被否决，因为没有实现证据且破坏当前主模型。
  - 完全不保留历史查询口径：被否决，因为不满足迁移验收和追溯要求。

## 决策 5：`REV-006` 与 `SYS-010` 的职责分界

- **Decision**: `SYS-002/REV-006` 负责催缴对象筛选、任务分组、业务事件生成、状态承接、历史查询和处置关联；`SYS-010` 负责短信、微信公众号、站内信等触达执行与结果回传。
- **Rationale**:
  - 该分界与 `03_Interface_Design.md` 中跨系统协同表一致。
  - 业务筛选和状态归属留在 `SYS-002`，能保证催缴逻辑与账单口径一致。
  - 触达能力放在 `SYS-010`，避免 `REV-006` 越权扩展到消息平台实现。
- **Alternatives considered**:
  - 让 `SYS-010` 负责催缴对象筛选：被否决，因为会削弱营收主系统对账单规则的控制。
  - 让 `SYS-002` 直接承担全部消息发送：被否决，因为与既有系统边界不一致。