@liangjie559567/ultrapower 7.5.2 → 7.7.0

package/docs/reviews/bugs-pain-points-audit/review_tech.md

@@ -0,0 +1,382 @@
+# Tech Feasibility Review: ultrapower v7.5.2 BUG 与痛点审计
+
+## 评审概要
+
+**评审人**: Tech Lead
+**评审日期**: 2026-03-16
+**PRD 版本**: Draft
+**评审结论**: ✅ **通过 - 需分阶段实施**
+
+---
+
+## 1. 架构影响分析 (Architecture Impact)
+
+### 1.1 Schema Changes
+**状态**: ❌ 无 Schema 变更
+
+本次审计为**纯修复性工作**，不涉及：
+- 数据库 Schema 变更
+- 状态文件格式变更
+- API 接口变更
+
+### 1.2 API Changes
+**状态**: ❌ 无 API 变更
+
+所有修复均为**内部实现优化**，对外接口保持向后兼容：
+- Hook 接口不变（仅增强输入验证）
+- Agent 生命周期接口不变（修复推断逻辑）
+- 状态管理接口不变（增强并发保护）
+
+### 1.3 架构完整性评估
+
+| 维度 | 当前状态 | 修复后状态 | 影响评级 |
+|------|----------|------------|----------|
+| **安全边界** | 存在路径遍历漏洞 | 强制白名单校验 | 🔴 高影响 |
+| **状态一致性** | 部分绕过原子写入 | 统一原子写入 + 重试 | 🟡 中影响 |
+| **并发控制** | 四层保护不完整 | 补全 debounce + atomic | 🟡 中影响 |
+| **生命周期管理** | 推断逻辑错误 | 修复 success !== false | 🟢 低影响 |
+
+**架构风险**:
+- ✅ 无破坏性变更
+- ✅ 向后兼容
+- ⚠️ 需要全面回归测试（状态管理路径变更）
+
+---
+
+## 2. 技术可行性评估 (Feasibility Assessment)
+
+### 2.1 P0 问题修复（阻塞性）
+
+#### 2.1.1 安全加固
+
+**可行性**: ✅ 高（已有实现参考）
+
+| 反模式 | 修复方案 | 实施难度 | 风险 |
+|--------|----------|----------|------|
+| AP-S01: 路径遍历 | 使用 `assertValidMode()` 强制校验 | 低 | 低（已有 validateMode.ts） |
+| AP-S02: 废弃字段读取 | 统一使用 `success !== false` | 低 | 低（单点修改） |
+| AP-S03: 敏感信息存储 | 文件权限 0o600 + 审计日志 | 中 | 低（已有 atomic-write.ts） |
+
+**技术依赖**:
+- ✅ `src/lib/validateMode.ts` 已存在
+- ✅ `src/lib/atomic-write.ts` 已支持权限设置
+- ✅ v6.0.0 已实现安全审计日志
+
+**实施路径**:
+```typescript
+// 1. 全局搜索未校验的 mode 拼接
+grep -r "\.omc/state/\${mode}" src/
+
+// 2. 批量替换为安全模式
+const validMode = assertValidMode(mode);
+const path = `.omc/state/${validMode}-state.json`;
+```
+
+#### 2.1.2 状态一致性
+
+**可行性**: ✅ 高（技术债务 TD-4 已识别）
+
+| 问题 | 修复方案 | 实施难度 | 风险 |
+|------|----------|----------|------|
+| AP-C01: 绕过原子写入 | 统一使用 `atomicWriteJsonSyncWithRetry` | 中 | 中（需回归测试） |
+| AP-ST02: 跨会话误清理 | 增强 session_id 匹配逻辑 | 低 | 低（已修复 #573） |
+
+**技术依赖**:
+- ✅ `atomicWriteJsonSyncWithRetry` 已在 v6.0.0 实现
+- ✅ 指数退避重试机制已就绪
+
+**实施路径**:
+```typescript
+// 替换 writeTrackingStateImmediate 中的直接写入
+- writeFileSync(statePath, JSON.stringify(state, null, 2));
++ atomicWriteJsonSyncWithRetry(statePath, state, 3);
+```
+
+#### 2.1.3 Agent 生命周期
+
+**可行性**: ✅ 高（已修复 Bug #1）
+
+| 问题 | 修复方案 | 实施难度 | 风险 |
+|------|----------|----------|------|
+| AP-AL01: 孤儿 Agent 误发信号 | 批量清除（删除 tracking 文件） | 低 | 低（已实现） |
+| AP-AL02: 超时阈值混淆 | 文档澄清 + 提取常量 | 低 | 低 |
+| AP-AL03: 死锁检测缺失 | 实现 DEADLOCK_CHECK_THRESHOLD 逻辑 | 高 | 中（需设计检测算法） |
+
+**技术挑战**:
+- ⚠️ 死锁检测需要实现**循环依赖图分析**
+- ⚠️ 需要定义"相互等待"的精确语义
+
+### 2.2 P1 问题修复（严重）
+
+#### 2.2.1 测试质量
+
+**可行性**: ✅ 中（需补充边界用例）
+
+**测试覆盖缺口**:
+- 并发写入冲突场景（subagent-tracking.json）
+- Windows 平台 rename 失败处理
+- 状态文件损坏恢复流程
+- 超时/孤儿/死锁边界情况
+
+**实施成本**: 3-5 天（编写 + 验证）
+
+#### 2.2.2 文档同步
+
+**可行性**: ✅ 高（已有规范文档）
+
+**差异点修复**:
+- D-03: 合法 mode 数量（7 → 8）
+- D-04: 互斥模式范围（2 → 4）
+- D-09: stale 阈值双重含义澄清
+
+**实施成本**: 1-2 天（文档更新 + 代码注释）
+
+### 2.3 P2 改进（优化）
+
+**可行性**: ✅ 低优先级（可延后至 v8.0）
+
+**技术债务清理**:
+- 51 个 TODO/FIXME/HACK 标记
+- 需逐个评估是否仍然有效
+
+---
+
+## 3. 风险评估 (Risk Assessment)
+
+### 3.1 技术风险
+
+| 风险项 | 概率 | 影响 | 缓解措施 |
+|--------|------|------|----------|
+| 原子写入性能回退 | 中 | 中 | 保留 debounce 层，仅修复即时写入 |
+| Windows 平台兼容性 | 低 | 高 | 增加 Windows CI 测试 |
+| 并发测试不充分 | 高 | 中 | 补充压力测试用例 |
+| 死锁检测误报 | 中 | 低 | 先实现警告模式，不自动终止 |
+
+### 3.2 复杂度评分
+
+**总体复杂度**: 6/10（中等）
+
+| 维度 | 评分 | 说明 |
+|------|------|------|
+| 代码变更范围 | 7/10 | 涉及核心状态管理路径 |
+| 测试复杂度 | 8/10 | 需要并发场景测试 |
+| 回归风险 | 5/10 | 向后兼容，但需全面验证 |
+| 文档工作量 | 3/10 | 主要是澄清现有差异点 |
+
+### 3.3 POC 需求
+
+**状态**: ⚠️ 部分需要
+
+| 功能 | 是否需要 POC | 原因 |
+|------|--------------|------|
+| 原子写入统一 | ❌ 否 | 已有 v6.0.0 实现 |
+| 死锁检测算法 | ✅ 是 | 需验证检测准确性 |
+| Windows 命令注入防护 | ❌ 否 | 已在 v5.5.18 修复 |
+
+---
+
+## 4. 实施计划 (Implementation Plan)
+
+### 4.1 分阶段策略
+
+**Phase 1: P0 安全修复（1 周）**
+```
+Day 1-2: 路径遍历漏洞修复
+  - 全局搜索未校验的 mode 拼接
+  - 批量替换为 assertValidMode()
+  - 补充单元测试
+
+Day 3-4: 状态一致性修复
+  - 替换 writeTrackingStateImmediate 为原子写入
+  - 验证并发写入场景
+  - 压力测试
+
+Day 5: Agent 生命周期修复
+  - 统一 success !== false 推断逻辑
+  - 提取超时常量
+  - 文档澄清
+```
+
+**Phase 2: P1 质量提升（1 周）**
+```
+Day 1-3: 测试覆盖补充
+  - 并发场景测试
+  - Windows 平台测试
+  - 边界情况测试
+
+Day 4-5: 文档同步
+  - 修复差异点 D-03/D-04/D-09
+  - 更新代码注释
+  - 补充示例
+```
+
+**Phase 3: P2 优化（可选，2 周）**
+```
+Week 1: 技术债务清理
+  - 评估 51 个 TODO/FIXME
+  - 清理过期标记
+  - 重构反模式代码
+
+Week 2: 死锁检测 POC
+  - 设计检测算法
+  - 实现原型
+  - 验证准确性
+```
+
+### 4.2 Backend 实施细节
+
+**核心修改文件**:
+```
+src/lib/validateMode.ts          # 已存在，无需修改
+src/lib/atomic-write.ts          # 已存在，无需修改
+src/hooks/subagent-tracker/index.ts  # 修复原子写入
+src/hooks/session-end/index.ts   # 已修复，验证即可
+src/hooks/bridge-normalize.ts    # v6.0.0 已完成
+```
+
+**预计变更行数**: 200-300 行（主要是替换调用）
+
+### 4.3 Frontend 实施细节
+
+**状态**: ❌ 无 Frontend 变更
+
+本次审计为纯后端修复，不涉及 UI 变更。
+
+---
+
+## 5. 成本估算 (Cost Estimation)
+
+### 5.1 人力成本
+
+| 阶段 | 工作量 | 人员配置 | 日历时间 |
+|------|--------|----------|----------|
+| Phase 1 (P0) | 5 人日 | 1 Senior Dev | 1 周 |
+| Phase 2 (P1) | 5 人日 | 1 Mid Dev | 1 周 |
+| Phase 3 (P2) | 10 人日 | 1 Mid Dev | 2 周（可选） |
+| **总计** | **20 人日** | **1-2 人** | **2-4 周** |
+
+### 5.2 技术成本
+
+| 项目 | 成本 | 说明 |
+|------|------|------|
+| CI/CD 资源 | 低 | 复用现有 GitHub Actions |
+| 测试环境 | 低 | 本地 + Windows CI |
+| 文档工具 | 零 | Markdown + Git |
+| **总计** | **低** | 无额外基础设施成本 |
+
+### 5.3 机会成本
+
+**延迟修复的风险**:
+- 🔴 路径遍历漏洞可能被利用（安全风险）
+- 🟡 状态文件损坏导致用户数据丢失（信任风险）
+- 🟢 技术债务累积影响 v8.0 重构（开发效率）
+
+**建议**: P0 问题应在 **v7.5.3** 中立即修复，不应延后。
+
+---
+
+## 6. 依赖关系分析 (Dependencies)
+
+### 6.1 内部依赖
+
+```mermaid
+graph TD
+    A[validateMode.ts] --> B[所有状态文件操作]
+    C[atomic-write.ts] --> B
+    D[bridge-normalize.ts] --> E[所有 Hook 处理器]
+    F[subagent-tracker] --> C
+    F --> A
+```
+
+**关键路径**:
+- `validateMode.ts` 是安全边界的基石
+- `atomic-write.ts` 是状态一致性的保障
+- 两者已在 v6.0.0 实现，修复工作为**应用层调用统一**
+
+### 6.2 外部依赖
+
+**状态**: ✅ 无新增外部依赖
+
+所有修复均使用现有依赖：
+- Node.js fs 模块
+- TypeScript 类型系统
+- Vitest 测试框架
+
+### 6.3 版本兼容性
+
+| 依赖 | 当前版本 | 最低要求 | 兼容性 |
+|------|----------|----------|--------|
+| Node.js | 18+ | 18.0.0 | ✅ |
+| TypeScript | 5.x | 5.0.0 | ✅ |
+| Vitest | 最新 | 1.0.0 | ✅ |
+
+---
+
+## 7. 实施建议 (Recommendations)
+
+### 7.1 优先级排序
+
+**立即执行（v7.5.3）**:
+1. ✅ 路径遍历漏洞修复（AP-S01）
+2. ✅ SubagentStopInput.success 推断修复（AP-S02）
+3. ✅ 原子写入统一（AP-C01）
+
+**短期执行（v7.6.0）**:
+4. ⚠️ 测试覆盖补充
+5. ⚠️ 文档差异点修复
+6. ⚠️ 超时常量提取
+
+**长期规划（v8.0）**:
+7. 🔵 死锁检测实现
+8. 🔵 技术债务清理
+9. 🔵 性能优化
+
+### 7.2 质量门禁
+
+**发布前必须满足**:
+- ✅ 所有 P0 问题修复完成
+- ✅ 单元测试覆盖率 > 80%
+- ✅ 并发压力测试通过（100 并发写入）
+- ✅ Windows CI 测试通过
+- ✅ 无新增 ESLint 错误
+
+### 7.3 回滚计划
+
+**风险缓解**:
+- 保留 v7.5.2 分支作为回滚点
+- 状态文件格式不变，支持热回滚
+- 增量发布：先 beta 测试 1 周，再正式发布
+
+---
+
+## 8. 结论 (Conclusion)
+
+### 8.1 总体评估
+
+**可行性**: ✅ **高度可行**
+
+- 技术方案成熟（v6.0.0 已验证）
+- 实施风险可控（向后兼容）
+- 成本合理（2-4 周）
+
+### 8.2 推荐决策
+
+**建议**: ✅ **批准实施，分阶段执行**
+
+**理由**:
+1. P0 安全问题不容延迟
+2. 技术债务已影响开发效率
+3. 修复成本远低于延迟风险
+
+### 8.3 关键成功因素
+
+1. **充分的回归测试**（尤其是并发场景）
+2. **Windows 平台验证**（CI 覆盖）
+3. **文档同步更新**（避免新的差异点）
+4. **分阶段发布**（降低回滚成本）
+
+---
+
+**评审签名**: Tech Lead
+**评审日期**: 2026-03-16
+**下一步**: 提交 Product Manager 审批

package/docs/reviews/bugs-pain-points-audit/review_ux.md

@@ -0,0 +1,161 @@
+# UX Review: ultrapower v7.5.2 BUG 与痛点审计
+
+## 1. Flow Analysis (流程分析)
+
+### 问题 1: 用户角色定义模糊 (P1)
+**当前状态**: PRD 列出 4 个角色（开发者、贡献者、用户、架构师），但"用户"和"开发者"的边界不清晰。
+**影响**: ultrapower 的最终用户就是开发者，这种角色划分会造成混淆。
+**建议**:
+- 重新定义为：核心维护者、外部贡献者、终端用户（使用 ultrapower 的开发者）
+- 明确每个角色在审计流程中的参与点
+
+### 问题 2: 审计执行流程缺失 (P0)
+**当前状态**: PRD 只列出"要审计什么"，没有说明"如何执行审计"。
+**影响**: 读者无法理解从启动审计到输出报告的完整流程。
+**建议**: 补充流程图：
+```
+启动审计 → 自动扫描 → 人工分类 → 优先级排序 → 生成报告 → 修复验证
+```
+
+### 问题 3: MVP 范围过大 (P1)
+**当前状态**: P0 包含 3 大类问题，P1 包含 3 大类，没有明确的阶段划分。
+**影响**: 无法判断"最小可交付"是什么，容易导致范围蔓延。
+**建议**:
+- 将 P0 缩减为单一关键路径：安全加固 → 状态一致性验证
+- 其他问题移至 P1/P2
+
+## 2. UI/Visual Feedback (视觉反馈)
+
+### 问题 4: 错误信息不面向用户 (P0)
+**当前状态**: 附录 A 列出的反模式代码（如 AP-S01、AP-ST01）对终端用户来说是黑盒。
+**影响**: 当用户遇到路径遍历错误或状态污染时，无法理解发生了什么。
+**建议**:
+- 为每个反模式补充"用户可见的错误表现"
+- 示例：AP-S01 → 用户看到 "Error: Invalid state file path" 但不知道是输入验证失败
+
+### 问题 5: 缺少进度可见性 (P1)
+**当前状态**: 审计过程中没有进度指示器或里程碑。
+**影响**: 对于 1198 个文件的扫描，用户不知道需要等多久。
+**建议**:
+- 添加进度反馈机制：已扫描文件数 / 总文件数
+- 关键阶段完成时的通知（如"安全扫描完成，发现 3 个 P0 问题"）
+
+### 问题 6: 技术债务可视化缺失 (P2)
+**当前状态**: "51 个 TODO/FIXME/HACK" 只是一个数字。
+**影响**: 无法快速识别哪些债务最紧急、分布在哪些模块。
+**建议**:
+- 提供热力图或分类统计（按模块、按严重程度）
+- 示例：状态管理模块 15 个，Agent 生命周期 12 个
+
+## 3. Usability Score (1-10)
+
+**评分: 4/10**
+
+**理由**:
+- ✅ 问题分类清晰（安全、状态、生命周期）
+- ✅ 优先级标记明确（P0/P1/P2）
+- ❌ 缺少可执行的操作流程
+- ❌ 错误信息不面向终端用户
+- ❌ 没有成功标准和验收条件
+- ❌ 文档可读性差（技术术语密度过高）
+
+## 4. 开发者体验 (DX) 痛点
+
+### 问题 7: 调试路径不清晰 (P0)
+**当前状态**: 当开发者遇到"状态污染"或"孤儿 Agent"时，PRD 没有提供调试指南。
+**影响**: 开发者需要自己阅读 1198 个文件来定位问题。
+**建议**:
+- 为每个反模式提供"如何复现"和"如何调试"步骤
+- 示例：AP-AL01 → 运行 `omc doctor --check-orphans` 查看孤儿列表
+
+### 问题 8: 修复优先级与用户痛点脱节 (P1)
+**当前状态**: P0 问题是"安全加固"，但用户最常遇到的可能是"Agent 超时"。
+**影响**: 修复顺序可能与用户实际痛点不匹配。
+**建议**:
+- 补充"用户报告频率"数据（如果有 issue tracker）
+- 将高频痛点提升优先级
+
+### 问题 9: 缺少回滚机制 (P1)
+**当前状态**: 如果审计后的修复引入新问题，没有回滚方案。
+**影响**: 用户可能被迫停留在有 bug 的版本。
+**建议**:
+- 明确版本策略：v7.5.2 → v7.5.3-audit-fix
+- 提供降级指南
+
+## 5. 文档可用性问题
+
+### 问题 10: 术语过载 (P1)
+**当前状态**: PRD 中出现大量未定义术语：worktree、SubagentStopInput、DEADLOCK_CHECK_THRESHOLD。
+**影响**: 新贡献者无法理解问题上下文。
+**建议**:
+- 添加术语表或链接到相关文档
+- 首次出现时提供简短解释
+
+### 问题 11: 反模式代码缺少对比 (P0)
+**当前状态**: 只说"不要这样做"，没有展示"应该这样做"。
+**影响**: 开发者不知道正确的实现方式。
+**建议**:
+- 为每个反模式提供 Before/After 代码示例
+- 示例：
+```typescript
+// ❌ AP-S01: 错误
+const path = `.omc/state/${mode}-state.json`;
+
+// ✅ 正确
+import { assertValidMode } from './validateMode';
+const validMode = assertValidMode(mode);
+const path = `.omc/state/${validMode}-state.json`;
+```
+
+### 问题 12: 成功标准缺失 (P0)
+**当前状态**: 没有定义"审计完成"的标准。
+**影响**: 无法判断何时可以关闭审计任务。
+**建议**:
+- 添加验收条件：
+  - 所有 P0 问题修复并通过测试
+  - 文档更新完成
+  - 回归测试通过率 > 95%
+
+## 6. 交互设计问题
+
+### 问题 13: 错误恢复路径不明确 (P1)
+**当前状态**: 当用户遇到"状态污染"时，PRD 没有说明如何清理。
+**影响**: 用户可能需要手动删除状态文件，导致数据丢失。
+**建议**:
+- 提供自动修复命令：`omc repair --fix-state-pollution`
+- 在错误信息中包含修复提示
+
+### 问题 14: 批量操作缺失 (P2)
+**当前状态**: 51 个技术债务需要逐个处理。
+**影响**: 效率低下，容易遗漏。
+**建议**:
+- 提供批量修复工具：`omc fix --pattern="TODO:security"`
+- 生成修复清单供人工审核
+
+## Conclusion (结论)
+
+**评审结果: Optimizable (可优化)**
+
+### Top 3 Changes Needed (亟待改进):
+
+1. **补充可执行流程** (P0)
+   - 添加从启动到验证的完整操作步骤
+   - 为每个反模式提供调试和修复指南
+   - 定义明确的成功标准
+
+2. **改善错误可见性** (P0)
+   - 将技术反模式翻译为用户可见的错误表现
+   - 为每个问题提供 Before/After 代码示例
+   - 添加错误恢复路径
+
+3. **优化信息架构** (P1)
+   - 重新定义用户角色，避免混淆
+   - 缩减 MVP 范围，聚焦关键路径
+   - 添加术语表和进度反馈机制
+
+### 额外建议:
+- 考虑将此 PRD 拆分为两个文档：
+  - **审计执行计划**（面向执行者）
+  - **问题修复指南**（面向开发者）
+- 补充用户调研数据（如果有）来验证优先级排序
+- 提供交互式问题浏览器（如 Web UI）而非纯文本列表

package/docs/reviews/bugs-pain-points-audit/summary.md

@@ -0,0 +1,129 @@
+# 评审摘要: ultrapower v7.5.2 BUG 与痛点审计
+
+**生成日期**: 2026-03-16
+**评审轮次**: 5 专家并行评审
+**原始 PRD**: bugs-pain-points-audit-draft.md
+**最终 PRD**: bugs-pain-points-audit-rough.md
+
+---
+
+## 1. 关键决策
+
+### 决策 1: 分阶段发布策略
+**冲突**: Product 建议缩减 MVP vs Tech 建议 3 阶段实施 vs Critic 要求完整安全验证
+**仲裁**: 技术可行性 > 战略对齐
+**决策结果**: 采用 3 阶段发布
+- v7.5.3 (2 周): P0 安全 + 状态一致性
+- v7.6.0 (4 周): P0 生命周期 + P1 测试/文档
+- v7.7.0+ (持续): P2 优化项
+
+### 决策 2: 死锁检测优先级
+**冲突**: Domain 标记 P0 vs Tech 标记高难度需 POC vs Critic 要求明确范围
+**仲裁**: 技术可行性 > 业务逻辑
+**决策结果**: 降级为 P1，v7.6.0 实施
+- 原因: 需要 POC 验证检测算法准确性
+- 缓解: v7.5.3 先实现警告模式，不自动终止
+
+### 决策 3: 测试覆盖率目标
+**冲突**: Critic 未定义 vs Product 建议 >80% vs Tech 建议分层
+**仲裁**: 技术可行性 > 战略对齐
+**决策结果**: 采用分层策略
+- 安全关键路径: 100%
+- 状态管理模块: ≥90%
+- 其他模块: ≥80%
+
+### 决策 4: 敏感数据处理
+**冲突**: Critic 要求敏感数据清单 vs Domain 建议加密存储
+**仲裁**: 安全 > 业务逻辑
+**决策结果**: 两者都实施
+- v7.5.3: 建立敏感数据扫描机制 + CI 集成
+- v7.6.0: 实现 AES-256-GCM 加密存储
+
+### 决策 5: 并发度上限
+**冲突**: Critic 要求定义上限 vs Domain 建议限流机制
+**仲裁**: 安全 > 业务逻辑
+**决策结果**: 两者都实施
+- v7.5.3: 硬编码上限 20 个并发 Agent
+- v7.6.0: 实现自适应限流
+
+---
+
+## 2. 范围变更
+
+### 新增需求（来自专家评审）
+
+**安全加固增强** (Critic S-01/S-02/S-03):
+- 静态分析扫描报告（所有 mode 参数使用点）
+- 敏感数据清单和扫描机制
+- Windows 命令注入防护审计
+- CI 门禁：阻止未校验路径拼接
+
+**测试覆盖补充** (Critic E-01/E-02/E-03):
+- 并发压力测试（10+ 会话同时写入）
+- 状态文件损坏恢复测试
+- 跨会话状态污染测试
+- 文件锁超时降级行为验证
+
+**文档改进** (UX 问题 10/11/12):
+- 术语表和首次出现解释
+- 每个反模式的 Before/After 代码示例
+- 调试指南和错误恢复路径
+- 明确的验收标准
+
+**领域特定需求** (Domain G-01/G-02):
+- Agent 级联失败处理文档
+- 分布式追踪支持（OpenTelemetry 集成）
+- 结构化日志（JSON 格式 + 日志级别）
+
+### 移除需求（范围控制）
+
+**延后至 v8.0.0**:
+- Saga 模式补偿事务（Domain G-01）
+- Redis/etcd 状态存储后端（Domain 长期改进）
+- 自适应限流和熔断机制（Domain 长期改进）
+- 性能基准测试（Draft 暂不包含）
+
+**移至技术债务池**:
+- 51 个 TODO/FIXME/HACK 标记清理（P2，按需处理）
+- 开发体验优化（构建速度、调试工具）
+- 性能优化（非关键路径）
+
+### 优先级调整
+
+**升级为 P0**:
+- 敏感数据扫描和加密存储（Critic S-02）
+- 并发度上限配置（Critic E-01）
+- Windows 命令注入审计（Critic S-03）
+
+**降级为 P1**:
+- 死锁检测实现（Tech 高难度，需 POC）
+- 技术债务清理（Product 战略建议）
+
+**降级为 P2**:
+- 开发体验改进（UX 建议，非阻塞）
+- 性能优化（Product 战略建议）
+
+---
+
+## 3. 关键风险与缓解
+
+### 风险 1: 范围蔓延
+**来源**: 5 专家评审新增 15+ 需求
+**缓解**: 严格执行分阶段发布，P2 问题不设硬性 deadline
+
+### 风险 2: 回归引入
+**来源**: Tech 评估，状态管理路径变更
+**缓解**: 强制测试覆盖率门禁 + Windows CI + 分阶段发布
+
+### 风险 3: 用户感知价值低
+**来源**: Product 战略风险评估
+**缓解**: 发布说明强调"更稳定、更安全"，提供迁移指南
+
+---
+
+## 4. 下一步行动
+
+1. **用户确认门禁**: 展示 Rough PRD，询问是否进入任务拆解阶段
+2. **调用 axiom-system-architect**: 进行系统架构设计和任务拆解
+3. **生成 Manifest 清单**: 原子任务 DAG + 依赖关系
+