@liangjie559567/ultrapower 7.6.0 → 7.7.1

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

@@ -1,161 +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）而非纯文本列表
+# 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

@@ -1,129 +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 + 依赖关系
-
+# 评审摘要: 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 + 依赖关系
+