Wenjie Zhang工程决策记录
决策记录保存非平凡变更的当前判断、真实替代方案、接受的代价和验证。它补充代码与当前文档，不替代二者。
生命周期
proposed/：尚未实现的提案；必须写问题、候选方案、验收标准和风险。implemented/：已经生效的当前决定；使用现在时，只保留问题、决策、替代方案、后果和验证。rejected/：明确拒绝且值得保留原因的提案；不构成当前实现要求。archived/：冻结历史，不能修改或作为当前权威。当前机制必须链接到新的 owning record。
提案实现后，把记录移动到 implemented/ 并改写为当前事实；不要保留迁移 checklist、进度日志或”应当”式 spec。决定被部分取代时，在新旧记录中交叉链接；完全失去当前价值时，将旧记录移到 archived/，或在理由已经被新记录完整吸收后删除。任何记录移入 archived/ 前先改写为问题、决策、替代方案、后果、验证结构，不保留提案、进度或迁移章节。
非平凡工作必须在实现前创建 proposed。小而完整、在同一变更中已经生效且没有待裁决替代或风险的修复可直接写 implemented，但 PR 必须解释为何不需要 proposal；不得用 diff 大小或文件数量自动判定 trivial。完整流程见 Yuxi Spec Loop。
何时需要
满足任一条件即为非平凡：
- 改变重要工程主张的语义 Owner、commit/publication 边界、oracle、负向案例或实际 gate。
- 改变持久状态、事务发布点、权限、worker 生命周期、模型可见输入或兼容承诺。
- 引入新的抽象、依赖、配置、fallback、状态机或长期维护表面。
- 接受一个并不显然、未来可能重开的工程取舍。
局部文案、机械重命名和不改变行为的等价清理可以免除，但 PR 要明确说明原因。
格式
文件名使用 YYYY-MM-DD-topic.md。所有记录包含：
# 决策标题
状态：implemented
类型：feature
Owner：path/to/owner
## 问题
## 决策
## 替代方案
## 后果
## 验证
类型 只使用 feature、bug-fix、simplification、architecture、process、testing。Owner 指向拥有当前行为的首要代码、契约或文档；一项决定跨越多个事实 Owner 时，在正文明确分工，不能让 decision record 反向成为运行时事实源。
proposed 使用 ## 问题、## 提案、## 替代方案、## 验收标准、## 风险，并在验收标准中包含以下证据矩阵：
| 验收主张 | 失败面 | 语义 Owner | 直接证据 / 命令 | 负向案例 | 当前结果 |
|---|---|---|---|---|---|
simplification 提案和 implemented 记录还必须分别在 ## 验收标准 或 ## 验证 中包含 旧能力不存在： 与 重新引入条件：，避免只增加替代物而不删除旧表面。rejected 说明拒绝原因。不要保存 chain-of-thought、逐步实现叙事、Review 对话、人员评价或敏感数据。