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 的外部协同。

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

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

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

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