3.1 KiB
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:
- 升级为“部分实现”：会放大现有消息协同或历史查询描述，和证据不匹配。
- 直接按“已实现”处理：与仓库现状冲突。