决策触发
知应触发架构决策而非仅任务的事件。
为什么
非每选择是架构决策——"哪个 linter"是任务、"哪个数据库"是决策。把任务当决策（过度流程）慢团队；把决策当任务（欠流程）意味着 DB 选择由接工单者做、无理由记录。决策触发是应升为正式决策的事件：新外部依赖、跨团队接口、贵反转的选择。前定触发意味着正确决策自动获正确流程。
何时使用
定义一次、持续应用。2 小时定义触发列表。季度重访。
如何做
1. 列应触发正式决策（ADR+评审）的事件： - 加新外部依赖（DB、队列、框架、SaaS） - 贵反转的选择（> 1 工程周改） - 跨团队接口（API 契约、数据格式、事件 schema） - 影响值班的选择（新技运维） - 影响成本 > 1 千/月的选择 2. 列非决策事件（仅任务）： - 内部重构、linter 配、测框架、内部命名 3. 触发发时工作暂停直到 ADR 写+评审 4. 触发列表可见（在 CONTRIBUTING.md）让人人知标准 5. 月度审计：有决策无 ADR 吗？加触发
示例
触发列表（在 CONTRIBUTING.md）： - 新 DB/缓存/队列 → 需 ADR - 新框架或主库（>1000 星、成依赖）→ ADR - 破消费者的 API 契约变 → ADR + 消费者评审 - 加新值班技能的任何 → ADR + 值班签 - 成本影响 > 1 千/月 → ADR + 财务评审 非决策（仅 PR）： - 内部重命名、linter 规、测工具、服务内重构 审计：上月"加 Redis"无 ADR → 加"新数据存储"触发。
常见问题
- ⚠把每选择当决策——团队淹在 linter 配的 ADR 里且不再为重要事写。
最佳实践
- ✓触发列表保持短（5-7 项）——太多触发人绕流程；太少决策意外做。
- ✓当决策无 ADR 时评审触发列表——缺口通常是缺触发非流程违规。