tangweijie 3eccab2cf9 docs: 文档治理统一 — AGENTS.md 生命周期规则 + 模块归档 + DDL 修正

1. AGENTS.md 更新
   - water-docs: 新增 specs/ 与 docs/design/ 生命周期规则章节
   - water-backend: 更新协作引用（建设期/建成后、evidence 模块化）

2. specs/ 重复合并
   - 006-reminder-event-design 合并入 003-rev006-reminder-event-design
   - 001-rev004-accounting 删除冗余 data-model.md + contracts/
   - 002-rev005-invoice-flow 删除冗余 data-model.md + contracts/

3. evidence 按模块归档
   - 35 个 REV-004 文件归入 evidence/rev004-accounting/
   - 7 个通用 bugfix 文件归入 evidence/bugfix/ 和 bugfix/frontend/
   - 新建 rev005-invoice/、rev006-reminder/、rev007-statistics/ 目录

4. guides/ 清理
   - 14 个 REV004_*.md 移入 evidence/rev004-accounting/

5. 遗留文件处理
   - docs/research/ 归档到 Archive/06_Migration_Plans/
   - backend-check detached worktrees 清理

6. 交叉引用修复
   - 006-reminder-event-design → 003-rev006-reminder-event-design
   - docs/guides/REV004_ → docs/evidence/rev004-accounting/REV004_

7. DB 设计文档修正（01_Database_Design.md）
   - biz_invoice 明确为开票配置表，非发票记录表
   - 新增 biz_invoice_record 为发票申请/结果主表
   - 新增 biz_charge_invoice_rel 账单-发票关联说明
   - REV-005 承接口径表名全部修正

8. 发票审计证据
   - 新增 evidence/rev005-invoice/2026-06-16-invoice-document-audit.md

2026-06-16 11:47:16 +08:00

3.1 KiB

Raw Blame History

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:

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

3.1 KiB Raw Blame History Unescape Escape