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