决策评审
定期评审过去决策以抓过时、并从老化好或差学。
为什么
2 年前决策现在可能错——厂商 EOL、团队专长变、规模超选择。无定期评审这些过时决策累积为技术债人人抱怨无人重查。决策评审是季度读 ADR 日志、标上下文变的决策、确认或取代的实践。也是学习：比我们预测的（后果节）vs 发生的揭哪些决策者校准、哪些标准预测。评审决策的团队更会做。
何时使用
季度、2 小时。仅 ADR 日志 < 10 决策可跳过。
如何做
1. 读 ADR 日志（所有已接受 ADR、最旧先） 2. 每个问：上下文变了吗？ - 厂商仍可行？团队专长仍准？规模仍在范围？ 3. 标上下文变的决策 → 取代候选 4. 取代候选写新 ADR 引旧的+解释变 5. 老化好的决策记什么使其耐久（校准数据） 6. 老化差的决策记漏了什么（反校准数据） 7. 与团队分享评审摘要——学习是重点
示例
Q3 ADR 评审（12 ADR）： ADR-003（API 用 Lambda）：上下文变——流量长 20 倍、Lambda 现 5 倍成本 → 被 ADR-024 取代（移 Fargate）、引 ADR-003 ADR-007（目录用 Mongo）：老化好——访问模式仍适、无问题 → 记："读重目录用文档存储耐久" ADR-011（用 REST 非 gRPC）：老化差——内部服务现要类型 RPC → 被 ADR-025 取代（内部 gRPC、外部 REST） 学习：成本决策规模变时老化差； 适配决策老化好。回顾分享。
常见问题
- ⚠评审但不取代——团队同意决策过时但无人写新 ADR、过时仍"已接受"；取代否则非评审。
最佳实践
- ✓评审限时 2 小时——更长则变每决策重审；标并过。
- ✓随时间追校准数据——"基于成本的决策 60% 错"是改未来决策的元学习。