ADR 0000 - ADR 记录什么（以及不记录什么）

ADR 记录的是架构决策及其理由——我们决定了什么、为什么，是在列举的备选方案中作出选择，并附上由此产生的权衡。该决策约束此后代码的写法。

ADR 不是已完成工作的变更日志，也不是未来工作的待办清单。

1. 结构

每份 ADR 依主题不同，包含以下各节（可酌情调整）：

• Context（背景）——促使决策的情境（当前存在什么、要解决什么问题）。此处可出现当前状态以框定决策，但不是工作流水账。
• Decision（决策）——所作的选择，表述为一条长期有效的规则。
• Considered（备选方案）——被否决的方案，以及原因。
• Consequences（后果）——该决策的结构性影响（使什么更易、更难或成为必需），正反两面。

2. 纪律

• Consequences 是影响，而非工作日志。「现在 N 个二进制编译同一份测试体」是后果；「我们写了 44 个测试」是变更日志条目——后者不应出现在 ADR 中。已完成的度量和 bug 修复归入追踪产物。
• 不设 Follow-up / TODO 节。 未来工作归入 issue 追踪器或相关追踪文件，而非 ADR。
• 每个 ADR 一个决策。 本身即构成决策的变更（例如改变公开 API 行为）应单立一份 ADR；不要折进不相关 ADR 的 Consequences。
• 代码风格规则（格式、命名）归入 CONTRIBUTING 等其他位置，不归此处——ADR 位于风格之上。

3. 范围

为重大且难以撤销的设计选择撰写 ADR：新的测试工作流、追踪模型、类别体系、全生态机制。不要为日常实现撰写 ADR。