实施前置条件规约

适用：任何聚合出设计文档或生成代码之前。 配套清单由各项目自行维护（不走文档站），落盘 docs/design/prerequisites.md；模板示例见仓库 docs/design/documentation/实施前置条件清单示例.md。

1. 什么是前置条件

项目级的技术事实，必须在出设计文档或生成代码之前由人确认。与聚合级澄清分工不同：

类型	例子	谁确认	频率	落点
项目级	数据库类型、事件总线、Outbox 开关	技术负责人 / 架构	一次，随技术演进改	项目自己的前置条件清单
聚合级	某个 Q 走 ES 还是数据库直读、业务待确认项	业务方 + 技术负责人	每个需求	各自设计文档 §10、投影文档 §1.3

聚合级不进项目清单，避免把项目决策稀释成单聚合决策。

2. 清单结构

固定 10 项，字段固定为：编号 / 前置条件 / 结论。各项的影响范围与阻断关系统一见 §4。

3. 三条硬规则

1. 有结论才算已确认：结论非空且不是「待确认」。
2. 「待定」不允许跨迭代存活：一个迭代结束时仍待定的项，必须在评审上给出结论或明确「不涉及」。
3. 未确认即阻断：不是提醒，是对应产出不生成，映射见 §4。

4. 阻断映射

未确认项	未确认时禁止产出
数据库类型与版本	DDL、Mapper、TypeHandler 装配
事件总线	事件配置类、订阅装配；多选时每种总线各自一套装配与 topic
是否启用 Outbox	执行器选型、outbox 表与装配
补偿模式	补偿动作、compensation 表
Redis 版本与客户端	Redis 副本、缓存投影、序列化配置
ES 版本与安全开关	ES 副本、索引 mapping、客户端配置
ID 生成方式	工厂、事件的即时 / 延迟判定
部署实例数	清理任务、对账并发、补偿幂等
时区	时间字段口径、跨时区展示
多租户 / 数据隔离	查询条件、索引、缓存 key 前缀

5. 冲突与变更

• 可多选项：事件总线允许同时选多个（RocketMQ / Kafka / ThreadPool），结论列写全选中的类型，并说明各承载哪些事件；单选也是合法结论。
• 冲突以清单为准：设计文档写的与清单不一致时，按清单改文档，不改清单迁就文档。
• 清单只增不删：新增项必须写明「为什么它是前置条件」；确实作废的项标「已废弃」并保留行，不物理删除。
• 技术升级改清单：受影响的聚合设计文档打「需复核」标记，并列出需要重看的章节。

6. 使用顺序

1. 出设计文档前读清单，未确认项记进写设计文档 §10.3。
2. 写设计文档时，涉及未确认项的章节只写结构和占位，不写结论。
3. 生成代码前逐项核对阻断映射，缺项不生成。
4. 确认完成后回填清单，同步解除对应章节的「待确认」。

7. 与其他文档的关系

前置条件	落到哪里
数据库、ES、Redis 版本	投影文档 §4（读源结构）、写文档 §7（持久化）
事件总线、Outbox、补偿模式	写文档 §6.4 执行器选型、§6.7 补偿
ID 生成方式	写文档 §6.2 工厂
部署实例数	写文档 §10.4 待核实 + 装配层
时区、多租户	语义文档属性口径、投影条件族