@liangjie559567/ultrapower 5.5.2 → 5.5.3

package/docs/reviews/draft-prd-memory-evolution-optimize/review_critic.md

@@ -0,0 +1,302 @@
+# Critic 评审报告（安全与边缘情况）
+
+**评审者**: axiom-critic
+**评审时间**: 2026-03-02
+**评审对象**: PRD v0.2 - Axiom 记忆与进化系统 Token 使用效率优化
+
+---
+
+## 总体评分
+
+**5 / 10**
+
+PRD 所列的已知风险均已描述，但在安全性和逻辑严谨性两个维度存在多处遗漏。核心问题在于：T4 的状态标记名称内部自相矛盾（`auto_evolve_done` vs `auto_evolve`），T3 v1/v2 的接口语义不统一，`stop_hook_active` 守卫在现有代码中并无对应实现，以及若干并发写入和边界值场景未被处理。这些问题若进入实现阶段，将直接导致功能行为不可预测。
+
+---
+
+## 评审意见
+
+### 1. 安全性问题
+
+#### 1.1 归档文件路径：路径遍历风险（P0 级别评估）
+
+PRD 将归档路径硬编码为 `.omc/axiom/evolution/learning_queue_archive.md` 和 `.omc/axiom/evolution/reflection_log_archive.md`，属于固定路径，**本身不存在路径遍历漏洞**。
+
+然而，隐患存在于**触发链**上：
+
+- T1 的归档触发时机是"ax-evolve 处理完一批条目后"。ax-evolve 的 LQ 条目内容（`内容` 字段、`元数据` 字段）是由系统自动生成并写入的，但 `learning_queue.md` 是纯 Markdown 文件，**不经过任何输入消毒**。
+- 若恶意内容（例如通过 ax-reflect 写入的会话内容）在 `内容` 字段中包含文件路径片段（如 `../../.claude/settings.json`），这些内容会被**原样写入归档文件**。
+- 归档文件本身不执行，写入无害。但若后续有代码从归档文件中提取路径并做文件操作（未来扩展），则构成路径遍历预留风险。
+- **当前 PRD 版本不涉及动态路径构建，故严重程度为 LOW**，但须在未来实现中明确标注"归档路径不可来自文件内容"。
+
+#### 1.2 MiniSearch 查询输入净化（HIGH）
+
+PRD 第 3 节 T3 描述 `ax-knowledge` 接受 `--filter <keyword>` 参数，交由 MiniSearch 执行全文匹配（模糊搜索 fuzzy: 0.2 + 前缀 prefix: true）。
+
+**关键漏洞**：MiniSearch 本身是纯内存的 JavaScript 库，没有 SQL 注入面，但其**查询字符串未经净化时存在两类风险**：
+
+1. **正则注入（RegExp Injection）**：MiniSearch 在处理模糊查询时内部会构建正则表达式。若 `keyword` 参数包含 `[`, `]`, `*`, `+`, `?`, `{`, `}`, `(`, `)`, `\` 等正则特殊字符，可能导致正则异常（抛出 `SyntaxError: Invalid regular expression`）而**穿透降级路径**——即 MiniSearch 并非"加载失败"而是"查询抛异常"，现有降级逻辑（"MiniSearch 加载失败 → grep"）**不会捕获此场景**，ax-knowledge 将直接抛出未处理异常。
+   - 证据：LQ-006 已记录 Regex Injection 防护模式（k-034），说明项目已知晓此风险，但 PRD T3 v2 未引用此模式。
+   - 示例攻击输入：`ax-knowledge --filter "test[*"`
+
+2. **超长查询字符串**：无长度限制的 `--filter` 参数可触发 MiniSearch 在大数据集下的高 CPU 消耗。当前 62 条规模下影响有限，但 PRD 未定义最大查询长度。
+
+**建议**：在 TypeScript 层对 `keyword` 参数做以下处理：
+- 长度上限（建议 256 字符）
+- 正则特殊字符转义（参考 k-034 的转义模式：`str.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')`）
+
+#### 1.3 TOCTOU 竞争条件：SessionEnd hook 读取 active_context.md（HIGH）
+
+T4 的设计依赖以下顺序：
+
+```
+Step 1: 读取 active_context.md → 检查 auto_evolve_done 字段
+Step 2: 若字段不存在 → 执行 ax-evolve（3 条）
+Step 3: 执行完成后 → 写入 auto_evolve: true 到 active_context.md
+```
+
+**竞争条件场景**：在多工作区（worktree）环境中，或者用户同时打开两个 Claude Code 会话（共享同一 `.omc/axiom/` 目录），两个 SessionEnd hook 可能**并发触发**：
+
+- Session A 读取 active_context.md（Step 1），判断 `auto_evolve_done` 不存在，决定执行
+- Session B 读取 active_context.md（Step 1），同样判断不存在，决定执行
+- Session A 执行 ax-evolve，处理条目 LQ-031、LQ-032、LQ-033，写入 learning_queue.md
+- Session B 执行 ax-evolve，**同样**处理 LQ-031、LQ-032、LQ-033（因为 Session A 的写入可能尚未完成）
+- 结果：**同一批条目被处理两次**，knowledge_base.md 中写入重复知识条目，learning_queue.md 状态可能损坏
+
+这是经典的 **TOCTOU（Time-of-Check-Time-of-Use）** 问题。PRD 在"安全守卫"中仅提及 `stop_hook_active` 守卫，未处理并发 SessionEnd 场景。
+
+**严重性评估**：MEDIUM（多会话并发场景在日常使用中确实存在，特别是 Claude Code 允许在多个终端窗口打开同一项目）。
+
+**建议**：使用文件锁（`lockfile` 或写入专用的 `.lock` 文件 + 原子检查）或在 `active_context.md` 中使用 **写入再读取**（write-then-verify）模式替代 TOCTOU 易发的读写分离模式。
+
+#### 1.4 stop_hook_active 守卫：环境变量检查与实际代码不符（HIGH）
+
+PRD T4 第 5 条："安全守卫：hook 脚本入口检查 `stop_hook_active` 环境变量；若为 `true` 则立即退出"。
+
+**代码层核查发现**：
+
+- `templates/hooks/subagent-stop.mjs` 确实检查了 `stop_hook_active`，但该检查是从**JSON stdin 数据**中解构获取（`const { stop_hook_active } = data`），而非环境变量 `process.env.stop_hook_active`。
+- **PRD 描述与实际实现存在根本性差异**：PRD 说"检查环境变量"，实际代码检查的是"JSON 数据字段"。
+- 在 T4 新增的 SessionEnd hook 脚本中，若实现者按 PRD 描述做 `process.env.STOP_HOOK_ACTIVE === 'true'` 检查，该守卫将**完全失效**（SessionEnd hook 的触发上下文不提供此环境变量，Claude Code 通过 JSON 字段传递此标志）。
+- 更严重的是，**SessionEnd hook 天然不应收到 `stop_hook_active` 字段**（该字段只在 Stop hook 的 JSON payload 中存在），因此该守卫在 SessionEnd hook 中逻辑上是无意义的——PRD 声称这是"防 Stop hook 误触发"，但 SessionEnd hook 本身就不是 Stop hook，守卫的存在目的自相矛盾。
+
+**建议**：在 T4 的实现规格中明确：SessionEnd hook 脚本无需也不应检查 `stop_hook_active`；若要防止意外触发，应检查 `hook_event_name` 字段是否等于 `'SessionEnd'`。
+
+---
+
+### 2. 逻辑不一致
+
+#### 2.1 T1 阈值语义：`done > 10` 与 `done >= 10` 的歧义（MEDIUM）
+
+PRD 第 3 节 T1 第 1 条："主文件中 `done` 条目数超过 **10 条**时触发归档"——"超过 10 条"语义为 `done > 10`（即 done = 11 时触发）。
+
+但 PRD 第 5 节验收标准 T1 写道："触发归档后，主文件 done 条目数 `<= 10`"——这意味着**触发后保留最多 10 条**。
+
+流程图 4.1 写道：`{done 条目数 > 10?}` ——确认触发条件为 `done > 10`，即 done = 11 时触发，归档到 done = 10。
+
+**但** PRD 第 3 节 T1 第 4 条："主文件只保留……最近 10 条 `done` 条目"——这里"最近 10 条"是归档后的目标状态，对应 `done <= 10`，与 `done > 10` 的触发条件逻辑上一致。
+
+**问题**：如果有恰好 10 条 done 时执行 ax-evolve，将第 10 条的 pending 变为 done，done = 11，触发归档，归档后 done = 10。**但 PRD 第 3 节 T1 第 1 条描述是"超过 10 条时触发"，这意味着 done = 10 时不触发**——此处"超过"的文字语义为严格大于（`>`），而非大于等于（`>=`），实现时需要明确。
+
+**真正的逻辑缺陷**：若触发条件为 `done >= 10`（即恰好 10 条也触发），则每次 ax-evolve 将第 9 条变为 done（done = 10），立即触发归档，归档掉 0 条（因为要保留 10 条）——归档操作为空操作，造成无意义的 I/O。
+
+**建议**：明确语义为 `done > 10`（done = 11 时触发），并在代码注释中标注。
+
+#### 2.2 T4 状态标记名称内部不一致（HIGH — 功能级别缺陷）
+
+这是本 PRD **最严重的逻辑不一致**。
+
+PRD 第 3 节 T4：
+- 第 4 条（跳过条件）：通过读取 active_context.md 中的 `auto_evolve_done: true` 标记判断是否跳过
+- 第 6 条（触发标记）：自动触发完成后在 active_context.md 写入标记 `auto_evolve: true`
+
+**矛盾**：写入的是 `auto_evolve: true`，检查的是 `auto_evolve_done: true`——**两个不同的字段名**。
+
+按照 PRD 当前描述，系统将永远不会跳过自动触发：
+1. 第一次会话结束：`auto_evolve_done` 不存在 → 执行 ax-evolve → 写入 `auto_evolve: true`
+2. 第二次会话结束：检查 `auto_evolve_done`（仍不存在，因为写入的是 `auto_evolve`）→ 再次执行 ax-evolve
+3. **重复无限循环**（跨会话，每次都重新处理相同条目）
+
+这不是措辞问题，是**功能级别的逻辑错误**：跳过条件与写入条件检查的是两个不同名称的字段，导致跳过逻辑永久失效。
+
+实际代码中（`grep "auto_evolve" src/`）**没有找到任何现有实现**，说明这是纯设计层面的错误，尚未在代码中固化，应在 PRD 确认前修正。
+
+**建议**：统一字段名，两处均使用 `auto_evolve_done: true`，或均使用 `auto_evolve: true`，并在 PRD 中保持一致。
+
+#### 2.3 T3 v1 与 v2 的 `--filter` 参数语义不统一（MEDIUM）
+
+T3 v1（SKILL.md 层，基础方案）：`--filter <keyword>` 只返回 **Title 或 Category 包含关键词**的行（字段精确匹配）
+
+T3 v2（MiniSearch）：`--filter <keyword>` 执行**全文匹配**（title + content + tags 加权，支持模糊匹配 fuzzy: 0.2）
+
+验收标准（第 6 节）混合引用了两套语义：
+- "ax-knowledge --filter typescript 只返回 Title/Tags 含 typescript 的条目（MiniSearch 全文匹配）"
+- "过滤结果正确（无漏匹配、无误匹配）"
+
+**逻辑问题**：同一个验收标准，在 v1 环境下（MiniSearch 失败，降级到 grep）的行为与 v2 环境下**结果集不同**：
+
+- v2：`--filter typescript` 可能返回 content 含 "typescript" 但 Title 不含的条目（全文匹配）
+- v1/降级：`--filter typescript` 只返回 Title 或 Category 含 "typescript" 的条目（字段匹配）
+
+这意味着**降级路径的结果集是 v2 结果集的子集**，用户在降级状态下看到的结果比正常状态少，但 PRD 的验收标准未区分这两种状态下的预期行为，无法判断降级时是否"正确"。
+
+**更深的矛盾**：T3 v1 验收标准说 "MiniSearch 加载失败时自动降级至 grep 过滤，不抛异常"，但 T3 v1 本身就是 SKILL.md 层的 grep 过滤，v2 才是 MiniSearch。降级"从 v2 回到 v1"——所以 v1 的 grep 过滤**既是基础方案又是降级方案**，但 PRD 在两个位置（T3 v1 描述和降级路径描述）对该行为的描述逻辑重叠，未明确是否为同一实现。
+
+#### 2.4 流程图 4.1 中"会话结束检测"节点与 SessionEnd hook 技术实现不一致（LOW）
+
+PRD 第 3 节 T4 第 1 条明确："触发点：仅使用 SessionEnd hook（不使用 Stop hook）"。
+
+流程图 4.1 中使用 `J{会话结束检测}` 菱形判断节点，暗示这是一个**主动检测过程**。
+
+**不一致之处**：SessionEnd hook 是**被动触发机制**（Claude Code 在会话结束时主动调用），而非"检测"。图中的表述会让实现者误解为需要轮询或主动检测会话结束状态，而实际只需在 SessionEnd hook 的处理函数中追加 ax-evolve 逻辑即可。这不是功能缺陷，但会给实现者带来认知混乱，可能导致过度设计（例如引入不必要的轮询机制）。
+
+---
+
+### 3. 边缘情况遗漏
+
+#### 3.1 并发写入归档文件（HIGH）
+
+**场景**：用户在同一台机器上同时执行两次 `ax-evolve`（例如两个 Claude Code 窗口并发运行），T1 的归档操作同时触发：
+
+1. 进程 A：读取 learning_queue.md，统计 done = 15，决定归档 5 条
+2. 进程 B：读取 learning_queue.md，同样统计 done = 15，决定归档 5 条
+3. 进程 A：将 LQ-001~LQ-005 写入归档文件
+4. 进程 B：将 LQ-001~LQ-005 **也**写入归档文件（重复追加）
+5. 进程 A：重写主文件，删除 LQ-001~LQ-005
+6. 进程 B：重写主文件，**再次**删除 LQ-001~LQ-005（实际已无这些条目，可能损坏主文件结构）
+
+**结果**：归档文件中 LQ-001~LQ-005 被写入两次，违反了 PRD 声称的"幂等操作"。PRD 的幂等性声明实际上是**单进程幂等**，不是并发安全的。
+
+T2（reflection_log.md 滚动窗口）存在相同的并发写入问题。
+
+PRD 的"先写归档，再清理主文件"方案在并发场景下既不原子也不幂等。
+
+#### 3.2 knowledge_base.md 完全为空时的 MiniSearch 建索引行为（MEDIUM）
+
+当 `knowledge_base.md` 中无任何有效条目时（初始安装、全部迁移失败或文件为空），MiniSearch 的建索引行为：
+
+- 对空文档数组建索引：MiniSearch 允许，索引为空，查询返回空结果——**行为安全**
+- **真正的风险**：YAML front-matter 迁移失败导致**部分条目无法解析**。例如 62 条中有 3 条 YAML 格式错误，解析器会：
+  - 方案 A（严格模式）：整个 knowledge_base.md 解析失败，触发降级 → 但降级路径（grep）无法处理损坏的 YAML
+  - 方案 B（宽松模式）：跳过错误条目，只对59条建索引 → 用户不知道有 3 条被静默丢弃
+
+**PRD 未定义** YAML 解析部分失败时的行为（全失败 vs 宽松跳过），这是实现层的重要决策，应在 PRD 中明确。
+
+#### 3.3 reflection_log.md 有效条目恰好等于 20 条时的边界值行为（MEDIUM）
+
+PRD T2 第 2 条："滚动窗口：主文件保留最近 20 条完整反思记录"。
+
+**边界值歧义**：当 ax-reflect 写入**第 21 条**时，触发归档。但当前恰好 20 条时：
+
+- 触发条件应为 `count > 20`（写入后大于 20 才归档）还是 `count >= 20`（等于 20 即归档）？
+- PRD 第 3 节 T2 说"主文件保留最近 20 条"，暗示 `count <= 20` 是目标状态
+- 流程图 4.1 菱形节点写 `{反思条目数 > 20?}`，确认触发条件是严格大于 20
+
+但**边界 off-by-one 仍存在**：若触发条件为 `count > 20`，则 count = 20 时**不触发**；ax-reflect 写入第 21 条后 count = 21，触发归档，归档 1 条，保留 20 条——逻辑自洽。然而 PRD 验收标准写"新写入反思后，主文件反思条目数 `<= 20`"，这与 `count > 20` 触发一致，但实现者可能误读为"每次写入后都检查，若 = 20 就触发"。
+
+**建议**：验收标准改为"主文件反思条目数**恒**保持 <= 20（以 21 条写入测试验证）"，明确触发时机为"写入第 21 条后"。
+
+#### 3.4 T4 ax-evolve 处理中途失败的数据一致性（HIGH）
+
+PRD T4 第 2 条："每次自动触发最多处理 3 条 pending 条目"。
+
+**中途失败场景**：处理第 2 条（LQ-032）时，写入 knowledge_base.md 成功，但随后更新 learning_queue.md 中 LQ-032 的状态（pending → done）时崩溃。
+
+**结果**：
+- knowledge_base.md 中已有 LQ-032 的知识条目（k-XXX 已写入）
+- learning_queue.md 中 LQ-032 状态仍为 pending
+- 下次 SessionEnd 触发时，LQ-032 **再次被处理**，knowledge_base.md 中写入**重复的知识条目**（不同 ID 但相同内容）
+
+PRD 的风险表仅描述了"归档操作崩溃风险"，未描述 **ax-evolve 处理链中途崩溃**的一致性问题。T4 触发的 ax-evolve 属于增量处理，比 T1 的批量归档更难保证原子性。
+
+**建议**：明确 T4 的处理原子性要求：对每条 LQ 条目，必须**先更新 learning_queue.md 状态（pending → processing），再写知识库，再更新状态（processing → done）**。崩溃后下次可通过检查 `processing` 状态的条目恢复，而非重复处理 pending 条目。
+
+#### 3.5 首次安装时 learning_queue_archive.md 不存在的处理（MEDIUM）
+
+PRD T1 第 2 条："归档目标路径：`.omc/axiom/evolution/learning_queue_archive.md`（追加写入）"。
+
+**首次归档时**，该文件不存在。"追加写入"（append 模式）在 Node.js 中：
+
+- `fs.appendFileSync` 若文件不存在，**自动创建**——行为安全
+- `fs.open(path, 'a')` 同样自动创建——行为安全
+
+**但**，PRD 第 5.2 节验收标准："`learning_queue_archive.md` 存在且包含所有历史 done 条目（无内容丢失）"——这要求文件被**创建**。这在技术上自动完成，无需额外处理。
+
+**隐患**：归档文件所在目录 `.omc/axiom/evolution/` 在全新安装的系统中**可能不存在**。`fs.appendFileSync` 在目录不存在时会抛出 `ENOENT` 异常，不会自动创建目录。PRD 未提及首次安装时的目录初始化逻辑（对比：LQ-004 / k-032 记录了 `atomicWriteJson` 的目录自动创建能力，但归档操作若不使用 atomicWriteJson 就没有此保障）。
+
+#### 3.6 T4 的 3 条处理上限与实际 pending 数量的交互（LOW）
+
+**场景**：learning_queue.md 中有 50 条 pending 条目（长期积压）。每次 SessionEnd 处理 3 条，按此速率需要 ~17 次会话才能清空。
+
+**未被分析的副作用**：
+- 50 条 pending 时，前 17 次会话每次都触发 ax-evolve（3 条），最后第 18 次会话（剩 2 条）只处理 2 条——PRD 未明确是否允许处理少于 3 条（"最多 3 条"语义允许少于 3 条，但未明确）
+- 若 ax-evolve 的 pending 条目按优先级（P0/P1/P2/P3）处理，PRD T4 未声明自动触发时是否遵循优先级顺序——实现者可能默认按文件顺序（而非优先级）取前 3 条
+
+---
+
+### 4. PRD 自相矛盾
+
+#### 4.1 "触发点：仅使用 SessionEnd hook" 与流程图节点措辞（LOW）
+
+PRD 第 3 节 T4 第 1 条："触发点：仅使用 SessionEnd hook"——明确说明是被动的 hook 触发。
+
+流程图 4.1 节点 `J{会话结束检测}`——措辞"检测"暗示主动轮询/探测行为，与 SessionEnd hook 的被动触发机制在概念上矛盾。
+
+技术上不影响功能，但会造成实现者认知混乱，建议将节点描述改为 `J{SessionEnd hook 触发}`。
+
+#### 4.2 T3 验收标准混淆了 v1 和 v2 的过滤语义（MEDIUM）
+
+T3 验收标准第一条："ax-knowledge --filter typescript 只返回 Title/Tags 含 typescript 的条目（MiniSearch 全文匹配）"——**括号内"MiniSearch 全文匹配"与前文"Title/Tags 含"相矛盾**：
+
+- "Title/Tags 含 typescript"是**字段精确包含**判断（v1 基础方案语义）
+- "MiniSearch 全文匹配"是**跨字段全文搜索**（v2 语义）
+
+这两种描述对应不同的结果集：v2 全文匹配可能返回 Title 不含 "typescript" 但 content 含 "typescript" 的条目；而字段精确包含不会返回这类结果。验收标准**同时要求两种互相矛盾的语义**，导致无法确定正确实现的验证基准。
+
+#### 4.3 T4 标记名称的内部自相矛盾（已在 2.2 节详述）
+
+**跳过条件**：检查 `auto_evolve_done: true`
+**写入标记**：写入 `auto_evolve: true`
+
+两个不同字段名，导致跳过逻辑永久失效。这是本 PRD 中**唯一一个会导致实现后功能完全错误**的矛盾，严重程度 HIGH。
+
+---
+
+## 差异点（Diff Points）
+
+| ID | 描述 | 严重程度 | 建议 |
+|----|------|----------|------|
+| D-C01 | T4 状态标记名称自相矛盾：跳过条件检查 `auto_evolve_done: true`，但写入的是 `auto_evolve: true`，导致跳过逻辑永久失效，每次 SessionEnd 都会重复处理 | HIGH | 统一字段名，两处均使用 `auto_evolve_done: true`，并在 PRD 中同步修正验收标准第 5 条 |
+| D-C02 | `stop_hook_active` 守卫描述为"检查环境变量"，但实际代码（subagent-stop.mjs）从 JSON stdin 解构获取；更严重的是，SessionEnd hook payload 中不存在该字段，守卫在 SessionEnd hook 中逻辑上无意义 | HIGH | 删除 T4 中对 `stop_hook_active` 守卫的描述；在实现规格中改为"检查 hook_event_name === 'SessionEnd' 确认正确触发事件" |
+| D-C03 | TOCTOU 竞争条件：多窗口/多 worktree 场景下，两个 SessionEnd hook 并发执行可能导致相同的 LQ 条目被处理两次，knowledge_base.md 写入重复条目 | HIGH | 引入基于文件锁的互斥机制（在 SessionEnd ax-evolve 逻辑入口写 `.lock` 文件，完成后删除；检测到 lock 文件则跳过） |
+| D-C04 | T4 ax-evolve 中途崩溃的数据一致性：处理链"写知识库 → 更新 LQ 状态"若在写知识库后崩溃，下次重复处理同一条目导致知识库重复条目 | HIGH | 增加中间状态 `processing`：先将 LQ 状态设为 processing，再写知识库，再设为 done；崩溃恢复时跳过 done 条目，对 processing 条目做去重检查 |
+| D-C05 | MiniSearch `--filter` 参数未净化：包含正则特殊字符的查询字符串（如 `test[*`）可能导致 MiniSearch 内部抛出 RegExp SyntaxError，该异常不属于"MiniSearch 加载失败"，现有降级路径无法捕获 | HIGH | 在调用 MiniSearch 前，对 keyword 参数做正则特殊字符转义（参考项目已有 k-034 模式），并设置 256 字符长度上限 |
+| D-C06 | T3 v1/v2 的 `--filter` 参数语义不同：v1 做字段精确包含，v2 做全文模糊匹配；验收标准混用两套语义，导致降级状态下结果集不一致且无法判断是否正确 | MEDIUM | 分别为 v1（字段匹配）和 v2（全文匹配）定义独立的验收标准；明确降级时允许结果集缩小（subset 行为），并在用户文档中声明 |
+| D-C07 | 并发写入归档文件：两个 ax-evolve 实例并发执行时，T1/T2 的归档操作均无并发保护，可能造成归档文件重复写入和主文件双重修改 | MEDIUM | 归档操作入口使用进程级文件锁（`.omc/axiom/evolution/.archive.lock`），或使用 write-to-tmp-then-rename 的原子写入替代 append 操作 |
+| D-C08 | 首次安装目录不存在风险：`.omc/axiom/evolution/` 目录在全新系统中可能不存在，`fs.appendFileSync` 会因目录缺失抛出 ENOENT，PRD 未说明目录初始化逻辑 | MEDIUM | 在 T1/T2 归档操作前加入 `mkdirSync({ recursive: true })` 确保目录存在（参考 k-032 的 atomicWriteJson 隐含目录创建模式） |
+| D-C09 | T3 v2 YAML 部分解析失败的行为未定义：62 条中部分条目 YAML 格式错误时，是全量失败触发降级，还是宽松模式跳过错误条目？宽松模式会导致条目静默丢失 | MEDIUM | 明确定义：YAML 解析采用宽松模式（跳过错误条目 + 记录警告日志），不因单条错误触发全局降级；对跳过条目数量设上限（如超过 10% 则触发降级） |
+| D-C10 | T3 验收标准第一条自相矛盾："只返回 Title/Tags 含 typescript 的条目"（字段匹配）与"MiniSearch 全文匹配"（全文搜索）描述的是不同结果集 | MEDIUM | 修正验收标准：v2 描述改为"返回 title/tags/content 中含 typescript 的条目（MiniSearch 全文匹配，含模糊）" |
+| D-C11 | T1 阈值语义歧义："超过 10 条"在自然语言中通常为严格大于（`>`），但未在 PRD 中明确标注为 `count > 10`，实现者可能误用 `count >= 10` | LOW | 在 T1 第 1 条中直接写明条件表达式：`done 条目数 count > 10 时触发`，并在验收测试中使用 done = 11 作为边界测试用例 |
+| D-C12 | 流程图 4.1 节点 `J{会话结束检测}` 暗示主动轮询，与 SessionEnd hook 被动触发机制在概念上矛盾，可能导致实现者过度设计 | LOW | 将节点描述改为 `J{SessionEnd hook 触发}`，与 T4 第 1 条的描述一致 |
+
+---
+
+## 总结
+
+### 必须在进入实现前修正的阻断级问题（Blockers）
+
+1. **D-C01（HIGH）**：`auto_evolve_done` vs `auto_evolve` 标记名称不一致——T4 的跳过逻辑因此永久失效，实现后必然产生重复处理 Bug，须在 PRD 确认前修正字段名。
+
+2. **D-C02（HIGH）**：`stop_hook_active` 守卫的描述与实际实现机制不符，且在 SessionEnd hook 中从语义上就是无意义的——实现者若照 PRD 编写将产生无效守卫代码。
+
+3. **D-C05（HIGH）**：MiniSearch `--filter` 参数的 RegExp 注入风险——降级路径无法捕获该异常，项目已有防护模式（k-034）但 PRD 未引用，须在 T3 的实现规格中强制引用。
+
+4. **D-C04（HIGH）**：T4 ax-evolve 中途崩溃的数据一致性问题——缺少中间状态 `processing` 会导致知识库重复条目。
+
+### 建议结论
+
+**Conditional Pass（有条件通过）**
+
+- **严重阻碍（必须修正后才能进入实现）**：D-C01、D-C02、D-C04、D-C05
+- **建议修正（可并行进入实现但须跟踪）**：D-C03、D-C06、D-C07、D-C08、D-C09、D-C10
+- **低优先级（可在实现时顺手修正）**：D-C11、D-C12

package/docs/reviews/draft-prd-memory-evolution-optimize/review_domain.md

@@ -0,0 +1,237 @@
+# Domain Expert 评审报告
+
+**评审者**: axiom-domain-expert
+**评审时间**: 2026-03-02
+**评审对象**: PRD v0.2 - Axiom 记忆与进化系统 Token 使用效率优化
+
+---
+
+## 总体评分
+
+**7.5 / 10**
+
+理由：方案在 Token 效率优化方向上定位清晰，T1/T2/T4 的设计逻辑合理。但在以下三点存在明显领域风险：（1）MiniSearch 在 62 条记录规模下存在方案过度设计嫌疑；（2）时间衰减公式的参数选择缺乏对 Axiom 知识库实际访问模式的分析支撑；（3）T4 的 active_context.md 并发写入机制存在数据一致性隐患。核心逻辑框架可通过，但需要针对上述问题明确边界条件和降级策略后方可进入开发阶段。
+
+---
+
+## 评审意见
+
+### 1. 业务逻辑正确性
+
+#### 1.1 归档阈值（10 条 done）的合理性
+
+**评估：合理，但阈值偏低，边界语义不明确。**
+
+从实际数据出发：当前 learning_queue.md 有 LQ-001~LQ-030 共 30 条，全部为 done。按照 PRD 定义，阈值 10 条意味着系统在第 11 条 done 出现时立即触发归档，主文件保留最新 10 条 done + 所有 pending + 所有 in-progress。
+
+正面：阈值 10 条与"保留最近 10 条 done"语义对称，直观合理。对于活跃系统（每周新增 2-5 条 LQ 条目），主文件能稳定在约 60 行以内，与 PRD 目标吻合。
+
+问题一：阈值定义存在二义性。"done 条目数超过 10 条时触发"——是指主文件中 done 的总数超过 10，还是指本次 ax-evolve 处理完后累计 done 超过 10？当前描述两者均可解读。建议明确为："主文件中 done 状态的条目数 > 10 时触发"。
+
+问题二：归档后"保留最新的 10 条 done"的排序依据未定义。是按 `处理时间` 字段倒序？还是按 LQ 编号倒序？两者在大多数情况下等价，但若存在乱序处理场景（如 P0 插队），结果会不同。
+
+问题三：当前 learning_queue.md 已全部 done，zero pending。T4 的触发条件是"存在至少 1 条 pending"，因此自动触发不会激活。这是正确行为，但 T1 的归档逻辑在全空（无 pending）场景下仍应执行——PRD 对此未明确说明。归档与 ax-evolve 的耦合关系需要解耦：即使没有新的 pending 被处理，只要主文件中 done 数 > 10，也应支持手动触发归档。
+
+#### 1.2 滚动窗口（20 条反思）的业务依据
+
+**评估：窗口值偏大，业务依据不充分，但方向正确。**
+
+实际数据验证：当前 reflection_log.md 有 18 条反思条目（通过 grep 确认），总行数 681 行，平均每条约 38 行。按照 20 条滚动窗口，主文件上限约为 760 行——这反而比当前 681 行还多。对于行数已经超过 20 条窗口目标值的场景，PRD 的 "优化后主文件上限 ~400 行" 与 "保留最近 20 条" 存在内部矛盾。
+
+矛盾计算：若每条反思平均 35 行，20 条 = 700 行；PRD 却声称优化后主文件上限为 400 行（~41% 降幅）。两者不能同时成立，除非对每条反思的行数有更严格的格式约束（当前最长的反思超过 60 行）。
+
+业务依据缺失：PRD 未解释为什么是 20 条而非 10 条或 30 条。从认知科学角度，LLM Agent 的上下文窗口利用率通常遵循"最近 N 条即可"规律，具体 N 值应基于 Axiom 的实际会话频率和反思内容密度来决定。当前月活跃会话约 20-30 次（从 2026-02-26 至 2026-02-28 的 18 条可推算），20 条窗口约等于 3-4 天的历史，这在业务上是否足够未有依据支撑。
+
+建议：将窗口值从"固定 20 条"改为"固定 N 条或固定 K 行，取先达到者"，同时在 PRD 中补充选择 20 条的业务依据（例如：覆盖最近 3 次迭代周期的反思记录）。
+
+#### 1.3 时间衰减公式的适配性
+
+**评估：公式形式正确，但参数选择缺乏 Axiom 知识库访问模式的支撑。**
+
+公式：`finalScore = score × e^(-0.023 × ageInDays) × (1 + 0.2 × (3 - priority))`
+
+参数验证：
+- 衰减系数 0.023 对应 30 天半衰期（ln(2)/30 ≈ 0.0231），这是合理的数学关系。
+- 但 30 天半衰期的业务假设是：一条知识在 30 天后其相关性降至原始值的 50%。
+
+问题：这个假设对 Axiom 知识库不成立。观察实际数据：
+
+1. k-006 到 k-020 是 Flutter/Dart 相关知识，创建于 2026-02-09，距今（2026-03-02）已约 21 天。若使用 30 天半衰期，这些知识的分数已衰减至原来的约 61%。但这些是架构层面的稳定知识（Flutter Widget Lifecycle、Dart Null Safety 等），其实际相关性并未随时间减弱。
+
+2. k-001（Global Configuration Pattern，创建于 2026-02-08）在整个系统中被持续引用，但 30 天半衰期会使其分数衰减至约 55%，可能在搜索排名中被更近期的条目压制——即使更近期的条目在实际查询场景中并不更相关。
+
+3. 知识库中存在明显的"永久知识"（架构模式、安全规则）和"时效知识"（具体 bug 修复记录）两类。统一使用 30 天半衰期无法区分这两类知识。
+
+优先级调权：`(1 + 0.2 × (3 - priority))`——当 priority=1（P0/最高）时系数为 1.4，priority=3（P2）时为 1.0，priority=5（P4？）时为 0.6。但实际 knowledge_base.md 中没有 priority 字段，该字段是 T3 v2 引入 YAML front-matter 后才存在的。迁移前如何处理 priority 默认值未说明。
+
+---
+
+### 2. 数据完整性
+
+#### 2.1 "先写归档，再清理主文件"的原子性
+
+**评估：原子性保障方案可接受，但对文件系统层面的并发访问未考虑。**
+
+PRD 描述的可靠性保证："归档操作失败时，主文件内容不受影响（先写归档，再清理主文件）"，以及风险缓解："归档前先备份主文件到临时文件，操作完成后删除临时文件"。
+
+正面：两步写入策略（写归档 → 清理主文件）是正确的故障安全模式。即使第二步失败，数据会重复（归档中有，主文件中也有），而非丢失。重复比丢失好处理，且可通过幂等归档操作消除重复。
+
+问题一：归档操作的幂等性定义不清。PRD 要求"归档操作为幂等操作：重复执行不产生重复归档"，但未说明幂等性的判断依据是什么——是 LQ 条目的 ID（LQ-001），还是内容哈希？若按 ID 判断，重复执行时如何比对归档文件中已有的条目？这需要在每次归档前扫描归档文件全文，当归档文件增长到数百条时，这个扫描开销不可忽视。
+
+问题二：T4 的 active_context.md 写入存在 TOCTOU 风险（Time-Of-Check-Time-Of-Use）。T4 依赖读取 active_context.md 中的 `auto_evolve_done: true` 标记来判断是否跳过触发，但同一会话中若有多个并发操作（虽然 Claude Code 通常是顺序的），或者文件在读取后、判断前被其他进程修改，标记判断会失效。建议补充：SessionEnd hook 应使用文件锁或原子写入模式。
+
+问题三：T2 的一次性清理风险被 PRD 正确识别为 HIGH，缓解措施是"清理前先备份整个文件"。但 PRD 要求"清理后人工确认"——这打破了自动化闭环，将人工干预引入了一个声称是"自动化"的优化任务中。应明确：一次性清理是人工触发的单次操作，还是 ax-reflect 触发的自动操作？两者的备份策略不同。
+
+#### 2.2 knowledge_base.md 条目迁移至 YAML front-matter 的数据丢失风险
+
+**评估：中等风险，迁移脚本的具体行为未定义。**
+
+当前 knowledge_base.md 的结构是一个 Markdown 表格（Index 表），每行包含 ID、Title、Category、Confidence、Created、Status 六个字段。T3 v2 要求为每条 entry 添加 YAML front-matter（tags、category、created_at、last_accessed、priority）。
+
+风险点一：字段映射不完整。现有字段 `Confidence`（0.75-0.95）在新的 YAML front-matter 中没有对应字段（新字段是 priority），两者语义不同——Confidence 是知识可信度，Priority 是查询优先级。迁移脚本如何处理这个映射？丢弃 Confidence？将其转换为 Priority？
+
+风险点二：`last_accessed` 字段的初始值问题。迁移时所有条目的 `last_accessed` 均为空（历史上没有记录访问时间），时间衰减公式的 `ageInDays` 计算将使用 `created_at`，而非实际最后访问时间，导致长期未访问的知识（如 k-001）被低估。
+
+风险点三：knowledge_base.md 当前格式是中央索引表，每条 entry 只有元信息，没有"内容"字段（content）。T3 v2 的 MiniSearch 索引字段包含 `content`（权重 1x），但现有数据中 content 从何而来？是 Title 复用？还是需要人工补充每条知识的详细内容？这是一个重大的数据迁移工作量被 PRD 低估的地方。
+
+---
+
+### 3. 领域最佳实践符合度
+
+#### 3.1 MiniSearch BM25 方案对 62 条记录规模的适配性
+
+**评估：方案可行，但存在明显的过度工程化风险（Over-engineering）。**
+
+规模对比：
+- MiniSearch 设计目标是客户端全文搜索，适合数百至数万条记录（官方示例展示数千条电影索引）
+- 当前知识库：62 条记录，8KB，每条平均约 128 字节（仅元信息，无详细内容）
+
+在 62 条记录规模下，即使是简单的 `Array.filter()` + 字符串匹配也能在微秒级别完成，与 BM25 索引相比性能差异对用户完全无感知。引入 MiniSearch 的核心价值在于：
+1. 模糊匹配（fuzzy: 0.2）——对 62 条可用简单 Levenshtein 距离替代
+2. 字段权重（title 2x，tags 1.5x）——对 62 条可用带权重的手写 filter
+3. 前缀搜索（prefix: true）——对 62 条用 `startsWith` 即可
+
+MiniSearch 的实际价值体现在知识库增长到 500+ 条后。目前以"62 条 / 8KB"为依据引入 BM25 搜索引擎，属于为不确定的未来规模预留基础设施，而非解决当前实际问题。
+
+行业最佳实践参照：MemGPT/Letta 的记忆检索在初期同样使用简单的关键词过滤，BM25/向量检索是在记忆规模增长后才引入的。以此类比，Axiom 的正确路径应是：v1（grep/filter）→ 在知识库超过 200-300 条后评估引入 MiniSearch v2。
+
+然而，PRD 也明确说明了降级路径（MiniSearch 失败 → grep 兜底），这使得引入成本较低。若开发团队有信心将知识库快速扩展到 500+ 条，则提前引入是合理的技术预判。
+
+**结论：方案在技术上无误，但在当前规模下存在过度设计嫌疑，需要补充引入 MiniSearch 的预期知识库增长路径作为业务依据。**
+
+#### 3.2 SessionEnd hook 方案与 Claude Code hook 生命周期规范符合度
+
+**评估：设计决策正确，符合 Claude Code hook 规范，来自 claude-mem bug #987 的教训被正确应用。**
+
+PRD 正确区分了 Stop hook 与 SessionEnd hook 的语义差异：
+- Stop hook：会话可能继续（Claude 可能读取 stop hook 的 systemMessage 输出并继续响应）
+- SessionEnd hook：会话已终止，无法被重入
+
+这与 claude-mem 27.2K⭐ bug #987 的根本原因完全对应：Stop hook 返回含"next steps"的 systemMessage，Claude 将其解读为新任务指令，触发无限循环。SessionEnd hook 天然规避此问题。
+
+`stop_hook_active` 守卫的必要性分析：PRD 要求"hook 脚本入口检查 stop_hook_active 环境变量"。这是防御性设计，保护在错误配置下 Stop hook 触发此脚本时的安全边界，与 SessionEnd hook 选择并不矛盾。这是正确的双重防护。
+
+但存在一个潜在问题：PRD 中 T4 的触发标记是"完成后在 active_context.md 写入标记 auto_evolve: true"，但跳过条件却检查的是 `auto_evolve_done: true`（第 4 条）。两者字段名不一致（auto_evolve vs auto_evolve_done），这是一个字段名不一致的 bug，需要在实现前统一。
+
+**30 秒时间限制的合理性**：T4 声称最多处理 3 条、预估 10-15 秒。但每次 ax-evolve 需要执行 TypeScript/Skill 调用，实际执行时间取决于 LLM 响应时间（可能 5-20 秒/条）。3 条串行执行在网络延迟较高时可能超过 30 秒。建议 PRD 明确：若 30 秒超时，已处理的条目是否标记为 done，未处理的是否保留为 pending。
+
+#### 3.3 时间衰减算法的行业参照
+
+**评估：算法形式（指数衰减）是行业标准，但参数来源于 OpenClaw 的引用需要核实。**
+
+PRD 声称时间衰减评分来自 "OpenClaw 242K⭐ 模式"。指数衰减是检索系统中的经典算法（Elasticsearch 的 Function Score Query、Solr 的 RecencyBoostQuery 均有类似实现），但 OpenClaw（推测是 Claw 或 Open-WebUI 相关项目）的具体实现参数是否与此公式完全对应，PRD 未提供代码引用或链接。
+
+行业参照核实：
+- Elasticsearch Function Score + exp decay：`score × exp(-λ × max(0, |date - origin| - offset))`，形式相同，参数由用户自定义
+- MemGPT/Letta 的记忆权重：使用访问频率 + 创建时间的混合权重，未单独使用时间衰减
+- `claude-mem` 的记忆检索：依赖向量相似度，无时间衰减
+
+`(1 + 0.2 × (3 - priority))` 优先级调权因子的问题：priority 取值范围未定义。若 priority 为 1-5（P0-P4），则当 priority=5 时系数为 `1 + 0.2 × (3-5) = 0.6`，这使 P4 知识得分乘以 0.6，可能导致低优先级知识即使时间很近也被严重压制。这是否是预期行为？
+
+---
+
+### 4. 边界条件与异常
+
+#### 4.1 learning_queue.md 全空（无 pending）时 T4 的触发逻辑
+
+**评估：T4 的跳过逻辑正确，但文件全空场景下 T1 的行为未定义。**
+
+当前状态：learning_queue.md 全部 30 条均为 done，零 pending。
+
+T4 触发条件分析：PRD 第 3 条明确"触发条件：learning_queue.md 中存在至少 1 条 pending 条目时才触发"。当前全 done 场景下，T4 正确跳过，不触发自动 ax-evolve。逻辑无误。
+
+但引发了一个 T1 的问题：当 learning_queue.md 有 30 条 done、0 条 pending 时，T1 应该触发归档（done 数量 30 > 阈值 10）。但 T1 的触发时机是"ax-evolve 处理完一批条目后（状态变为 done 时）自动检查并执行"——如果没有新的 pending 被处理（T4 跳过），T1 就永远不会被触发。这意味着在当前全 done 状态下，learning_queue.md 不会自动归档，需要人工触发。PRD 未对此场景提供解决路径。
+
+建议：T1 应支持独立的触发方式（如 `ax-knowledge --archive-queue`），不强依赖 ax-evolve 执行。
+
+#### 4.2 reflection_log.md 空条目的判断标准
+
+**评估：标准定义不够精确，可能导致误清理。**
+
+PRD 对空条目的定义："内容仅有标题行或空白行的反思块"。
+
+问题一：判断边界不清晰。什么是"仅有标题行"？以下哪些属于空条目？
+- 案例 A：`## 反思 - 2026-02-11 Reflection (Session: Codex Workflow Optimization)` + 完整内容（非空，已确认）
+- 案例 B：一个有标题、有 `### 📊 本次会话统计` 但内容全为 `-` 的条目
+- 案例 C：一个有标题但正文为 `<!-- auto-generated -->` 注释的条目
+
+实际数据观察：reflection_log.md 在行 367-390 存在一个无 `---` 分隔符的反思条目（2026-02-11 Codex Workflow），格式与其他条目有差异（英文标题，格式略有不同）。清理逻辑若按分隔符 `---` 划分块，可能将此条目误判或错误截断。
+
+问题二：历史上确实存在 "auto-session-" 类型的空模板条目（见反思 2026-02-27 04:20 中的记录：300 行中有 30+ 个空模板）。这些条目已通过 LQ-013 的修复被清理（fix(learner): skip empty session reflections），且该修复已合并。PRD 的 T2 一次性清理是否还有必要？需要确认当前 reflection_log.md 中是否仍存在待清理的空条目（从当前数据看 18 条均有实质内容）。
+
+建议：补充"空条目"的精确判断规则，例如：若一个由 `## 反思` 开始的块中，`### ✅ 做得好的` / `### ⚠️ 待改进` / `### 💡 学到了什么` 三个核心小节均无有效文本内容，则判定为空条目。
+
+#### 4.3 MiniSearch 索引构建与 knowledge_base.md 格式的兼容性
+
+**评估：PRD 忽略了一个关键的结构性问题。**
+
+当前 knowledge_base.md 是一个**索引表**，不包含知识条目的详细内容——每条知识的实体内容存储在何处？PRD 未说明。MiniSearch 的 `content` 字段（权重 1x）需要什么数据来填充？
+
+若 content 字段为空，MiniSearch 的 BM25 评分退化为仅基于 title 和 tags 的关键词匹配，与基础 v1 方案（grep title/tags）的实际效果差异不大，引入 MiniSearch 的价值大打折扣。
+
+#### 4.4 Token 降幅估算的可信度
+
+**评估：82% 和 85% 的降幅数字过于乐观，存在误导决策的风险。**
+
+- learning_queue.md：PRD 声称优化后约 60 行，降幅 82%（MemGPT two-tier 模式）。当前 327 行中包含 30 条 done 全量记录。若归档后保留 10 条 done + 头部，约为 20行头部 + 10条×10行 = 120行，而非 60 行。60 行仅在 pending 为 0 时成立。
+
+- knowledge_base.md：PRD 声称 85% 降幅（qmd 96% 参照）。"平均返回 10 条" 的假设基于典型查询场景，但 `ax-knowledge`（无参数）仍全量返回 62 条——这是最常见的调用方式之一。全量调用场景下降幅为 0%。
+
+---
+
+## 差异点（Diff Points）
+
+| ID | 描述 | 严重程度 | 建议 |
+|----|------|---------|------|
+| D-01 | T4 触发标记字段名不一致：写入 `auto_evolve: true`，读取判断用 `auto_evolve_done: true` | HIGH | 统一字段名，在 PRD 中明确定义字段名为 `auto_evolve_done: true` |
+| D-02 | T1 归档无法在"全 done / 零 pending"状态下自动触发，导致当前状态下归档永远不执行 | HIGH | 为 T1 添加独立触发方式（手动命令 `ax-knowledge --archive-queue`），解除与 ax-evolve 的强耦合 |
+| D-03 | Token 降幅估算（82%/85%）基于乐观假设，实际效果取决于 pending 数量和调用参数，全量调用场景下降幅为 0% | MEDIUM | 将降幅估算改为"最优场景/典型场景/最差场景"三值区间，避免单一乐观值误导 |
+| D-04 | 知识库条目迁移时 `Confidence` 字段与新 `priority` 字段语义不同，迁移映射规则未定义 | MEDIUM | 在 T3 v2 迁移脚本设计中明确：Confidence 保留为独立字段，priority 需人工或脚本补充 |
+| D-05 | MiniSearch `content` 字段的数据来源未定义：knowledge_base.md 是索引表，无 entry 详细内容 | MEDIUM | 明确 content 字段的填充策略：若为 Title 复用则说明；若需知识实体文件则需大量迁移工作 |
+| D-06 | 反思空条目的判断标准不精确，存在误清理 2026-02-11 Codex Workflow 反思（格式异常条目）的风险 | MEDIUM | 补充精确的空条目判断规则，基于核心小节内容而非仅看标题/空白行 |
+| D-07 | 时间衰减公式对"永久知识"（架构模式、安全规则）产生不合理的分数压制（21天后衰减至61%） | MEDIUM | 引入 knowledge_type 字段区分 evergreen（不衰减）和 temporal（衰减）两类知识；或将半衰期从30天延长至180天 |
+| D-08 | T2 的一次性清理是否仍有必要存疑：LQ-013 已修复空条目生成根源，当前 18 条反思均有实质内容 | LOW | 评估当前 reflection_log.md 中空条目实际数量，若为零则 T2 的一次性清理步骤可简化为仅建立滚动窗口机制 |
+| D-09 | priority 字段取值范围未定义，`(3 - priority)` 调权因子在 priority > 3 时产生负系数，知识总分可能低于基础分 | LOW | 明确 priority 取值范围（如 1-5），并限制调权因子下限（max(0, 1 + 0.2 × (3 - priority))） |
+| D-10 | "保留最新的 10 条 done"排序依据未定义，乱序处理场景下（P0 插队）结果不确定 | LOW | 明确排序字段为 `处理时间` 倒序，缺失处理时间时使用 `添加时间` 作为兜底排序依据 |
+
+---
+
+## 总结
+
+PRD v0.2 在 Token 效率优化的整体方向上设计清晰，T1/T2/T4 的核心逻辑符合 LLM Agent 记忆管理的行业实践（参照 MemGPT 两层记忆模型、claude-mem 的 SessionEnd hook 教训）。以下是关键结论：
+
+**可以通过的部分：**
+- T1 归档机制：逻辑合理，双步写入保障数据安全，幂等性概念正确（需细化判断依据）
+- T4 SessionEnd hook 选择：技术决策正确，Stop hook 风险被正确识别并规避
+- T3 v1 基础方案（grep 过滤）：轻量、无风险、立即可实现
+
+**需要修正后通过的部分：**
+- D-01（HIGH）：T4 字段名不一致必须在实现前修正，否则跳过逻辑永远无法生效
+- D-02（HIGH）：T1 触发机制需解耦，确保全 done 状态下可手动归档
+- T2 滚动窗口：窗口值（20条）与 Token 降幅目标（400行）的内部矛盾需在设计文档中解决
+- 时间衰减公式：需补充知识类型区分（evergreen vs temporal）或延长半衰期
+
+**建议暂缓的部分：**
+- T3 v2 MiniSearch：在知识库未超过 200 条前，v1 grep 方案完全足够，引入 MiniSearch 的开发成本高于当前收益；建议将 v2 列入 v2 延期列表，与"知识库 200+ 条"绑定作为触发条件
+
+**整体建议**：T1+T2+T4 可以进入开发阶段（需先修正 D-01、D-02）；T3 v1 可同步开发；T3 v2 建议延期至知识库规模增长后重新评估。