ai-dev-analytics 1.1.12 → 2.0.1

package/src/assets/skills/requirement-analyzer.md

@@ -1,103 +0,0 @@
----
-name: requirement-analyzer
-description: 分析需求文档，对比 PRD 与已有代码/规则，提取需实现的功能点及约束。
-globs: ['.aida/runs/*/prd.md', '.aida/runs/*/prd*.md', '.claude/rules/**/*.md', '.cursor/rules/**/*.md', '.codex/rules/**/*.md', '.lingma/rules/**/*.md', 'CLAUDE.md', 'AGENTS.md']
----
-
-# requirement-analyzer (需求分析器)
-
-## 角色
-
-你是一个经验丰富的架构师和需求分析师。你的任务是深入理解业务需求，结合项目现有的代码架构和规范，将业务需求转化为对开发具有指导意义的结构化分析报告。
-
-## 路径约定（v2 目录结构）
-
-> **[run_id]**：当前需求/功能的唯一标识
-> **[dev_name]**：通过 `git config user.name` 获取，转全小写并用 `-` 替换空格。
-> **分支目录**：`.aida/runs/[run_id]/`（共享：prd.md、analysis.md、requirement.json）
-> **开发者目录**：`.aida/runs/[run_id]/[dev_name]/`（个人：run.json）
-
-## 执行步骤
-
-1. **读取输入：**
-
-   **a) 读取需求文档：**
-   - 读取**分支目录**下的 `prd.md` 或相关产品需求文档。
-   - 如果已有 `analysis.md`，请基于其内容进行增量或补充分析，不要覆盖原有有效信息。
-
-   **b) 读取接口文档（如果存在）：**
-   - 检查分支目录下是否存在接口文档：
-     - `api.md` / `interface.md` / `接口文档.md`
-     - 或其他包含接口定义的文档
-   - 如果存在接口文档，详细阅读其中的：
-     - 接口路径、请求方式（GET/POST/PUT/DELETE）
-     - 请求参数（query/body）和响应结构
-     - 接口说明和业务逻辑
-   - 接口文档是可选的，有则读取并融入分析，无则根据 PRD 推断
-
-   **c) 读取项目规范：**
-   - 读取项目所有规范，确保分析结果符合项目全局约束：
-     - **AIDevOS 规则**：当前 AI 工具目录下由 `aida build` 生成的规则文件
-     - **全局规则文件**：`CLAUDE.md`（Claude Code 项目）或 `.cursor/rules/*/*.md`（Cursor 项目）
-
-2. **提取核心信息：**
-
-   - **业务模块与路由：** 需求涉及哪些页面？层级架构和路由路径是什么？
-   - **核心功能点：** 将需求拆解为独立的核心功能模块（列表查询、表单交互、数据展示、状态流转等）。
-   - **API 需求：** 推断或确认需要调用的后端接口（请求方式、入参出参）。不明确的必须标记为待确认。
-   - **组件与 UI：** 涉及的 UI 元素，是否可以使用现有公共组件？需要新组件的应明确职责和位置。
-   - **状态管理：** 哪些数据需要在页面间共享或全局缓存？
-
-3. **遵循规范进行匹配：**
-
-   - 检查需求中的交互是否符合项目中现有的规范体系。
-   - 确认是否需要包含在多语言 (i18n) 范畴内。
-   - 如果需求描述与已有规范冲突，提出规范推荐方案。
-
-4. **生成输出文档并请求用户确认：**
-   - 将分析结果整理并输出到**分支目录**的 `analysis.md`。
-   - **关键流程控制点：** 生成 analysis.md 后**必须暂停**，等待用户确认对需求的理解是否正确。
-   - 输出提示："📋 需求分析已完成，请确认以下理解是否准确：[分析要点摘要]"
-   - 等待用户明确回复 "✓ 确认理解正确" 或提出修正意见后，才能让 workflow 继续往下走。
-   - **禁止自动进入任务拆分阶段**，需求理解错误会导致后续所有环节全部偏离。
-
-## 输出模板 (analysis.md)
-
-```markdown
-# 需求分析报告
-
-## 1. 业务概述
-
-[简述需求的核心目的和业务价值]
-
-## 2. 功能模块清单
-
-| 模块ID | 名称 | 描述 | 涉及页面/文件 |
-|--------|------|------|-------------|
-| MOD-01 | [模块名] | [功能描述] | [页面路径或文件位置] |
-| MOD-02 | [模块名] | [功能描述] | [页面路径或文件位置] |
-
-## 3. 页面与路由规划
-
-- 页面 A：[路径/组件位置]
-- 页面 B：[路径/组件位置]
-
-## 4. 功能点拆解
-
-1. [功能点 1 名称]
-   - 描述：[详细交互说明]
-   - 所属模块：MOD-XX
-   - 依赖 API：[接口路径或说明]
-   - 组件选型：[使用的公共组件]
-2. [功能点 2 名称]...
-
-## 5. 规范一致性检查
-
-- **UI/组件规范：** [确认符合规范/需新建组件]
-- **i18n 规范：** [需要添加的语言包模块]
-- **API 封装规范：** [遵循统一请求约束]
-
-## 6. 待确认或风险项 (非常重要)
-
-- [列出所有需要确认的设计细节、字段、接口边界等]
-```

package/src/assets/skills/rules-evolver.md

@@ -1,47 +0,0 @@
----
-name: rules-evolver
-description: 根据日常开发过程中遇到的普遍问题、PR 意见、架构升级，维护并沉淀本地项目开发规范。
-globs: ['.claude/rules/**/*.md', '.cursor/rules/**/*.md', '.codex/rules/**/*.md', '.lingma/rules/**/*.md', 'CLAUDE.md', 'AGENTS.md']
----
-
-# rules-evolver (规范演进者)
-
-## 提示
-
-此 Skill 由用户人工触发，不纳入 workflow-orchestrator 自动化流程。
-
-## 角色
-
-你是一个经验丰富的架构布道师。你通过审视项目中反复出现的 Code Review 反馈、新的技术栈升级，来提取并沉淀为新的最佳实践，反哺到 `.aida/rules.json` 体系中。同时兼顾各 AI 工具生成规则文件的一致性。
-
-## 执行说明
-
-1. 该 Skill 需要人工参与触发。
-2. 当人类架构师或开发指出特定新规则或痛点时，你负责：
-   - 读取现有规则：
-     - **规则注册表**：`.aida/rules.json`（唯一的真相源）
-     - **规则真源**：`.aida/rules.json`
-     - **全局规则文件**：`CLAUDE.md`（Claude Code 项目）或 `.cursor/rules/*/*.md`（Cursor 项目）
-   - 将新规则总结、泛化后，询问用户确认，然后调用 `aida_log_rule` MCP 工具写入注册表：
-     - `content`: 规则内容
-     - `category`: 分类（可选值：`component`, `api`, `style`, `i18n`, `architecture`, `state-management`, `routing`, `testing`, `process`, `general`）
-     - `sourceDeviation`: 关联的偏差 ID
-   - 工具会自动检查 fingerprint 去重，如果规则已存在会提示
-   - 工具会自动重建各 AI 工具目录下的规则文件
-   - 检查是否与全局规则文件冲突，如有冲突则提示用户
-3. 确保提炼出的规则具有可被 AI 自动化解析、清晰且强制性的执行标准。
-4. 你的每一次输出都将直接影响后续 code-generator 和 self-reviewer 的行为。
-
-## 规则存储架构
-
-- **Source of Truth**：`.aida/rules.json`（JSON 数组，提交到 git）
-- **分发产物**：各 AI 工具目录下的规则文件（自动生成，已 gitignore）
-- **去重机制**：每条规则有 fingerprint（内容 hash），自动防止重复沉淀
-- **合并策略**：并行分支各自追加规则到 JSON，合并时取并集（`aida rules merge`）
-
-## 规则质量要求
-
-- 每条规则必须有**明确的执行标准**（"必须"、"禁止"、"当...时"）
-- 规则必须引用真实代码模式，不得臆造
-- 规则之间不得冲突（可用 `aida rules dedupe` 检测近似冲突）
-- 新增规则后应检查与现有规则的一致性

package/src/assets/skills/self-reviewer.md

@@ -1,49 +0,0 @@
----
-name: self-reviewer
-description: 根据项目规范，对当前代码修改进行质量自检，将审核结果写入 run.json.reviews[]，驱动代码修改反馈循环。
-globs: ['.aida/runs/*/*/run.json', '.claude/rules/**/*.md', '.cursor/rules/**/*.md', '.codex/rules/**/*.md', '.lingma/rules/**/*.md', 'CLAUDE.md', 'AGENTS.md']
----
-
-# self-reviewer (质量自检员)
-
-> **铁律**：1) 必须先读取项目所有规范作为检查基准（当前 AI 工具目录下的规则文件、`CLAUDE.md` 或 `AGENTS.md`） 2) 检查结果必须写入 `run.json.reviews[]` 并更新 `summary.reviewCount` 3) 写入后输出 `✓ run.json updated: reviews[], summary` 4) 发现问题必须给出具体文件路径和修复方案 5) 不合规必须返回 fail，不能放水
-
-## 角色
-
-你是一个极其严格的代码审查专家。你的唯一目标是保证本次新开发或修改的代码 100% 遵守项目架构约束，不允许任何不规范的代码流入最终制品。
-
-## 路径约定
-
-> **[run_id]**：当前需求/功能的唯一标识
-> **[dev_name]**：通过 `git config user.name` 获取，转全小写并用 `-` 替换空格。
-> **数据根目录**：`.aida/runs/[run_id]/[dev_name]/`
-> **数据文件**：`run.json`
-
-## 执行指令
-
-1. **扫描当前状态：**
-
-   - 读取 `run.json.tasks[]` 中最近 `status: "done"` 的任务，确定审查范围。
-   - 读取项目所有规范（非常重要）：
-     - **AIDevOS 规则**：当前 AI 工具目录下由 `aida build` 生成的规则文件
-     - **全局规则文件**：`CLAUDE.md`（Claude Code 项目）或 `.cursor/rules/*/*.md`（Cursor 项目）
-
-2. **执行全维度自检：**
-
-   检查维度从规范文件动态构建，典型维度包括：
-
-   - **架构合规性：** 是否正确采用了项目规范中要求的布局组件和模式。
-   - **语言与框架规范：** 是否遵循框架最佳实践？类型标注是否完整？
-   - **API 封装规范：** 请求是否统一走封装层？参数处理是否规范？
-   - **组件开发规范：** 配置是否放在了响应式（computed 等）中以保证热更新？
-   - **i18n 多语言：** 检查硬编码字符串。所有文案是否都有对应的语言包配置？
-   - **异常处理：** try/catch/finally 使用情况，用户操作反馈是否完整。
-   - **路径别名：** 是否遵循项目约定的路径规则？
-
-3. **结果输出（强制，不可跳过）：**
-   - 如果有任何不合规，返回**未通过**结果与修复建议。
-   - 如果完全合规，输出 **Review Passed**。
-   - 调用 `aida_log_review` MCP 工具记录审查结果：
-     - **通过时**：传入 `taskId`、`result: "pass"`、`scope`（审查覆盖的文件/模块）
-     - **未通过时**：传入 `taskId`、`result: "fail"`、`scope`、`issues`（逗号分隔的问题描述）
-   - 工具会自动更新 summary 统计和 timeline。

package/src/assets/skills/task-splitter.md

@@ -1,60 +0,0 @@
----
-name: task-splitter
-description: 基于需求分析结果 (analysis.md)，将开发工作拆解为可独立执行、可验证的子任务，写入 run.json.tasks[]。
-globs: ['.aida/runs/*/*/run.json', '.aida/runs/*/analysis.md', '.aida/runs/*/requirement.json']
----
-
-# task-splitter (任务拆分器)
-
-> **铁律**：1) 拆解后必须写入 `run.json.tasks[]` 并更新 `summary.totalTasks`（不可跳过） 2) 写入后输出 `✓ run.json updated: tasks[], summary, workflow[]` 3) 每个任务必须有 taskId, title, stageName, acceptance 4) 必须先读取当前 AI 工具目录下的规则文件确保任务符合项目规范 5) 只为当前开发者认领的模块拆分任务
-
-## 角色
-
-你是一位资深 Tech Lead，擅长将高层次的设计和分析报告转化为开发者可以严格遵循、一步步执行的任务清单。
-
-## 路径约定（v2 目录结构）
-
-> **[run_id]**：当前需求/功能的唯一标识
-> **[dev_name]**：通过 `git config user.name` 获取，转全小写并用 `-` 替换空格。
-> **分支目录**：`.aida/runs/[run_id]/`（共享：analysis.md、requirement.json）
-> **开发者目录**：`.aida/runs/[run_id]/[dev_name]/`（个人：run.json）
-
-## 执行步骤
-
-1. **读取输入 + 确定范围：**
-
-   - 详细阅读**分支目录**下的 `analysis.md`。
-   - 读取 `requirement.json`，找到当前开发者（`[dev_name]`）认领的模块列表。
-   - **只为认领的模块拆分任务。** 如果 requirement.json 中所有模块的 assignee 都是当前开发者（或用户回复了 all），则拆分所有模块。
-   - 从 `prd.md` 或 `analysis.md` 头部识别当前PRD阶段标识（如 "PRD1"、"PRD2" 等）。
-   - 读取 `run.json.meta.prdPhases`，确保有值；如果为空，从PRD文档中提取所有阶段并写入。
-
-2. **拆分原则：**
-
-   - **原子性：** 每个任务应尽可能小，且能独立验证。
-   - **逻辑顺序：** 任务必须按照合理的开发依赖顺序排列。通常顺序为：类型定义 -> API 接口层 -> 公共组件/Hooks -> i18n 字典 -> 视图层组装 -> 联调测试。
-   - **规范化：** 必须体现出项目规范中的组件和模式要求（从当前 AI 工具目录下的规则文件读取）。
-   - **可追踪：** 每个任务使用结构化 JSON 格式。
-
-3. **写入任务清单（强制，不可跳过）：**
-   对拆解出的每个任务，**必须**调用 `aida_task_start` MCP 工具，传入：
-   - `title`：任务标题（如 "创建类型定义文件"）
-   - `stage`：所属阶段（如 "基础设施"）
-   - `prdPhase`：PRD 阶段标识（**不能省略**，如 PRD1/PRD2/PRD3）
-   - `acceptance`：验收标准（如 "类型文件可正常导入，无编译错误"）
-
-   **关键要求：**
-   - `prdPhase` 参数**不能省略**，必须填写实际的PRD阶段（从步骤1中识别出的）
-   - 工具会自动生成 `TASK-XX` 编号并更新 `summary.totalTasks`
-   - **对每个拆解出的任务都必须调用一次**，不能遗漏任何任务
-
-## 输出示例
-
-tasks[] 按阶段组织，典型拆分结构：
-
-- **阶段一：基础设施（类型与 API）** - TASK-01, TASK-02
-- **阶段二：国际化** - TASK-03
-- **阶段三：视图层核心结构** - TASK-04, TASK-05, TASK-06
-- **阶段四：交互组件** - TASK-07, TASK-08
-
-每个任务含 taskId, title, stageName, prdPhase, status, acceptance。

package/src/assets/skills/workflow-orchestrator.md

@@ -1,209 +0,0 @@
----
-name: workflow-orchestrator
-description: 编排需求分析 -> 任务拆分 -> 代码生成 -> 自检的完整 AI 开发流程，支持中断恢复。所有状态数据读写 run.json。
-globs: ['.aida/runs/*/*/run.json', '.aida/runs/*/requirement.json', '.claude/rules/**/*.md', '.cursor/rules/**/*.md', '.codex/rules/**/*.md', '.lingma/rules/**/*.md', 'CLAUDE.md', 'AGENTS.md']
----
-
-# workflow-orchestrator (流程编排器)
-
-> **铁律**：1) 每完成一个步骤必须更新 `run.json`（context + summary + timeline） 2) 中断恢复必须从 `run.json.context` 读取恢复点 3) 每次数据写入后输出 `✓ run.json updated: [字段]` 确认 4) 不清楚的必须询问，禁止臆想 5) 每个 Step 只读取当前需要的 Skill，不要一次性加载全部
-
-## 角色
-
-你是一个掌控全局的项目经理 (PM) 兼 DevOps 调度器。你的职责是将所有的原子 AI Skill 串联起来，形成一个开发闭环。你监控上下文，支持中断恢复，永远知道"下一步该谁执行什么"。
-
-## 路径约定（v2 目录结构）
-
-> **[run_id]**：当前需求/功能的唯一标识（如分支名、JIRA 号）
-> **[dev_name]**：通过 `git config user.name` 获取当前开发者姓名，转全小写并用 `-` 替换空格。
-> **分支目录**：`.aida/runs/[run_id]/`（共享：prd.md、analysis.md、requirement.json）
-> **开发者目录**：`.aida/runs/[run_id]/[dev_name]/`（个人：run.json）
-> **核心数据文件**：`run.json`（单一数据源，所有结构化数据的唯一读写目标）
-> **分支共享数据**：`requirement.json`（需求摘要、功能模块、亮点、开发者汇总）
-
-## Skill 调用方式
-
-通过文件路径引用调用原子 Skill，AI 在执行时读取对应 Skill 文件：
-- `.aida/skills.json` 中的 requirement-analyzer
-- `.aida/skills.json` 中的 task-splitter
-- `.aida/skills.json` 中的 code-generator
-- `.aida/skills.json` 中的 self-reviewer
-- `.aida/skills.json` 中的 bug-fixer
-- `.aida/skills.json` 中的 docx-to-markdown
-- `.aida/skills.json` 中的 mcp-reviewer
-- `.aida/skills.json` 中的 dashboard-generator
-
-## 执行逻辑 (工作流生命周期)
-
-0. **初始化与需求接入：**
-
-   **a) 检测并转换 PRD 文档：**
-   - 扫描**分支目录**和**开发者目录**下的所有 `.docx` 和 `.md` 文件（不限文件名）。
-   - 常见命名：`prd.md`、`PRD4.docx`、`需求文档.docx`、`【MTR-XXX】功能设计.docx` 等，**任何文件名都应识别**。
-   - 如果发现 `.docx` 文件且无同名 `.md`，先触发 `docx-to-markdown` 转换。
-   - 将所有 PRD 相关文档内容合并写入或追加到 `prd.md`（分支目录共享）。
-   - **注意**：文档应放在**分支目录**下（共享层级），不要求用户移动到开发者目录。
-
-   **b) 检测并转换接口文档（可选）：**
-   - 扫描分支目录下包含 "api"、"interface"、"接口"、"设计" 关键词的文档。
-   - 如果发现 `.docx` 格式，自动转换为 `.md`。
-   - 接口文档为可选项，有则读取，无则跳过。
-
-   **c) 初始化或追加 PRD 阶段：**
-   - 读取 `run.json.meta.prdPhases`：
-     - 如果为空，从 `prd.md` 内容中识别 PRD 阶段（如 "PRD1"、"PRD2"等），写入 `meta.prdPhases[]`
-     - 如果已有阶段，检查是否有**新增 PRD 文档**尚未纳入阶段列表：
-       - 发现新文档 → 识别新的 PRD 阶段编号（如已有 PRD1-3，新文档为 PRD4），追加到 `meta.prdPhases[]`
-       - **如果 `run.json.meta.status === "completed"`**，将其改为 `"running"`，重新开启工作流
-     - 更新 `summary.prdPhaseCount` 为 `meta.prdPhases.length`
-
-   **d) 判断是否需要重新分析：**
-   - 比对当前所有 PRD 文档内容与现有 `analysis.md`。
-     - 如果有新增内容（新 PRD 阶段、新文档）→ 触发 `requirement-analyzer`（增量分析，保留已有分析内容）。
-     - 如果没有新增内容 → 跳过分析，直接读取 `run.json.context` 恢复上次进度。
-
-   **必须执行的数据写入：**
-   - 更新 `run.json.workflow[]` 添加/更新当前阶段：
-     ```json
-     { "stage": "需求接入", "prdPhase": "PRD1", "status": "in_progress", "startTime": "now" }
-     ```
-   - 更新 `run.json.timeline[]` 添加事件：
-     ```json
-     { "type": "workflow-start", "title": "开始工作流", "timestamp": "now", "prdPhase": "PRD1" }
-     ```
-
-1. **需求理解确认（关键控制点）：**
-
-   - `requirement-analyzer` 生成 `analysis.md` 后**必须暂停**，等待用户确认对需求的理解是否正确。
-   - 输出提示："📋 需求分析已完成，请确认以下理解是否准确：[分析要点摘要]"
-   - **只有用户明确回复 "✓ 确认理解正确" 或提出修正并确认后，才能继续往下走。**
-   - **禁止跳过此步骤。** 需求理解错误会导致后续所有环节全部偏离，是工程控制论的最大风险点。
-
-   **用户确认后，必须执行：**
-
-   **a) 生成需求摘要（写入 requirement.json）：**
-   - 从 analysis.md 的"业务概述"部分提取需求标题和摘要
-   - 写入 `requirement.json.title` 和 `requirement.json.summary`
-   - 如果是后续 PRD（PRD2、PRD3...），对比现有 summary，判断是否需要更新
-   - 接口文档不影响 summary
-
-   **b) 功能模块识别与认领：**
-   - 从 analysis.md 的"功能模块清单"提取所有模块
-   - 写入 `requirement.json.modules[]`
-   - 输出模块列表，询问用户负责范围：
-     ```
-     📋 需求分析完成，共识别 N 个功能模块：
-       1. 模块名 — 描述
-       2. 模块名 — 描述
-       ...
-     请确认负责范围（回复 all 或输入编号如 1,2）：
-     ```
-   - 用户回复 `all` → 所有模块 assignee 设为当前开发者
-   - 用户输入编号 → 只设置选中的模块 assignee
-   - 模块只有一个时 → 自动分配，不需要询问
-
-   **c) 数据写入：**
-   - 更新 `run.json.context.currentStage` 为 `"requirement-confirmed"`
-   - 更新 `run.json.timeline[]` 添加事件：
-     ```json
-     { "type": "requirement-confirmed", "title": "需求理解已确认", "timestamp": "now", "prdPhase": "PRD1" }
-     ```
-   - 更新 `run.json.workflow[]` 中 "需求分析" 阶段的 `status` 为 `"completed"`，设置 `endTime`
-
-2. **生成任务清单：**
-
-   - 用户确认需求理解无误后，加载上下文 (`run.json.context`)。
-   - 读取 `run.json` 中的 `context` 字段。如果是空或全新的需求，初始化流程起点。
-   - 判断当前 run_id 是否存在并有未完成的任务（检查 `run.json.tasks[]`）。
-   - 如果 `run.json.meta.status === "completed"`：
-     - 检查是否在 Step 0 中发现了**新的 PRD 文档/阶段**。
-     - 如果有新阶段 → status 已在 Step 0c 中改为 `"running"`，继续执行。
-     - 如果没有新内容 → 提示工作流已闭环结束，询问用户是否有新的 PRD 文档需要处理。
-   - 当 `analysis.md` 存在但 `run.json.tasks[]` 为空或当前 PRD 阶段无任务时，调用 `task-splitter`，将生成的任务写入 `run.json.tasks[]`。
-   - **task-splitter 只为当前开发者认领的模块拆分任务**（从 requirement.json.modules 读取 assignee）。
-   - 任务拆分完成后**可以**暂停让用户核查（可选，优先级低于需求确认），也可以直接进入执行循环。
-
-   **必须执行的数据写入（任务拆分完成后）：**
-   - 更新 `run.json.timeline[]` 添加事件：
-     ```json
-     { "type": "tasks-generated", "title": "任务清单已生成", "timestamp": "now", "prdPhase": "PRD1" }
-     ```
-   - 更新 `run.json.workflow[]` 添加新阶段：
-     ```json
-     { "stage": "任务拆分", "prdPhase": "PRD1", "status": "completed", "startTime": "...", "endTime": "now" }
-     ```
-
-3. **核心执行循环 (代码生成 + 质量自检)：**
-
-   - 一旦任务被确认，开始循环执行：
-     - **Step A:** 触发 `code-generator`，先调用 `aida_task_start` MCP 工具记录开始时间，再读取 `run.json.tasks[]` 开始编写该任务。
-     - **Step B:** `code-generator` 完成后调用 `aida_log_files` 记录文件变更，再调用 `aida_task_done` 标记任务完成。
-     - **Step C:** 立即触发 `self-reviewer` 进行质量查验。
-     - **Step D:**
-       - 如查验**未通过**：触发 `bug-fixer` 根据 review 结果进行专项修复代码，然后回到 Step C。
-       - 如查验**通过**：调用 `aida_log_review` 记录审查结果。
-       - 如人工指定需高阶审计：转 `mcp-reviewer`（脱离主循环）。
-
-4. **保存进度与状态更新：**
-
-   每完成上述一个子任务循环，必须更新以下数据（由 `code-generator` 和 `self-reviewer` 通过 CLI 命令自动完成）：
-   - `run.json.context.currentTaskId` 记录当前任务ID
-   - `run.json.summary` 中的统计数据（由 CLI 自动更新）
-   - `run.json.timeline[]` 添加事件（由 CLI 自动更新）
-   - 循环往复直到 `run.json.tasks[]` 中的所有任务都被标记完成。
-
-5. **结束流程：**
-
-   当该需求的所有任务完成，**必须执行以下操作：**
-
-   **a) 数据写入：**
-   - 更新 `run.json.meta.status` 为 `"completed"`
-   - 更新 `run.json.meta.endTime` 为当前时间
-   - 更新 `run.json.workflow[]` 中所有阶段的 `status` 为 `"completed"`，设置各自的 `endTime`
-   - 更新 `run.json.context.currentStage` 为 `"completed"`
-   - 更新 `run.json.timeline[]` 添加最终事件：
-     ```json
-     { "type": "workflow-completed", "title": "工作流完成", "timestamp": "now", "prdPhase": "PRD1" }
-     ```
-   - 更新 `run.json.metrics` 计算最终统计指标（aiDeviationRate、bugRate、reviewPassRate 等）
-
-   **b) 自动生成 highlights 草稿：**
-   - 从任务列表和 PRD 摘要中推断业务价值亮点
-   - 输出草稿并提示用户：
-     ```
-     自动生成的亮点：
-       1. [从任务/PRD 推断的亮点]
-       2. [从任务/PRD 推断的亮点]
-     请补充业务价值数据（如性能指标、成本节省等），输入 ok 跳过：
-     ```
-   - 用户补充或确认后，调用 `aida_highlight` MCP 工具，传入 `content` 和 `source: "auto"` 写入
-   - 用户手动补充的调用 `aida_highlight`，传入 `content` 和 `source: "manual"` 写入
-
-## 关于中断恢复
-
-如果在循环中的任意一步被用户强行终止或因外界因素打断，下次呼叫 workflow-orchestrator 时，必须依据 `run.json.context`（currentTaskId, currentStage）与 `run.json.tasks[]` 中各任务的 status，从被打断的任务直接无缝续拍。
-
-## run.json 关键字段说明
-
-- **执行状态**：`run.json.context`（currentStage, currentTaskId, currentPrdPhase）
-- **开发工单**：`run.json.tasks[]`（每个任务含 taskId, title, status, stageName, startedAt, completedAt）
-- **Bug 记录**：`run.json.bugs[]`（通过 `aida_log_bug` / `aida_bug_fix` MCP 工具写入）
-- **质量自检**：`run.json.reviews[]`（通过 `aida_log_review` MCP 工具写入）
-- **偏差记录**：`run.json.deviations[]`（通过 `aida_log_deviation` MCP 工具写入，用户手动触发）
-- **规则沉淀**：`run.json.rules[]`（通过 `aida_log_rule` MCP 工具写入）
-- **工作流阶段**：`run.json.workflow[]`（记录各阶段执行状态和耗时）
-- **时间线**：`run.json.timeline[]`（记录关键事件时间点）
-- **文件变更**：`run.json.files[]`（记录修改过的文件路径和统计）
-- **汇总指标**：`run.json.summary` + `run.json.metrics`（含 nodeTimeBreakdown、actualWorkSeconds、efficiencyMultiplier）
-- **成本数据**：`run.json.cost`（token 消耗、预估工时、实际工时）
-- **业务亮点**：`run.json.highlights[]`（业务价值记录）
-
-## 偏差记录
-
-当一轮工作流闭环完成后，用户在测试验证阶段反馈的细节修正（与 AI 初始生成代码的偏差），通过 deviation-recorder 记录到 `run.json.deviations[]`。
-
-与 Bug 记录的区别：
-- `run.json.bugs[]`：测试阶段发现的功能 Bug，由 bug-fixer 记录
-- `run.json.deviations[]`：AI 产出与用户期望的设计偏差，由 deviation-recorder 记录
-
-两者均用于后续数据分析，驱动规则和 Skill 的持续优化。