📝 docs: ADR 状态定稿 —— 六条决策标 Accepted，新增「实施」列区分决策与代码 - #35
Conversation
六条 ADR 的状态行都还写着 Proposed，而每条都注明「随 PR 评审定稿」—— 设计 PR 早已评审合并，状态只是没跟上。 改为把两件事拆开记： - 状态 = 决策本身的状态。设计 PR 合并即 Accepted，六条全部改为 Accepted， 并在括号里注明是随哪个设计 PR 定稿的（0001-0004 随 #14，0005 随 #23， 0006 随 #28）。 - 实施 = 代码的落地程度。每条 ADR 新增一行、索引表新增一列，标出落地它的 PR，以及尚未动工的部分：0002 §6 的 recency 衰减项、0004 的 serve、 0005 的模式 B、0006 的 ④。 这样「决策已定」与「代码已写」不再挤在同一个词里，索引表一眼能看出哪条 还欠着什么。纯文档改动，无代码变更。 Co-Authored-By: Claude <noreply@anthropic.com>
xnne-bot
left a comment
xnne-bot
left a comment
There was a problem hiding this comment.
方向是对的，把「架构决策」与「代码实施」解耦很清晰。
回答 PR 里关于 0004 / 0005 的提问：
支持全部标记为 Accepted。ADR 记录的是架构决策本身，设计 PR 评审合并即代表决策在架构层面被采纳；是否暂缓服务或分期开发属于代码实施层面的进度，不影响决策已生效的事实。拆出「实施」列正好精准解决了这个信息混淆的问题。
文档链接和状态对应无误，无 blocking 问题，可以合并。
评审确认了 0004 / 0005 也标 Accepted，理由是：设计 PR 评审合并即代表决策在 架构层面被采纳，暂缓（0004 的 serve）或分期开发（0006 的 ④）属于实施进度， 不改变决策已经生效这件事。 这个问题会被问出来，本身说明原来那句说明还不够明确 —— 它只说了两列各记什么， 没说清"欠着的部分该去哪一列看"。补上这条规则和它对应的具体例子，并直说：想知道 某条决策还欠什么，看「实施」列，不要看「状态」列。 Co-Authored-By: Claude <noreply@anthropic.com>
|
确认收到，0004 / 0005 按你的判断全部保持 不过你这条提问本身暴露了一个问题：原来那句说明不够明确。它只交代了两列各记什么，没交代「欠着的部分该去哪一列看」—— 所以「serve 暂缓了，状态还能算 Accepted 吗」才会成为一个需要问的问题。既然会被问一次，就会被问第二次。
最后一句是刻意加的：新读者的默认直觉是去「状态」列找完成度，而这张表恰恰不是那样组织的。 PR 描述里那节「需要你拍板的一点」已改写成结论，不再挂着一个已经答完的问题。四道闸门重跑仍全绿（196 passed, 1 skipped，纯文档改动）。 另外一个合并顺序上的提醒：本 PR 里 0005 的实施列写的是「模式 B 未做」，这在 |
#36 合并后顺手核对了一遍项目自己的状态声明，发现落后现实**两个里程碑**： | 文件 | 声称 | 实际 | |---|---|---| | README.md | **M3（当前）**，M4 CLI 是将来时 | CLI 在 #12 就落地了 | | README.zh-CN.md | 同上 | 同上 | | docs/guide/what-is-wikimem.md | M4 CLI「(next)」 | 同上 | | docs/zh/guide/what-is-wikimem.md | M4「（下一步）」 | 同上 | 另外两处：README 与 guide 之间**互相矛盾**（一个说 M3 是当前、一个说 M3 已完成）； 而 **M5（日记 + 时间门控）—— 本仓库迄今最大的一块工作 —— 四份状态清单里一次 都没出现过**。 改动： - M3/M4 标 ✅，补上 M5（#16 #17 #19 + #26 #27 #31），补上 M6 = serve（暂缓）。 M5 / M6 这两个编号不是我编的：ADR-0001、ADR-0002 的「实施」段就把日记与时间 门控划为 M5，ADR-0004 把 serve 划为 M6。 - 四份清单末尾统一加一句：**M5 之后按决策跟踪、不按里程碑**，指向 ADR 索引。 这条是防复发的 —— 里程碑清单本来就不再是这个项目的状态载体了，让它继续假装 是，下一条 ADR 落地时它就会再次过期。 - 同步 ADR-0005：模式 B 已由 #36 落地，实施行与索引行从「⚠️ 模式 B 未做」 改为「✅ 模式 A #24、模式 B #36」。这是我在 #35 里承诺合并后补的那一处。 CLI 确实存在，不是照 PR 记录推断的 —— `uv run wikimem --help` 五个子命令 （ls/show/grep/explain/graph）都在。文档站本地 `pnpm build` 通过（VitePress 默认对死链报错，因此新加的 `/adr/README` 链接是通的；该路径线上实测 200， `/adr/` 反而是 404）。 Co-authored-by: MrXnneHang <xnnehang@gmail.com> Co-authored-by: Claude <noreply@anthropic.com>
2 participants
动机
六条 ADR 的状态行都还写着
Proposed，但每一条都注明「随 PR 评审定稿」—— 设计 PR 早就评审合并了，状态只是没跟上。更麻烦的是，光靠一个词说不清两件不同的事：决策定没定 和 代码写没写。ADR-0004 的 serve 被明确暂缓、ADR-0005 只有模式 A、ADR-0006 的 ④ 在等 bench 数据 —— 这些信息目前在索引表里一点都看不到，读者只能看到六个一模一样的
Proposed。解决方案
把两件事拆成两个字段记。
状态 = 架构决策本身的状态。 设计 PR 评审合并即代表决策在架构层面被采纳，六条全部改为
Accepted，括号里注明随哪个设计 PR 定稿：实施 = 代码的落地程度。 每条 ADR 新增一行
- **实施**：，索引表新增一列，标出落地它的 PR 与仍欠着的部分：0004 / 0005 是否也标 Accepted —— 已确认 ✅
评审确认：支持全部标记为 Accepted。理由是设计 PR 评审合并即代表决策在架构层面被采纳；是否暂缓服务或分期开发属于代码实施层面的进度，不影响决策已生效的事实。
6c8958c把这条规则本身写进了索引说明 —— 这个问题会被问出来，本身就说明原来那句只讲了「两列各记什么」，没讲清「欠着的部分该去哪一列看」：验证
纯文档改动，零代码变更。四道闸门在本地全绿（与 CI 同命令）：
引用的 PR / issue 编号都用
gh pr list --state merged与gh issue view逐个核对过，不是凭记忆写的 —— 尤其 #20 / #21 确认是 CLOSED 而非 merged。git diff main --stat只有docs/adr/下 7 个文件。合并后的一个跟进项
本 PR 里 0005 的实施列写的是「模式 B 未做」—— 这在
main上此刻为真，但 #36 正在把模式 B 做掉。两个 PR 都改docs/adr/README.md同一行会冲突，所以我没有在 #36 里提前改。 本 PR 合并后，我会在 #36 上补一个 commit，把 0005 的实施行与索引行同步成「模式 A #24、模式 B #36」。类型