@liangjie559567/ultrapower 5.5.2 → 5.5.3

package/docs/reviews/draft-prd-ultrapower-pain-fix/review_tech.md

@@ -1,219 +0,0 @@
-# Tech Feasibility Review: ultrapower 全面痛点修复计划
-
-> 评审基于真实代码读取，所有结论均有文件行号佐证。
-> 评审日期：2026-02-26
-
----
-
-## 整体评分：6 / 10
-
-**核心判断**：计划整体方向正确，P0 安全问题识别准确，但存在三处系统性低估：
-1. 分批粒度严重不足（"2个任务覆盖8个修复"的估计在实证面前站不住脚）
-2. P0-6/P0-7 的破坏性变更风险被忽视
-3. P1-9（delegation-enforcer 集成）被极度低估
-
----
-
-## 1. Architecture Impact（架构影响）
-
-| 维度 | 状态 | 备注 |
-|------|------|------|
-| Schema Changes | No | 无 DB Schema，状态文件格式不变 |
-| API Changes | Partial | P0-7 改变子进程通信协议，P1-9 改变 hook 路由 |
-| Breaking Changes | Yes | P0-6/P0-7 对 Windows ESM 和子进程通信有破坏性风险 |
-
----
-
-## 2. Risk Assessment（风险评估）
-
-- Complexity Score: **7 / 10**
-- POC Required: **Yes**（P0-6、P0-7、P1-9 三项各需独立 POC）
-
----
-
-## 3. 肯定点
-
-**P0-1（assertValidMode 缺失）**
-实证：`src/lib/validateMode.ts` 已有完善的 `assertValidMode()` 实现（行 63-75），`src/features/state-manager/index.ts` 的 `getStatePath()`（行 82-86）直接拼接 `name` 参数而未校验。修复方向正确，改动局部，工作量真实，无破坏性。
-
-**P0-2（execSync 字符串拼接）**
-实证：`src/features/auto-update.ts` 行 611 存在 `execSync('which omc 2>/dev/null || where omc 2>NUL', ...)` 的 Shell 字符串拼接，属于真实命令注入面。改用 `execFileSync('which', ['omc'])` 方案正确，改动范围可控。
-
-**P0-4（gemini --yolo 硬编码）**
-实证：`src/mcp/gemini-core.ts` 行 89 确认 `args = ['-p=.', '--yolo']` 硬编码，`src/team/mcp-team-bridge.ts` 行 347 亦有同样问题。改为环境变量 `OMC_GEMINI_YOLO` 方案合理，不影响调用协议。
-
-**P2-1（superpowers: 命名空间）**
-实证：全代码库对 `superpowers:` 的 grep 结果为 0 条，说明该命名空间残留已不存在或极少。批量替换风险远低于 PRD 描述，可能已由之前版本清理完毕。
-
----
-
-## 4. 差异点/问题
-
-### D-TL-01: P0-1 修复范围被低估——存在两个独立的 getStatePath 实现
-
-- 严重度: HIGH
-- 描述: PRD 描述"在 getStatePath() 入口添加 assertValidMode()"，但实际代码中存在**两个完全独立**的 `getStatePath` 函数：
-  - `src/features/state-manager/index.ts`（行 82-86）：接受 `name: string` + `location: StateLocation`，通过 `StateLocation` 枚举约束，`name` 参数无白名单校验。
-  - `src/tools/state-tools.ts`（行 50）：接受 `mode: StateToolMode`，通过自定义类型约束，需独立评估。
-  两处都需要修复，但修复方式不同——前者需要 `assertValidMode`，后者需要验证其 `StateToolMode` 类型是否已覆盖所有路径。PRD 仅提及一处，实际工作量加倍。
-- 建议: 修复前须对 `getStatePath` 的所有调用点做全量 grep 扫描，确认两处均已处理。
-
----
-
-### D-TL-02: P0-3（release-steps.mjs）问题描述与实际代码不符
-
-- 严重度: MEDIUM
-- 描述: PRD 称"release-steps.mjs 存在 `git push origin main`"，但读取实际文件（行 1-60）后，该文件**不包含** `git push origin main`。它包含的是 `npm publish`、`gh release create`、`run('tsc --noEmit')` 等操作，均通过封装函数 `run()` 调用 execSync，且有 dryRun 保护。若原始问题已不存在，此修复是无效工作；若问题存在于未读取的后半段，PRD 未精确定位。
-- 建议: 重新精确定位问题行号再排入修复计划。若已不存在，从 P0 清单移除，避免浪费 Batch 1 预算。
-
----
-
-### D-TL-03: P0-6（Windows ESM）修复方案存在破坏性变更风险
-
-- 严重度: HIGH
-- 描述: PRD 提出将模块路径改为 `pathToFileURL(modulePath).href`。查看 `src/hooks/bridge.ts` 末尾（行 1252）：`if (import.meta.url === pathToFileURL(process.argv[1]).href)` —— 项目**已经使用** `pathToFileURL`，说明部分路径已修复，但并非全量。真正的风险在于：动态 `import(modulePath)` 在 Windows 上若 `modulePath` 是绝对 Win32 路径（如 `C:\Users\...`），Node.js ESM loader 会拒绝，必须转为 file URL。但改动后，所有**依赖原始路径字符串做字符串比对**的逻辑（如 `existsSync`、`readFileSync`）必须保留原始路径，只有 `import()` 动态调用才用 URL 形式。混用容易引入 URL/path 类型混乱 bug。
-- 建议: 需要一个专项 POC，在真实 Windows 环境下验证改动不破坏懒加载模块链（bridge.ts 中大量 `await import('./ralph/index.js')` 等）。不能凭推理假设安全。
-
----
-
-### D-TL-04: P0-7（JSON.stringify 注入）修复方案对 daemon 通信机制改变被低估
-
-- 严重度: HIGH
-- 描述: PRD 提出"通过 stdin/环境变量传递 config 而非 JSON.stringify 字符串拼接"。`src/mcp/codex-core.ts`（行 292-293）已经使用 stdin 传递 prompt（`child.stdin.write(prompt); child.stdin.end()`），说明 prompt 通道已安全。但若 config 对象从 JSON.stringify 改为环境变量，会引入：
-  1. 环境变量大小限制（Windows 单变量上限约 32767 字节，Linux 通常 128KB ARG_MAX 总量）——若 config 较大，会静默截断。
-  2. 子进程环境变量继承链污染——敏感 config 字段暴露在 `/proc/{pid}/environ`（Linux）或任务管理器（Windows）中，安全性反而降低。
-  3. 若改为 stdin，则与现有 prompt stdin 管道冲突，需要协议设计（如 JSON framing）。
-  PRD 未分析任何一条，就定性为"修复方案"，风险评估缺失。
-- 建议: 明确区分哪个调用点的哪种数据存在注入风险，分别选择最小侵入方案。不得笼统套用"改为 stdin"方案。
-
----
-
-### D-TL-05: Batch 1 "2个任务覆盖8个修复"严重低估工作量
-
-- 严重度: HIGH
-- 描述: PRD 的分批声称"Batch 1：8个修复（P0-1~7 + P1-6/7），估计2个任务"。按照实际代码复杂度分解：
-  - P0-1：涉及 2 个独立 getStatePath 实现 + 全量调用点审查（见 D-TL-01）
-  - P0-2：execSync 实例分散在 auto-update.ts、teleport.ts、providers/index.ts 等多个文件
-  - P0-3：定位问题存疑（见 D-TL-02）
-  - P0-4：gemini-core.ts + mcp-team-bridge.ts 两处硬编码 + 环境变量文档
-  - P0-5：需要找到角色列表加载逻辑并重构错误处理
-  - P0-6：Windows ESM 全量扫描 + POC 验证（见 D-TL-03）
-  - P0-7：协议设计决策 + 实现（见 D-TL-04）
-  - P1-6/7：计时器泄漏修复，需要找到所有 setTimeout 调用点
-  保守估计：Batch 1 实际工作量为 **6-8 个独立任务**，而非 2 个。低估超过 3 倍会直接导致执行阶段范围蔓延和计划失控。
-- 建议: 按实际修复项 1:1 拆分任务，不允许将 POC 工作与实现工作合并计入同一任务。
-
----
-
-### D-TL-06: P1-9（delegation-enforcer 集成到 bridge.ts processHook）复杂度被极度低估
-
-- 严重度: HIGH
-- 描述: PRD 描述为"bridge.ts processHook 集成 delegation-enforcer"，表述像一行调用。但阅读实际代码后：
-  1. `src/hooks/bridge.ts` 的 `processPreToolUse()`（行 765-895）已经调用 `processOrchestratorPreTool()`（行 769-783），后者来自 `./omc-orchestrator/index.ts`，已经是 delegation 检查的入口。
-  2. `src/features/delegation-enforcer.ts` 的 `enforceModel()` 是独立的模型注入逻辑，与 orchestrator 的 delegation 检查是**两个不同维度**的功能。
-  3. 若目的是在 `processHook` 中集成 `delegation-enforcer`，需要明确：在哪个 hook type 注入、修改哪个 toolInput 字段、是否影响现有 `processOrchestratorPreTool` 的 `continue: false` 路径、如何处理 `modifiedInput` 返回给 Claude Code 的协议。
-  4. `src/__tests__/delegation-enforcer-integration.test.ts` 已存在集成测试，说明之前有过集成尝试，需要理解其当前状态。
-  真实工作量：需要 1 个完整的设计文档 + 至少 3 个任务（设计、实现、测试）。
-- 建议: 在 Batch 2 中将 P1-9 单独拆分为子 PRD，明确接口定义和集成协议，不允许以"一行调用"级别的估计进入执行。
-
----
-
-### D-TL-07: P2 测试新增"各≥10 cases"目标与项目测试现状不匹配
-
-- 严重度: MEDIUM
-- 描述: vitest.config.ts 显示测试超时 30s、使用 forks pool，项目已有 210 个测试文件（来自 find 统计）。PRD 要求新增 3 个测试文件各≥10 cases（atomic-write、version、hooks），但：
-  1. `src/__tests__/atomic-write` 和 `src/__tests__/validateMode.test.ts` 可能已存在，需要先确认现状。
-  2. `hooks` 测试文件已有 `src/hooks/__tests__/bridge-routing.test.ts`，新增文件需要明确与已有测试的边界划分。
-  3. 10 cases 的数量目标很低，但也意味着测试覆盖意图不够清晰——缺少具体的测试场景描述（正常路径、边界情况、错误路径各几个），执行者将难以判断"完成"。
-- 建议: 对每个测试文件提供具体场景列表（不需要代码，需要场景名称），而非仅声明数量目标。
-
----
-
-### D-TL-08: P2 命名空间替换"superpowers: → ultrapower:"风险被高估，但验证方案缺失
-
-- 严重度: LOW
-- 描述: 实际 grep 结果显示全代码库（src + scripts，排除 node_modules/dist）中 `superpowers:` 出现 **0 次**，说明该替换可能已完成或从未存在。PRD 将其列为 P2 修复项消耗评审资源，但若替换已完成，此项为无效工作。
-  另一方面，若问题存在于 dist/、templates/ 或文档文件（.md、.json）中，PRD 未说明替换范围。
-- 建议: 在计划开始前做一次全量扫描（包含 dist、docs、templates），若结果为 0 则从计划移除，若有遗留则精确定位文件列表后再评估工作量。
-
----
-
-### D-TL-09: 验收标准"Windows 真实环境验证"缺乏 CI 自动化路径
-
-- 严重度: MEDIUM
-- 描述: PRD 将"Windows 真实验证"列为验收标准之一，但：
-  1. 当前 vitest.config.ts 未配置任何平台矩阵，测试默认在当前平台运行。
-  2. GitHub Actions 上添加 `windows-latest` runner 需要修改 CI 配置，且 Windows 下 Node.js ESM + path 处理与 Linux 行为差异较大，需要独立的 test case。
-  3. P0-6 的 Windows ESM fix 若无 Windows CI 覆盖，则验收标准在实践中无法自动化验证，退化为人工验证——这不可重复、不可持续。
-- 建议: 将"Windows CI 矩阵配置"作为独立任务加入 Batch 3，在 P0-6 修复合并前完成，使验收标准可在 CI 中自动化执行。
-
----
-
-### D-TL-10: 整体修复计划缺少依赖关系图，执行顺序存在隐性风险
-
-- 严重度: MEDIUM
-- 描述: 各修复项之间存在未声明的依赖关系：
-  - P0-1（assertValidMode 调用）依赖 `validateMode.ts` 本身正确——若 VALID_MODES 白名单有遗漏，修复引入新 bug。当前白名单为 8 个模式，但 `src/tools/state-tools.ts` 中的 `StateToolMode` 可能包含额外模式（如 ralplan），需要对齐。
-  - P0-6（Windows ESM）与 P0-7（stdin 传递）若同时修改子进程通信路径，合并冲突概率极高，必须串行而非并行。
-  - P1-9（delegation-enforcer）依赖 bridge.ts 的 `processPreToolUse` 路径，而 P0-2 的 execSync 修复也涉及同一文件区域，若并行执行会产生冲突。
-  - P2 测试文件依赖 P0/P1 修复完成后的稳定接口，不应在修复期间同步开发。
-- 建议: 在执行前绘制简单的依赖 DAG（有向无环图），将存在冲突的修复项明确标记为串行。
-
----
-
-## 5. Implementation Plan（大致实现计划）
-
-**建议重构后的分批方案：**
-
-**Batch 1（P0 安全，串行）：10-12 个任务**
-- 1a. 全量扫描 getStatePath 调用点，确认两处实现（state-manager + state-tools）均需修复
-- 1b. 修复 state-manager/index.ts 中 getStatePath + readState 路径
-- 1c. 修复 state-tools.ts 中独立 getStatePath（若需要）
-- 1d. execSync 字符串拼接全量替换（auto-update.ts + 其他文件）
-- 1e. P0-3 重新定位问题，若存在则修复
-- 1f. gemini-core.ts + mcp-team-bridge.ts --yolo 环境变量化
-- 1g. P0-5 角色列表静默失败修复
-- 1h. **POC**：Windows ESM import URL 修复验证
-- 1i. P0-6 全量实施（依赖 1h POC 通过）
-- 1j. **POC**：P0-7 子进程 config 传递方案（stdin framing vs 环境变量上限评估）
-- 1k. P0-7 实施（依赖 1j POC 通过）
-- 1l. P1-6/7 计时器泄漏修复
-
-**Batch 2（P1 稳定性，部分并行）：8 个任务**
-- 2a-e. P1-1~5（platform 分支、path.relative、path.resolve、tmpdir、executionCounters）
-- 2f. P1-8（返回 false/抛出未实现错误）
-- 2g. P1-10（等待时间上限）
-- 2h. P1-11（先 kill 再写状态）
-
-**Batch 3（P1-9 delegation-enforcer，需独立子 PRD）：3 个任务**
-- 3a. 设计文档：明确集成接口、hook type 范围、modifiedInput 协议
-- 3b. 实现
-- 3c. 集成测试补充
-
-**Batch 4（P2 + Windows CI）：5 个任务**
-- 4a. superpowers: 全量扫描确认（若 0 结果则关闭）
-- 4b. 测试文件新增（有具体场景列表）
-- 4c. Windows CI 矩阵配置（GitHub Actions）
-- 4d. 文档版本号同步
-- 4e. 回归验证（4698+ 测试零回归）
-
----
-
-## 6. Conclusion（结论）
-
-- **评审决定：POC Required（需原型验证后方可执行）**
-- **理由：P0-6、P0-7、P1-9 三项存在未验证的技术假设，若直接进入 Batch 1 全量实施，有较高概率在 Windows 平台或子进程通信层引入回归。**
-
-**必须在 Batch 1 正式开始前完成的 POC：**
-1. Windows ESM import URL 修复（P0-6）——在真实 Windows 环境验证动态 import 路径
-2. 子进程 config 传递方案选型（P0-7）——验证 stdin framing 与现有 prompt stdin 不冲突
-
-**估计工作量：**
-- 原 PRD 估计：约 8 个任务
-- 修订后估计：**约 28-34 个任务**（含 POC、Windows CI、P1-9 子 PRD）
-- 日历时间：依团队规模，预计 **3-5 周**（非 2 批次即可完成）
-
-**不可协商的前提条件：**
-- P0-6 和 P0-7 必须有 Windows 真实环境 POC 通过后才能合并
-- P1-9 必须有设计文档经评审后才能进入实现
-- 所有 Batch 之间必须通过完整测试套件（4698+ cases zero regression）才能进入下一 Batch

package/docs/reviews/draft_prd_pain_points/review_domain.md

@@ -1,215 +0,0 @@
-# Domain Expert Review: ultrapower 项目全面痛点修复计划
-
-**评审时间：** 2026-03-01
-**评审人角色：** Domain Expert（业务逻辑与行业标准专家）
-**评审对象：** Draft PRD — ultrapower 项目全面痛点修复计划
-**代码基线版本：** v5.4.8
-
----
-
-## 整体评分：7 / 10
-
-PRD 体现了扎实的代码扫描能力，问题发现覆盖面广（118 项）。但部分安全严重度评级存在偏差：P0-3 被高估、P0-5 被低估；P1-9 的业务价值分析缺失导致优先级判断失准；测试补全（P2-8~10）的优先级相对行业标准偏低。总体修复逻辑符合现实，行业标准对齐尚可，但仍有若干领域缺陷需要修正。
-
----
-
-## 肯定点
-
-1. **安全分层清晰。** P0 到 P3 的四级分层与 OWASP/CVSS 的严重度分级理念一致，有利于工程团队按优先级交付。
-
-2. **P0-1 路径遍历问题定位准确。** `getStatePath()` 在 state-manager 中接受外部传入的 `name` 参数并直接拼接路径，经代码核查确认未调用 `assertValidMode()`，漏洞属实。该修复符合项目自身 `docs/standards/runtime-protection.md` 的 P0 安全规则。
-
-3. **P0-7 daemon.ts 动态代码注入的发现有价值。** 将 `JSON.stringify(cfg)` 注入 Node.js `-e` 脚本字符串，当 `config` 中含有反引号、特殊字符或换行时确实可破坏语法，属于真实的代码注入向量，定级 P0 合理。
-
-4. **P1-11 kill/write 顺序颠倒是典型的 TOCTOU 问题。** 先写状态后 kill 进程，若 kill 失败状态已损坏，无法自愈。修复方向（先 kill 成功再写状态）符合事务性操作的行业最佳实践。
-
-5. **P1 Windows 兼容性问题识别系统化。** 覆盖了 shell 命令、路径分隔符、`/tmp` 依赖等常见跨平台陷阱，适配策略（`process.platform` 分支、`os.tmpdir()`、`path.relative()`）均为 Node.js 生态标准做法。
-
----
-
-## 差异点 / 问题
-
----
-
-### D-DE-01：P0-3（git push origin main）严重度高估，应降级为 P2
-
-- **严重度：** MEDIUM（评审意见，当前 PRD 定级 P0）
-- **描述：**
-
-  P0-3 的理由是"违反 CLAUDE.md 分支策略规范（默认分支为 dev，禁止直接推送 main）"。但从业务逻辑视角评估：
-
-  1. **触发路径受控。** `git push origin main` 位于 `scripts/release-steps.mjs` 的 `syncMarketplace()` 函数中。该脚本是 CI/GitHub Actions 的发布管道入口，并非任意开发者日常调用路径。攻击面极度受限。
-  2. **运行时已有 dry-run 保护。** 函数签名包含 `dryRun = false` 参数，所有调用点均支持 `--dry-run` 旁路，不会意外执行。
-  3. **与 P0-7（代码注入）的危害不可同日而语。** P0-7 可被任意具有 config 写权限的路径触发代码执行；P0-3 至多造成分支规范违反，不涉及权限提升、数据泄露或服务中断。
-
-  按 CVSS v3.1 维度：影响范围（Scope）=局部，保密性/完整性影响=低，利用难度=高（需 CI 触发）。综合评分约 3.1，应归 P2（流程规范问题）而非 P0（安全漏洞）。
-
-- **建议：** 将 P0-3 移至 P2 分组，标注"分支策略合规修复"。修复方式：删除 `git push origin main` 改走 PR 流程，或改为 `git push origin HEAD:dev`，并在 CI YAML 中加 branch protection check。
-
----
-
-### D-DE-02：P0-4（--yolo 标志）风险评估需补充 Gemini CLI 行为语义
-
-- **严重度：** MEDIUM
-- **描述：**
-
-  PRD 将 `--yolo` 定级 P0，理由是"禁用所有安全确认，生产环境安全风险"。但需补充领域背景：
-
-  1. **`--yolo` 是 Gemini CLI 的非交互模式标志。** 其作用是跳过用户确认提示（类似 `--yes` / `--non-interactive`），使 CLI 在自动化管道中可无人值守运行，属于工具设计的标准用法。
-  2. **在 MCP 服务器上下文中，非交互模式是必要的。** ultrapower 将 Gemini CLI 作为子进程调用，进程标准输入不连接终端，若不传 `--yolo`，CLI 遇到确认提示会永久阻塞。
-  3. **真实风险在于"无法关闭"而非"标志本身"。** 若某些 Gemini CLI 版本的 `--yolo` 额外禁用了内容过滤或沙箱，硬编码确实不可接受。
-
-  因此风险核心是"缺乏可配置性以应对未来 CLI 行为变更"，而非当前的代码注入或权限提升。严重度介于 P0 与 P1 之间。
-
-- **建议：** 维持现有定级（P0 可接受），但修复描述应精确化：新增 `OMC_GEMINI_YOLO` 环境变量控制，并在文档中明确 `--yolo` 的语义边界。如 Gemini CLI 未来版本收紧此标志含义，需重新评估。
-
----
-
-### D-DE-03：P0-5（prompt-injection 静默失败）严重度被低估
-
-- **严重度：** HIGH（当前 PRD 列为 P0 但描述轻描淡写，修复方案不足）
-- **描述：**
-
-  经代码核查（`src/mcp/prompt-injection.ts:93-97`），失败路径的现状是：
-
-  ```typescript
-  } catch (err) {
-    console.error('[prompt-injection] CRITICAL: Could not scan agents/ directory...');
-    _cachedRoles = [];
-  }
-  ```
-
-  实际代码已有 `console.error` 日志输出（非"静默"），但 PRD 描述为"无任何错误日志"——此描述与源码不符，存在事实偏差。
-
-  真正的业务风险是：`_cachedRoles = []` 导致 `VALID_AGENT_ROLES` 为空数组，下游 `resolveSystemPrompt` 中的角色验证全部失败，所有 agent_role 参数被拒绝，MCP 工具退化为无角色模式——这是功能性降级，不是安全漏洞。
-
-- **建议：**
-  1. 修正 PRD 中的事实描述（代码已有错误日志）。
-  2. 补充 fallback 硬编码列表（真实业务需求）。
-  3. 考虑从 P0 降级为 P1（功能稳定性问题，无安全向量）。
-
----
-
-### D-DE-04：P0-6（daemon.ts Windows ESM import）已有部分缓解措施，评估需更新
-
-- **严重度：** MEDIUM
-- **描述：**
-
-  经代码核查（`daemon.ts:424`），现有代码：
-
-  ```typescript
-  const modulePath = __filename.replace(/\.ts$/, '.js');
-  const daemonScript = `import('${modulePath}')...`;
-  ```
-
-  PRD 描述"Windows 路径 `C:\Users\...` 插入 import() 字符串导致 ESM import 失败"属实。但补充背景：
-
-  1. **该代码路径在实际 Windows 生产环境中是否被激活？** `__filename` 来自 `fileURLToPath(import.meta.url)`，在 esbuild 打包后的 CJS bundle 中，`import.meta.url` 被替换为 `{}` 导致 ESM 路径不可用——实际上打包后的 daemon 可能走不同的代码路径。
-  2. **`createMinimalDaemonEnv()` 的白名单设计体现了良好的安全意识**，PRD 未予肯定，建议保留。
-
-- **建议：** 修复建议（`pathToFileURL(modulePath).href`）正确。但需在验收标准中补充"在打包产物上的 Windows E2E 测试"，而非仅在源码层验证。
-
----
-
-### D-DE-05：P1-9（delegation-enforcer 未集成）业务价值评估缺失
-
-- **严重度：** HIGH（业务影响大，PRD 分析不足）
-- **描述：**
-
-  PRD 将 P1-9 仅描述为"功能死区——模块存在但未被调用"，缺乏业务影响量化分析。经代码阅读，`delegation-enforcer` 的核心功能是：
-
-  **当 Task/Agent 调用未显式指定 `model` 参数时，自动从 agent definitions 注入默认模型（haiku/sonnet/opus）。**
-
-  其业务影响链：
-
-  1. 若 enforcer 未集成，所有不带 `model` 参数的 Task 调用将使用 Claude Code 默认模型（通常为当前会话模型），而非 agent catalog 中定义的轻量模型（如 `explore` 应为 haiku）。
-  2. 直接后果：haiku 级任务被 sonnet/opus 执行，**每次 agent 调用成本放大 3-10x**，在高并行场景（ultrawork、team 模式）下成本损失尤为显著。
-  3. 二级后果：CLAUDE.md 中的 model_routing 规范（haiku/sonnet/opus 分级）形同虚设，用户基于分级的成本预期完全失效。
-
-  这是一个持续发生的业务损耗问题，而非一次性功能缺失。在 49 个 agents、并行编排场景下，其成本影响可能远超其他 P1 问题。
-
-- **建议：**
-  1. 将 P1-9 提升为 P0.5 或 P1 中最高优先级。
-  2. 补充验收标准：集成后需验证 `Task({subagent_type: "ultrapower:explore"})` 在无 model 参数时实际使用 haiku，通过 MCP 日志或 mock 验证，而非仅靠单元测试。
-  3. 修复方案需注意：`bridge.ts` 中的 `processPreToolUse()`（第 765 行）目前已调用 `processOrchestratorPreTool()`，但后者未调用 `delegation-enforcer`。集成点清晰，实现难度不高。
-
----
-
-### D-DE-06：P2 测试补全优先级偏低，不符合行业最佳实践
-
-- **严重度：** MEDIUM
-- **描述：**
-
-  PRD 将 `atomic-write`、`version`、`hooks` 三个核心 lib 的测试覆盖补全列为 P2。但从行业标准视角：
-
-  1. **`atomic-write` 无测试是 P1 级风险，而非 P2。** 原子写入是 state-manager 的最底层安全保障，该函数无测试意味着 P0-1 修复后的路径遍历防护无法被回归测试覆盖，后续修改时随时可能引入回归。测试缺失本身是安全修复的质量保障缺口。
-  2. **行业标准（Jest、Vitest 生态惯例）：** 安全关键路径（路径遍历防护、原子写入）的单元测试覆盖是代码合并的必要条件（pre-merge gate），而非发布后的技术债。
-
-- **建议：** 将 `atomic-write` 和 `validateMode` 的测试覆盖提升至 P1，与其防护的 P0 安全问题同批交付。P2 中保留 hooks 集成测试补全（复杂度高，可延后）。
-
----
-
-### D-DE-07：P0-2（LSP shell 注入）需补充实际利用路径分析
-
-- **严重度：** MEDIUM
-- **描述：**
-
-  PRD 描述 `execSync(\`${checkCommand} ${command}\`)` 存在 shell 注入，定级 P0 合理。但缺少利用路径分析：
-
-  1. **`command` 的来源是什么？** 若来自 LSP servers 的静态配置表（如 `['clangd', 'pyright', 'tsserver']`），则注入向量为空，实际风险为低。
-  2. 若 `command` 可接受用户配置输入（如 `~/.claude/settings.json` 中的自定义 LSP 服务器路径），则注入向量存在，P0 定级正确。
-
-  未看到源码中 `servers.ts:155-163` 的完整上下文（该文件未在本轮读取中覆盖），因此无法做最终判断。
-
-- **建议：** 修复建议（改用 `execFileSync('which', [command])`）无论输入来源如何均为更安全的做法，应执行。但 PRD 应补充"command 参数来源分析"，以准确评估利用难度，避免高估或低估风险。
-
----
-
-### D-DE-08：`--yolo` 之外，Gemini CLI 集成缺少输入大小防护
-
-- **严重度：** LOW（PRD 遗漏项）
-- **描述：**
-
-  代码中已有 `MAX_FILE_SIZE = 5MB`、`MAX_STDOUT_BYTES = 10MB` 的限制，体现了良好的资源防护意识。但 PRD 未提及一个潜在问题：prompt 字符串（`fullPrompt`）本身没有大小上限检查，极大的 prompt 可能导致子进程 stdin 阻塞或 OOM。这是 MCP 工具服务器的常见稳定性风险。
-
-- **建议：** 在 P2/P3 中增加一条：对 `executeGemini` 和 `executeGeminiBackground` 的 `prompt` 参数添加大小上限（建议 4MB，与 MAX_FILE_SIZE 对齐），超出时返回明确错误。
-
----
-
-## 行业标准对照
-
-| 关注点 | 行业最佳实践 | 本项目现状 | 评估 |
-|--------|------------|----------|------|
-| 路径遍历防护 | 使用白名单验证 + 统一入口 | validateMode 存在但 state-manager 未调用 | 部分合规，P0-1 修复后可达标 |
-| Shell 注入 | 始终使用 execFileSync + 参数数组 | execSync 字符串拼接仍存在 | 不合规，需修复 |
-| 动态代码生成 | 禁止将外部数据插入 eval/exec 字符串 | JSON.stringify 插入 `-e` 脚本 | 不合规，P0-7 修复方向正确 |
-| 跨平台兼容 | 使用 path.resolve/path.relative + os.tmpdir() | 多处硬编码 Unix 路径和 shell 语法 | 不合规，P1 修复覆盖主要问题 |
-| 原子写入 | 写临时文件 + rename 保证一致性 | atomicWriteJsonSync 已实现，但无测试 | 实现合规，测试缺失 |
-| 进程子系统 | 先操作后更新状态，失败不污染状态 | handleKillJob 顺序颠倒 | 不合规，P1-11 修复方向正确 |
-| 测试安全关键路径 | 安全函数100%分支覆盖作为合并门禁 | atomic-write、validateMode 无完整测试 | 不合规，优先级应提升 |
-| 资源上限 | MCP 服务器对所有输入设置上限 | 文件/stdout 有限制，prompt 无上限 | 部分合规 |
-
----
-
-## 总体建议
-
-**结论：Modification Required（需修改后方可执行）**
-
-### 关键领域缺陷（Critical Domain Gaps）
-
-1. **P0-3 严重度高估**：`git push origin main` 是 CI 脚本中的流程规范违反，不是安全漏洞，应降级为 P2。将有限的 P0 修复资源集中于真实安全向量（P0-1、P0-7、P0-2）。
-
-2. **P1-9 业务价值严重低估**：delegation-enforcer 未集成导致 model routing 规范形同虚设，在高并行场景下持续产生 3-10x 成本放大效应。应作为 P1 最高优先级修复，并补充成本影响量化。
-
-3. **P0-5 事实描述不准确**：代码已有 `console.error` 日志，"静默失败"描述有误。真实风险是功能降级（角色验证失效），应修正描述并重新评估是否维持 P0 定级。
-
-4. **测试补全优先级偏低**：`atomic-write` 和 `validateMode` 的测试覆盖应与对应的 P0 安全修复同批交付，而非推迟至 P2 批次，否则安全修复缺乏回归保障。
-
-5. **P0-2 利用路径分析缺失**：需补充 LSP `command` 参数来源分析，以准确评估实际利用难度，避免决策层误判优先级。
-
-### 执行建议
-
-- **Batch 1（P0 真实安全漏洞）**：P0-1、P0-2、P0-6、P0-7，以及 atomic-write 测试覆盖
-- **Batch 2（P1 高影响功能修复）**：P1-9（delegation-enforcer 集成）优先于其他 P1；P1-11、P1-10
-- **Batch 3（P1 其余 + P0-3 降级处理）**：Windows 兼容性（P1-1~P1-4）、内存泄漏（P1-5~P1-7）、P2-3（P0-3 降级后放此）
-- **Batch 4（P2/P3）**：命名空间清洁、文档同步、代码质量

package/docs/reviews/ultrapower-full-bugfix-plan/review_product.md

@@ -1,135 +0,0 @@
-# Product Strategy Review: ultrapower 全面痛点修复计划
-
-> 评审人: Product Director (axiom-product-director)
-> 评审日期: 2026-03-01
-> PRD 版本: Draft (118 问题，4 批次修复)
-> 产品版本基线: v5.4.8
-
----
-
-## 整体评分：6 / 10
-
-**评分理由**：PRD 在技术识别层面做得扎实（问题分类清晰、P0 安全标注准确），但在产品战略层面存在三个根本性缺陷：缺乏用户影响量化、批次计划与发布节奏脱钩、验收标准停留在工程层面而非用户体验层面。这是一份偏工程视角的 Bug 修复计划，尚未达到可指导产品决策的 PRD 标准。
-
----
-
-## 肯定点
-
-### 1. P0 安全问题识别准确
-
-将路径遍历（state-manager）、Shell 注入（LSP）、代码注入（daemon ESM）列为最高优先级，符合"信任边界优先"的产品安全原则。这 7 项 P0 安全问题一旦被利用，可能导致用户系统级损害，产品口碑不可逆受损，优先修复是正确决策。
-
-### 2. Windows 平台单独分层合理
-
-明确将 Windows 兼容性问题单列为 P1，与用户主运行环境（Windows 11）的实际情况一致。结合项目历史（2026-02-27 Windows hook 路径修复会话、$USERPROFILE 修复）可知这是持续性痛点，专项分层有必要。
-
-### 3. 分批策略体现了优先级意识
-
-4 个批次的整体方向（安全 -> 功能 -> 规范 -> 质量）逻辑清晰，符合"先稳定、后完善"的发布逻辑，避免了将代码质量整理与安全修复混在同一批次增加回归风险。
-
----
-
-## 差异点 / 问题
-
-### D-PD-01: 用户影响维度完全缺失
-
-- 严重度: HIGH
-- 描述: PRD 列出了 118 项技术问题，但没有一项标注了"受影响用户规模"或"触发频率"。以 P1 内存泄漏（Python REPL Map、LSP timer）为例，这些问题仅在长时间会话中才会显现，实际触发用户比例可能很低；而 P2 中的 session-recovery 占位功能，却可能影响所有遭遇 Claude Code 崩溃的用户。当前优先级排序完全由技术严重度驱动，缺乏用户价值维度的校准。
-- 建议: 为每个优先级组补充"影响用户估计"（高/中/低频触发）和"用户可感知程度"（是否导致用户可见错误），作为优先级最终排序的第二权重。至少对 31 项 HIGH 问题进行用户影响评分。
-
----
-
-### D-PD-02: PRD 背景描述存在重大遗漏
-
-- 严重度: HIGH
-- 描述: PRD 背景部分仅用一段话描述问题全景，完全没有提及项目当前真实状态。从 active_context.md 和 reflection_log.md 可知，项目已经经历了多轮紧急修复（v5.4.1 plugin.json 验证、v5.4.5 二次注入、v5.4.6 npm-cache 死锁），这些修复均源于生产环境的真实用户报错。这意味着"产品当前稳定性欠佳"这一背景是已知事实，但 PRD 没有将这个语境显式化，导致读者无法判断修复计划的紧迫性来自历史积压还是新发现的问题。
-- 建议: 在背景部分增加"当前产品健康状态"小节，说明：(1) 近 3 个月生产环境紧急修复次数（至少 5 次）；(2) 用户报告的核心痛点（plugin 安装失败、hook 路径错误）；(3) 技术债务积累的历史原因（快速迭代期遗留）。这样才能让 PRD 的紧迫性论证站得住脚。
-
----
-
-### D-PD-03: "23项"与"31项"HIGH 严重度数据不一致
-
-- 严重度: HIGH
-- 描述: PRD 目标部分写道"消除 HIGH 严重度安全与稳定性 Bug（共 23 项实际统计为 31 项）"，这句话暗示了两个相互矛盾的数字，且没有解释差异来源。这对于需要向团队或外部利益相关方传达修复范围的产品文档而言，是严重的可信度问题——读者无法确认哪个数字是权威数字，也无法判断是否存在"被低估的修复工作量"。
-- 建议: 在 PRD 正式化之前必须厘清两个数字的来源：23 项是最初估计、31 项是精确统计，还是存在口径差异（例如 23 项是安全类、31 项含稳定性）。选择唯一权威数字，并在脚注说明统计口径。
-
----
-
-### D-PD-04: Batch 1 与 Batch 2 存在未声明的技术依赖
-
-- 严重度: MEDIUM
-- 描述: P0 安全修复（Batch 1）中包含 state-manager 路径遍历防护（要求 `assertValidMode()` 接口）；而 P1 Windows 修复（Batch 2）中的 subagent-tracker 路径和 pre-tool 路径问题，很可能需要复用同一批路径处理工具函数。PRD 将两者拆入不同批次，但未说明跨批次的接口契约：Batch 2 能否独立于 Batch 1 的路径工具函数实现？如果不能，批次边界就存在隐性依赖，可能导致 Batch 2 开发时需要等待或重构 Batch 1 的输出。
-- 建议: 在分批计划中增加"批次间接口契约"小节，明确 Batch 1 输出哪些可复用的工具函数/类型定义，供 Batch 2 直接引用。可参考项目现有实践（Sub-PRD T-01 中循环依赖防护注释的做法）。
-
----
-
-### D-PD-05: 验收标准停留在工程层面，缺乏用户验收维度
-
-- 严重度: MEDIUM
-- 描述: 当前验收标准（零回归、安全门禁、Windows 验证、测试新增、命名空间清洁、文档同步）全部是工程验收指标，没有用户体验层面的验收。以 P1 功能缺失（session-recovery 占位、job-management 阻塞）为例，即使代码修复通过了测试，用户是否能感知到体验改善？改善的幅度是否达到预期？这些在当前标准中无法被验证。
-- 建议: 为每个批次增加"用户可感知验收"维度，例如：Batch 2 完成后，在 Windows 环境执行核心工作流（auto-update、ax-export）的端到端成功率应达到 100%（对比 Batch 2 前的失败率基线）。
-
----
-
-### D-PD-06: P2 命名空间迁移（superpowers -> ultrapower）的业务风险未评估
-
-- 严重度: MEDIUM
-- 描述: PRD 将 9 个文件的命名空间迁移（superpowers: -> ultrapower:）列为 P2。但从产品角度看，这不仅是代码整洁问题：如果用户当前的 CLAUDE.md、settings.json、或个人工作流脚本中使用了 `superpowers:` 前缀调用命令，命名空间修复后这些调用是否会静默失效？PRD 没有评估向后兼容性风险，也没有说明是否存在兼容层（例如 alias 机制）来保护现有用户。
-- 建议: 在 P2 命名空间修复前，明确两点：(1) 目前是否存在用户可调用的 `superpowers:` 命令（通过 skills/commands 目录确认）；(2) 如果存在，是否需要保留兼容 alias 至下一个大版本（参考 CLAUDE.md 中的废弃别名机制）。将这两点作为 P2 的前置调查任务。
-
----
-
-### D-PD-07: 与 Q1/Q2 路线图的对齐关系缺失
-
-- 严重度: MEDIUM
-- 描述: PRD 没有说明这个修复计划与产品大版本路线图的关系。从项目历史看，ultrapower 处于高速迭代阶段（2 周内连续发布 v5.4.1 到 v5.4.8），这 118 个问题是否会与正在进行的新功能开发（例如 Nexus v2、deepinit 271 个 AGENTS.md）形成冲突？修复计划是独立于功能开发还是并行进行？如果并行，代码冲突和测试稳定性风险如何管理？
-- 建议: 增加"路线图对齐"小节，明确说明：(1) 4 个批次的预计发布版本号（如 Batch 1 对应 v5.5.0 patch，Batch 2 对应 v5.5.1 等）；(2) 是否有功能冻结期来保障修复质量；(3) 与正在进行的功能开发的冲突管理策略。
-
----
-
-### D-PD-08: delegation-enforcer 未集成的业务影响未阐明
-
-- 严重度: LOW
-- 描述: PRD 将 "delegation-enforcer 未集成" 列为 P1 功能缺失，但没有解释其业务影响：delegation-enforcer 负责什么约束？不集成的情况下，用户或系统会出现什么可见的异常行为？如果这个组件是 OMC 核心编排逻辑的一部分，其缺失可能导致某些委派场景静默失效，影响用户对 multi-agent 工作流的信任。
-- 建议: 在 PRD 中补充对 delegation-enforcer 未集成的用户可见影响描述（哪些场景会因此产生错误行为或降级行为），以支持 P1 优先级的合理性论证。
-
----
-
-### D-PD-09: 测试覆盖补全的范围不够明确
-
-- 严重度: LOW
-- 描述: PRD 提到"补全测试覆盖空白（atomic-write, version, hooks）"，但"空白"的定义模糊。从项目历史看，当前测试数量从 4663 增长到 4698，增量不大。118 个问题修复后，预期新增多少测试用例？当前覆盖率基线是多少？目标覆盖率是多少？没有这些数据，"测试新增"这一验收标准无法被量化验证。
-- 建议: 在验收标准中为测试补全设定可量化目标，例如："Batch 3 完成后，atomic-write、version、hooks 三个模块的单元测试行覆盖率均不低于 80%"，并提供当前基线数据。
-
----
-
-## 总体建议
-
-### 立即修复（进入执行前必须解决）
-
-1. 解决 HIGH 问题数量不一致（D-PD-03）：在 ax-review 流程进入 ax-decompose 之前，必须确认 PRD 中 31 项 HIGH 问题的完整清单，不能带模糊数字进入开发阶段。
-
-2. 补充用户影响评分（D-PD-01）：为 31 项 HIGH 问题中每一项标注"用户可见性"（1=内部逻辑不可见，2=间接影响，3=用户直接报错），作为细粒度排序依据。
-
-### 进入 Batch 1 前的调查任务（Low-cost，1-2小时）
-
-3. 确认 superpowers: 命名空间的用户暴露面（D-PD-06）：grep skills/commands 目录，确认是否有用户可调用的 superpowers: 命令，决定是否需要兼容 alias。
-
-4. 补充 delegation-enforcer 的用户可见影响描述（D-PD-08）：可通过代码搜索确认其调用链，不需要新调查。
-
-### 发布策略建议
-
-当前产品在 2 周内经历 5 次紧急修复（v5.4.1 到 v5.4.8），这本身是一个信号：紧急响应速度很快，但系统性防御不足。建议将此次 4 批次修复计划与版本号策略绑定：
-
-- Batch 1（P0 安全）-> v5.5.0（minor 版本，明确传递"安全加固"信号）
-- Batch 2（P1 Windows+功能）-> v5.5.1
-- Batch 3（P2 命名空间+文档）-> v5.5.2
-- Batch 4（P3 代码质量）-> v5.5.3 或合并至下一个 minor
-
-每个批次在独立分支上开发，通过 CI Gate 后合并到 dev，避免批次间的代码污染。这也与项目现有的 PR 工作流保持一致。
-
-### 最终结论
-
-- **优先级**: P1 - Should Have（当前版本）
-- **条件**: 必须在执行前解决 D-PD-01（用户影响评分）和 D-PD-03（HIGH 问题数量一致性）
-- **备注**: 这是一个技术上正确但产品战略论证尚不充分的修复计划。最大风险不在于修复本身，而在于 118 个问题对应的"用户可感知价值"没有被量化——执行完之后，团队无法有证据地向用户或利益相关方说明"产品变好了多少"。建议在 ax-decompose 阶段将用户影响评分纳入每个 Sub-PRD 的验收标准。