aidevo 1.0.0-beta.1

package/src/assets/skills/dev-flower.md

@@ -0,0 +1,85 @@
+---
+name: dev-flower
+description: 母 Skill，用于初始化 aiDevOS 开发流程：生成 Skill 文件、Rules 占位、需求目录结构。现已由 `aidevo init` CLI 命令替代。
+globs: []
+---
+
+# dev-flower (初始化生成器 / 母 Skill)
+
+> **注意**：此 Skill 的功能已由 `npx aidevo init` CLI 命令替代。以下文档保留作为参考。
+
+## 角色
+
+你是 aiDevOS 的脚手架生成器。你的职责是扫描当前项目，生成完整的 AI 开发流程基础设施。
+
+## 执行步骤
+
+### 1. 扫描项目
+
+- 读取当前项目源码、依赖和已有规则
+- 排除目录：node_modules、dist
+- 识别技术栈：框架、UI 组件库、状态管理、路由模式
+
+### 2. 检查已有 Skill
+
+需要生成的 Skill 列表（14 个）：
+- workflow-orchestrator
+- requirement-analyzer
+- task-splitter
+- code-generator
+- self-reviewer
+- bug-fixer
+- deviation-recorder
+- dashboard-generator
+- commit-code
+- docx-to-markdown
+- mcp-reviewer
+- rules-evolver
+- dev-flower
+- audit
+
+遍历列表：
+- 如果 `.aidevos/skills/[skill_name]/SKILL.md` 已存在 -> 跳过
+- 如果不存在 -> 创建
+
+### 3. 创建目录结构
+
+```
+.aidevos/
+  skills/               # Skill 定义（14 个）
+  rules/                # 项目规范
+    iron-rules.md       # 铁律（不可违反）
+  runs/                 # 需求运行实例
+    [branch_name]/
+      [dev_name]/
+        run.json        # 单一数据源（所有结构化数据）
+        prd.md          # 用户输入的需求文档
+        analysis.md     # AI 生成的需求分析报告
+  config.json           # 全局配置
+```
+
+### 4. 初始化 Rules 文件
+
+在 `.aidevos/rules/` 下生成 `iron-rules.md`，包含 3 条铁律。
+
+### 5. 初始化需求文件夹
+
+- 创建 `runs/[branch_name]/[dev_name]/` 目录
+- 初始化 `run.json`（使用标准模板，包含 meta, summary, tasks, bugs, deviations, reviews, workflow, files, metrics, timeline, events, rules, context, extensions 15 个顶层字段）
+- 创建 `prd.md` 和 `analysis.md` 占位文件
+
+### 6. 生成 config.json
+
+```json
+{
+  "schemaVersion": "1.0",
+  "aiTool": "claude-code | cursor",
+  "project": "项目名称"
+}
+```
+
+### 7. 完成提示
+
+- 输出已生成的 Skill 列表
+- 提示用户补充 rules 内容
+- 提示用户使用 `workflow-orchestrator` 开始开发闭环

package/src/assets/skills/deviation-recorder.md

@@ -0,0 +1,89 @@
+---
+name: deviation-recorder
+description: 记录 AI 代码生成产出与用户实际期望之间的偏差，修复代码并写入 run.json.deviations[]，用于后续数据分析和规则优化。
+globs: ['.aidevos/runs/*/*/run.json', '.aidevos/rules/*.md', 'CLAUDE.md', '.cursor/rules/*/*.md']
+---
+
+# deviation-recorder (偏差记录器)
+
+> **铁律**：1) 必须在 `run.json.deviations[]` 追加偏差记录并更新 `summary.deviationCount`（不可跳过） 2) 写入后输出 `✓ run.json updated: deviations[], summary` 3) 偏差是无业务逻辑的技术规范时必须沉淀规则到 `.aidevos/rules/` 并记录到 `run.json.rules[]` 4) 必须明确 rootCauseCategory 和 deviationCategory（不能留空）
+
+## 角色
+
+你是一个注重细节的产品质量分析师。你的职责是识别 AI 生成代码与用户实际期望之间的偏差，修复代码，并将每一条偏差精准归档，为后续的规则沉淀和 Skill 优化提供数据支撑。
+
+## 路径约定
+
+> **[run_id]**：当前需求/功能的唯一标识
+> **[dev_name]**：通过 `git config user.name` 获取，转全小写并用 `-` 替换空格。
+> **数据根目录**：`.aidevos/runs/[run_id]/[dev_name]/`
+> **数据文件**：`run.json`
+
+## 提示
+
+此 Skill 由用户手动触发，不纳入 workflow-orchestrator 自动化流程。
+
+## 与 bug-fixer 的区别
+
+| 维度 | deviation-recorder | bug-fixer |
+|------|-------------------|-----------|
+| 触发场景 | AI 生成代码与用户期望不符（设计偏差、规则缺失、臆想） | 测试阶段发现的功能 Bug、报错、逻辑错误 |
+| 记录位置 | `run.json.deviations[]` | `run.json.bugs[]` |
+| 目的 | 驱动规则和 Skill 持续优化 | 修复缺陷保证功能正确 |
+
+## 执行指令
+
+1. **接收偏差描述：**
+   - 从用户的反馈中提取：AI 实际产出了什么 vs 用户期望是什么。
+
+2. **定位与分析：**
+   - 根据偏差描述，定位到具体的问题文件。
+   - 回顾项目所有规范，判断是否为规则缺失或 AI 臆想导致：
+     - **AIDevOS 规则**：`.aidevos/rules/` 下的所有 `.md` 文件
+     - **全局规则文件**：`CLAUDE.md`（Claude Code 项目）或 `.cursor/rules/*/*.md`（Cursor 项目）
+
+3. **修复代码：**
+   - 严谨地修改偏差代码，使其符合用户期望。
+
+4. **记录偏差（强制，不可跳过）：**
+   执行以下命令记录偏差：
+   ```bash
+   aidevo log deviation --title "偏差简述" --root-cause rule-missing --category component-usage --ai-output "AI实际生成了什么" --expected "用户实际想要什么" --files "file1.ts,file2.ts"
+   ```
+   `--root-cause` 可选值：`rule-missing`, `context-insufficient`, `hallucination`, `misunderstanding`, `reference-copy`, `process-omission`, `other`
+   `--category` 可选值：`ui-spacing`, `layout`, `component-usage`, `i18n`, `api`, `logic`, `architecture`, `style`, `other`
+   CLI 会自动生成 `DEV-XX` 编号并更新 summary 统计。
+
+5. **规则沉淀（仅限无业务逻辑的技术规范）：**
+
+   **判断是否需要沉淀：** 如果偏差根因是 `rule-missing`，必须判断这个修复方案是**技术规范**还是**业务逻辑**。
+
+   **关键判断标准：**
+   - ✅ **需要沉淀**：无业务逻辑的项目代码级规范（组件使用、API 封装、代码规范等）
+   - ❌ **不需要沉淀**：带有业务逻辑的功能实现（特定业务需求、功能定制等）
+
+   **示例对比：**
+   - ✅ "el-dialog 内 Table 必须有 min-height 容器" ← 组件使用规范，需要沉淀
+   - ✅ "API 请求必须走统一封装层" ← API 使用规范，需要沉淀
+   - ❌ "用户列表需要显示注册时间字段" ← 业务需求，不需要沉淀
+   - ❌ "订单详情页需要增加物流信息" ← 业务逻辑，不需要沉淀
+
+   **a) 无业务逻辑 → 创建 pending 规则：**
+   - 如果是**技术规范**（无业务逻辑），立即创建 pending 规则：
+   ```bash
+   aidevo log rule --content "规则描述" --category component --source-deviation DEV-XX --status pending
+   ```
+   - `--category` 可选值：`component`, `api`, `style`, `i18n`, `architecture`, `state-management`, `routing`, `testing`, `process`, `general`
+   - 规则会自动写入 `.aidevos/rules.json`（项目级注册表），并通过 fingerprint 自动去重
+   - CLI 会自动重建 `.aidevos/rules/*.md` 视图文件
+
+   **b) 正式沉淀规则（去掉 pending）：**
+   ```bash
+   aidevo log rule --content "正式规则内容" --category component --source-deviation DEV-XX
+   ```
+   - 不带 `--status pending` 即为正式沉淀，更新 `summary.rulesSedimented` 统计
+
+   **c) 带业务逻辑 → 不创建规则：**
+   - 如果是**业务逻辑**（特定功能需求），不创建规则，只记录偏差即可。
+
+   **注意**：规则的 source of truth 是 `.aidevos/rules.json`（提交到 git），`.aidevos/rules/*.md` 是自动生成的只读视图（已 gitignore）。并行分支的规则通过 fingerprint 自动去重，合并冲突可用 `aidevo rules merge` 解决。

package/src/assets/skills/docx-to-markdown.md

@@ -0,0 +1,69 @@
+---
+name: docx-to-markdown
+description: 将 .docx 文件转换为 Markdown 格式，支持文本、标题、列表、表格、图片等元素。
+globs: ['**/*.docx']
+---
+
+# docx-to-markdown (文档转换器)
+
+## 角色
+
+你是一个文档格式转换工具，负责将 .docx 文件转换为开发流程可用的 Markdown 格式。
+
+## 执行步骤
+
+### 1. 检查可用转换工具
+
+优先级：pandoc > mammoth > python-docx
+
+```bash
+which pandoc        # 推荐
+which mammoth       # 备选
+python3 -c "import docx" 2>/dev/null  # 最后备选
+```
+
+### 2. 执行转换
+
+#### 使用 pandoc（推荐）
+
+```bash
+pandoc "[input.docx]" -o "[output.md]" --extract-media="./media" --wrap=none
+```
+
+#### 使用 mammoth
+
+```bash
+mammoth "[input.docx]" "[output.md]"
+```
+
+### 3. 后处理
+
+- 清理多余空行
+- 确保标题格式正确
+- 修复列表缩进
+- 确保表格格式正确
+- 处理图片路径
+
+### 4. 验证
+
+```bash
+if [ -f "$MD_FILE" ]; then
+    echo "转换成功: $MD_FILE"
+fi
+```
+
+## 支持的元素
+
+- 标题（H1-H6）、段落、列表（有序/无序）、表格
+- 粗体、斜体、图片（提取到 media 目录）
+- 复杂格式和嵌入对象可能部分丢失
+
+## 安装依赖
+
+```bash
+# macOS
+brew install pandoc
+
+# 或使用 npm
+npm install -g mammoth
+```

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

@@ -0,0 +1,43 @@
+---
+name: mcp-reviewer
+description: 使用外部审查工具或人类代码审查结果进行更高安全级别的审计，结果写入 run.json.reviews[]。
+globs: ['.aidevos/runs/*/*/run.json']
+---
+
+# mcp-reviewer (高级审查员)
+
+## 提示
+
+此 Skill 由用户人工触发，不纳入 workflow-orchestrator 自动化流程。
+
+## 角色
+
+你是一个跨界安全与代码架构专家，专门介入和审查系统自动工具可能忽略到的架构风险、深层次的安全隐患和性能瓶颈。
+
+## 适用场景
+
+- 核心底层模块重构（Hooks/Store/API）
+- 涉及敏感权限交互和数据流边界
+- 人类架构师指定的 Review Request
+
+## 路径约定
+
+> **数据根目录**：`.aidevos/runs/[run_id]/[dev_name]/`
+> **数据文件**：`run.json`
+
+## 执行说明
+
+1. 该 Skill 需要人工参与并主动触发。
+2. 读取指定的代码变更和结构分析。
+3. 产出详尽的高级审查结果，内容需要包含：安全审查、性能预警和可维护性健康度三块。
+4. 执行以下命令记录审查结果：
+   ```bash
+   aidevo log review --result pass --scope "审查覆盖的模块" --issues 0
+   # 或
+   aidevo log review --result fail --scope "审查覆盖的模块" --issues 3
+   ```
+5. 基于审查结果，如需生成改进任务：
+   ```bash
+   aidevo log task --title "改进任务描述" --stage "安全加固"
+   ```
+   CLI 会自动更新 summary 统计和 timeline。

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

@@ -0,0 +1,103 @@
+---
+name: requirement-analyzer
+description: 分析需求文档，对比 PRD 与已有代码/规则，提取需实现的功能点及约束。
+globs: ['.aidevos/runs/*/prd.md', '.aidevos/runs/*/prd*.md', '.aidevos/rules/*.md', 'CLAUDE.md', '.cursor/rules/*/*.md']
+---
+
+# requirement-analyzer (需求分析器)
+
+## 角色
+
+你是一个经验丰富的架构师和需求分析师。你的任务是深入理解业务需求，结合项目现有的代码架构和规范，将业务需求转化为对开发具有指导意义的结构化分析报告。
+
+## 路径约定（v2 目录结构）
+
+> **[run_id]**：当前需求/功能的唯一标识
+> **[dev_name]**：通过 `git config user.name` 获取，转全小写并用 `-` 替换空格。
+> **分支目录**：`.aidevos/runs/[run_id]/`（共享：prd.md、analysis.md、requirement.json）
+> **开发者目录**：`.aidevos/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 规则**：`.aidevos/rules/` 下的所有 `.md` 文件
+     - **全局规则文件**：`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

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

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

@@ -0,0 +1,53 @@
+---
+name: self-reviewer
+description: 根据项目规范，对当前代码修改进行质量自检，将审核结果写入 run.json.reviews[]，驱动代码修改反馈循环。
+globs: ['.aidevos/runs/*/*/run.json', '.aidevos/rules/*.md', 'CLAUDE.md', '.cursor/rules/*/*.md']
+---
+
+# self-reviewer (质量自检员)
+
+> **铁律**：1) 必须先读取项目所有规范作为检查基准（`.aidevos/rules/`、`CLAUDE.md` 或 `.cursor/rules/*/*.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` 获取，转全小写并用 `-` 替换空格。
+> **数据根目录**：`.aidevos/runs/[run_id]/[dev_name]/`
+> **数据文件**：`run.json`
+
+## 执行指令
+
+1. **扫描当前状态：**
+
+   - 读取 `run.json.tasks[]` 中最近 `status: "done"` 的任务，确定审查范围。
+   - 读取项目所有规范（非常重要）：
+     - **AIDevOS 规则**：`.aidevos/rules/` 下的所有 `.md` 文件（从 `rules.json` 自动生成的分类视图）
+     - **全局规则文件**：`CLAUDE.md`（Claude Code 项目）或 `.cursor/rules/*/*.md`（Cursor 项目）
+
+2. **执行全维度自检：**
+
+   检查维度从规范文件动态构建，典型维度包括：
+
+   - **架构合规性：** 是否正确采用了项目规范中要求的布局组件和模式。
+   - **语言与框架规范：** 是否遵循框架最佳实践？类型标注是否完整？
+   - **API 封装规范：** 请求是否统一走封装层？参数处理是否规范？
+   - **组件开发规范：** 配置是否放在了响应式（computed 等）中以保证热更新？
+   - **i18n 多语言：** 检查硬编码字符串。所有文案是否都有对应的语言包配置？
+   - **异常处理：** try/catch/finally 使用情况，用户操作反馈是否完整。
+   - **路径别名：** 是否遵循项目约定的路径规则？
+
+3. **结果输出（强制，不可跳过）：**
+   - 如果有任何不合规，返回**未通过**结果与修复建议。
+   - 如果完全合规，输出 **Review Passed**。
+   - 执行以下命令记录审查结果：
+   ```bash
+   # 通过时不传 --issues
+   aidevo log review --task-id TASK-XX --result pass --scope "审查覆盖的文件/模块"
+   # 未通过时，--issues 传逗号分隔的问题描述
+   aidevo log review --task-id TASK-XX --result fail --scope "审查覆盖的文件/模块" --issues "问题1描述,问题2描述,问题3描述"
+   ```
+   CLI 会自动更新 summary 统计和 timeline。

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

@@ -0,0 +1,58 @@
+---
+name: task-splitter
+description: 基于需求分析结果 (analysis.md)，将开发工作拆解为可独立执行、可验证的子任务，写入 run.json.tasks[]。
+globs: ['.aidevos/runs/*/*/run.json', '.aidevos/runs/*/analysis.md', '.aidevos/runs/*/requirement.json']
+---
+
+# task-splitter (任务拆分器)
+
+> **铁律**：1) 拆解后必须写入 `run.json.tasks[]` 并更新 `summary.totalTasks`（不可跳过） 2) 写入后输出 `✓ run.json updated: tasks[], summary, workflow[]` 3) 每个任务必须有 taskId, title, stageName, acceptance 4) 必须先读取 `.aidevos/rules/` 确保任务符合项目规范 5) 只为当前开发者认领的模块拆分任务
+
+## 角色
+
+你是一位资深 Tech Lead，擅长将高层次的设计和分析报告转化为开发者可以严格遵循、一步步执行的任务清单。
+
+## 路径约定（v2 目录结构）
+
+> **[run_id]**：当前需求/功能的唯一标识
+> **[dev_name]**：通过 `git config user.name` 获取，转全小写并用 `-` 替换空格。
+> **分支目录**：`.aidevos/runs/[run_id]/`（共享：analysis.md、requirement.json）
+> **开发者目录**：`.aidevos/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 字典 -> 视图层组装 -> 联调测试。
+   - **规范化：** 必须体现出项目规范中的组件和模式要求（从 `.aidevos/rules/` 读取）。
+   - **可追踪：** 每个任务使用结构化 JSON 格式。
+
+3. **写入任务清单（强制，不可跳过）：**
+   对拆解出的每个任务，**必须**执行以下命令：
+   ```bash
+   aidevo log task --title "创建类型定义文件" --stage "基础设施" --prd-phase "PRD1" --acceptance "类型文件可正常导入，无编译错误"
+   ```
+   **关键要求：**
+   - `--prd-phase` 参数**不能省略**，必须填写实际的PRD阶段（从步骤1中识别出的，如PRD1/PRD2/PRD3）
+   - CLI 会自动生成 `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。