@zeyue0329/xiaoma-cli 1.12.0 → 1.15.0

package/demo/xiaoma-bug-resolve/workflow.md

@@ -1,269 +0,0 @@
-# Bug Resolve Workflow
-
-**Goal:** 从 AI 测试平台推送的缺陷中，按时间正序取出第一条待处理 Bug，分析是否为真实缺陷，修复并验证，最后更新缺陷状态。
-
-**Your Role:** 你是一名全栈开发工程师，负责分析、修复和验证 AI 测试平台推送的缺陷。你需要精确定位问题根因，编写高质量修复代码，并通过测试验证修复效果。
-
-**所有输出使用简体中文。**
-
----
-
-## 参数说明
-
-本 skill 支持以下可选参数（通过调用时传入或交互式获取）：
-
-| 参数 | 说明 | 示例 |
-|------|------|------|
-| `testUrl` | Playwright 测试用的前端页面基础地址 | `http://localhost:8080/zqyl_manager` |
-| `authToken` | 登录认证 token（Bearer token） | `eyJhbGciOiJI...` |
-| `defectId` | 指定处理的缺陷ID（不传则自动取时间最早的待处理缺陷） | `DEF0158` |
-
-如果用户未提供 `testUrl` 和 `authToken`，在需要 Playwright 测试时主动向用户索要。
-
----
-
-## 数据库信息
-
-### MySQL 缺陷库（xiaoma-dev-mysql）
-
-**缺陷表：`t_defect_info`**
-
-| 字段 | 类型 | 说明 |
-|------|------|------|
-| id | bigint | 主键 |
-| defect_id | varchar(64) | 缺陷唯一标识 |
-| run_id | varchar(64) | 关联运行ID |
-| jira_id | varchar(64) | JIRA项目ID |
-| title | varchar(512) | 缺陷描述 |
-| module_path | varchar(256) | 所属模块 |
-| severity | tinyint | 严重等级：1紧急, 2高, 3中, 4低 |
-| defect_type | varchar(32) | 缺陷类型：前端, 后端 |
-| steps | text | 重现步骤 |
-| case_no | varchar(64) | 关联用例编号 |
-| case_name | varchar(256) | 关联用例名称 |
-| error_front | text | 前端错误日志 |
-| url | varchar(1024) | 页面URL |
-| error_apis | text | 接口报错信息 |
-| discover_time | datetime | 缺陷发现时间 |
-| defect_status | tinyint | **状态：0新增, 1已验证, 2已修复, 3非缺陷（测试误报）** |
-| is_del | tinyint | 删除标记：0未删除, 1已删除 |
-
----
-
-## WORKFLOW
-
-<workflow>
-
-<step n="1" goal="查询待处理缺陷并获取第一条Bug详情">
-
-  <action>使用 `mcp__xiaoma-dev-mysql__mysql_query` 工具查询所有待处理缺陷概要：
-  ```sql
-  SELECT id, defect_id, title, defect_status, severity, defect_type, module_path, discover_time, create_time
-  FROM t_defect_info
-  WHERE is_del = 0 AND defect_status = 0
-  ORDER BY create_time ASC;
-  ```
-  </action>
-
-  <check if="有指定 defectId 参数">
-    <action>按指定 defectId 查询缺陷详情</action>
-  </check>
-  <check if="未指定 defectId">
-    <action>取查询结果中时间最早（第一条）的缺陷</action>
-  </check>
-
-  <action>查询该缺陷的完整详情：
-  ```sql
-  SELECT * FROM t_defect_info WHERE defect_id = '{{target_defect_id}}' AND is_del = 0;
-  ```
-  </action>
-
-  <action>输出缺陷摘要信息：
-  - 缺陷ID、标题、严重度、类型
-  - 模块路径、页面URL
-  - 重现步骤（steps字段完整展示）
-  - 前端错误日志（error_front，如有）
-  - 接口报错信息（error_apis，如有）
-  </action>
-
-  <check if="没有待处理缺陷">
-    <action>告知用户当前没有待处理的缺陷，流程结束</action>
-  </check>
-
-</step>
-
-<step n="2" goal="分析缺陷根因">
-
-  <action>根据缺陷信息确定需要探索的代码区域：
-  - 根据 `module_path` 确定业务模块
-  - 根据 `url` 确定前端页面路径
-  - 根据 `defect_type` 确定前端/后端
-  - 根据 `error_apis` 确定相关API接口
-  </action>
-
-  <action>使用 Explore Agent 并行探索相关代码：
-  1. **前端代码**：找到页面组件、搜索表单配置、API调用方式
-  2. **后端代码**：找到 Controller → Application Service → Mapper，定位SQL/业务逻辑
-  3. **数据库**：通过 Oracle MCP Server 验证数据和SQL逻辑
-  </action>
-
-  <action>综合分析后得出结论，分为三种情况：
-  - **真实缺陷**：代码确实存在问题，需要修复
-  - **测试误报（非缺陷）**：代码逻辑正确，测试用例本身有误或测试数据问题
-  - **需要更多信息**：无法确定，需要向用户确认
-  </action>
-
-  <action>向用户展示分析结论，包括：
-  - 根因说明（哪个文件、哪一行、什么问题）
-  - 判定结果（真实缺陷 / 测试误报）
-  - 如为真实缺陷，展示修复方案
-  </action>
-
-</step>
-
-<step n="3" goal="修复缺陷（仅真实缺陷执行此步骤）">
-
-  <check if="判定为测试误报">
-    <action>跳过此步骤，直接进入 Step 5 更新状态</action>
-  </check>
-
-  <action>按照分析结果执行代码修复：
-  - 使用 Edit 工具修改相关文件
-  - 修复范围严格限定在缺陷涉及的代码，不做额外重构
-  - 遵循项目 CLAUDE.md 中的编码规范
-  </action>
-
-  <action>列出所有修改的文件和修改内容摘要</action>
-
-</step>
-
-<step n="4" goal="验证修复结果">
-
-  <action>根据缺陷类型选择验证方式：</action>
-
-  <!-- 数据库层验证（优先执行） -->
-  <action>如涉及SQL/查询逻辑变更：
-  - 通过 Oracle MCP Server 直接执行修复后的SQL逻辑
-  - 验证查询结果是否符合预期
-  - 记录验证结果
-  </action>
-
-  <!-- Playwright 页面验证（如需） -->
-  <check if="缺陷涉及页面交互且用户提供了 testUrl">
-    <action>使用 Playwright 工具进行端到端验证：
-    1. 导航到目标页面（使用 testUrl）
-    2. 如需登录，使用 authToken 注入认证信息
-    3. 按照缺陷的重现步骤操作
-    4. 验证结果是否符合预期
-    </action>
-  </check>
-
-  <check if="缺陷涉及页面交互但未提供 testUrl 或 authToken">
-    <action>向用户索要 Playwright 测试所需信息：
-    - 测试环境前端地址（testUrl）
-    - 登录认证 token（authToken）
-    提示用户：请提供测试地址和登录token，格式如：
-    `testUrl=http://localhost:8080/zqyl_manager authToken=eyJhbGci...`
-    </action>
-  </check>
-
-  <check if="本地无法构建/部署后端">
-    <action>说明已通过数据库SQL直接验证修复逻辑正确性，
-    端到端验证需等后端部署到测试环境后执行</action>
-  </check>
-
-  <action>输出验证结果摘要</action>
-
-</step>
-
-<step n="5" goal="更新缺陷状态">
-
-  <check if="真实缺陷且已修复验证通过">
-    <action>更新缺陷状态为已修复（defect_status = 2）：
-    ```sql
-    UPDATE t_defect_info SET defect_status = 2 WHERE defect_id = '{{target_defect_id}}' AND is_del = 0;
-    ```
-    </action>
-  </check>
-
-  <check if="判定为测试误报">
-    <action>更新缺陷状态为非缺陷（defect_status = 3）：
-    ```sql
-    UPDATE t_defect_info SET defect_status = 3 WHERE defect_id = '{{target_defect_id}}' AND is_del = 0;
-    ```
-    </action>
-  </check>
-
-  <action>验证状态更新成功：
-  ```sql
-  SELECT defect_id, title, defect_status FROM t_defect_info WHERE defect_id = '{{target_defect_id}}';
-  ```
-  </action>
-
-  <action>输出最终处理结果：
-
-  **处理完成**
-
-  | 项目 | 内容 |
-  |------|------|
-  | 缺陷ID | {{defect_id}} |
-  | 缺陷标题 | {{title}} |
-  | 判定结果 | 真实缺陷 / 测试误报 |
-  | 处理方式 | 已修复代码 / 标记为非缺陷 |
-  | 状态更新 | defect_status → 2(已修复) / 3(非缺陷) |
-  | 修改文件 | {{modified_files_list}} |
-  | 验证结果 | 通过 / 待部署后验证 |
-
-  </action>
-
-  <!-- 检查是否还有更多待处理缺陷 -->
-  <action>查询剩余待处理缺陷数量：
-  ```sql
-  SELECT COUNT(*) as remaining FROM t_defect_info WHERE is_del = 0 AND defect_status = 0;
-  ```
-  告知用户剩余待处理缺陷数量，询问是否继续处理下一条。
-  </action>
-
-</step>
-
-</workflow>
-
----
-
-## 项目特定信息
-
-### 代码结构映射
-
-根据缺陷的 `module_path` 和 `url` 定位代码位置：
-
-| 模块关键字 | 前端页面路径 | 后端Controller | Mapper XML |
-|-----------|-------------|---------------|------------|
-| 签发业务归属表 | `views/pjs/incentive/issueAttribution/` | `IssueAttributionController` | `IssueAttributionMapper.xml` |
-| 背书业务归属表 | `views/pjs/incentive/endorseAttribution/` | `EndorseAttributionController` | `EndorseAttributionMapper.xml` |
-| 融资台账 | `views/pjs/incentive/financeLedger/` | `FinanceLedgerController` | `FinanceLedgerMapper.xml` |
-| 费用方案 | `views/pjs/incentive/feePlan/` | `FeePlanController` | `FeePlanMapper.xml` |
-
-### 常见缺陷模式
-
-| 缺陷描述关键字 | 可能根因 | 修复方向 |
-|--------------|---------|---------|
-| 模糊查询不符合预期 | SQL使用 `=` 而非 `LIKE` | 改为 `LIKE '%' \|\| #{param} \|\| '%'` |
-| 字段未显示/缺少列 | 前端表头配置缺少字段 | 在 ylTableData.header 中添加列定义 |
-| 字段值展示错误 | 前端取值prop映射错误或后端SQL字段别名错误 | 修正prop或SQL alias |
-| 查询不出数据 | 查询条件逻辑错误（AND/OR）、字段映射错误 | 修正SQL条件逻辑 |
-| 表头名称错误 | 前端 header label 配置错误 | 修改 header 中对应列的 label |
-| 点击按钮报错 | 接口调用参数错误或后端接口异常 | 检查前端调用和后端接口 |
-
-### 数据库连接
-
-- **MySQL（缺陷库）**：使用 `mcp__xiaoma-dev-mysql__mysql_query` 工具
-- **Oracle（业务库）**：使用 `mcp__oracle_zqyl_pj_incentive_test4__execute_query` 工具
-
-### 状态码枚举
-
-| defect_status | 含义 | 场景 |
-|--------------|------|------|
-| 0 | 新增 | AI测试平台推送的初始状态 |
-| 1 | 已验证 | 人工确认为真实缺陷 |
-| 2 | 已修复 | 代码已修复并验证通过 |
-| 3 | 非缺陷 | 测试误报，非真实缺陷 |

package/docs/roadshow/01-/351/241/271/347/233/256/346/246/202/350/247/210/344/270/216/346/236/266/346/236/204.md

@@ -1,189 +0,0 @@
-# XiaoMa-CLI 项目概览与架构
-
-## 1. 项目定位与价值主张
-
-XiaoMa-CLI (`@zeyue0329/xiaoma-cli`) 是一个 AI 驱动的敏捷开发框架/CLI 工具。它将专业化的 AI 智能体角色、工作流和技能安装到用户的项目目录中，与 AI IDE（Claude Code、Cursor 等）协同工作。
-
-**核心价值：**
-
-- 将软件开发全生命周期（需求 → 设计 → 架构 → 开发 → 测试 → 交付）全面 AI 化
-- 9 个专业智能体协同，模拟真实敏捷团队
-- 26 个结构化工作流覆盖开发全阶段
-- 支持 25+ 主流 AI IDE 平台
-- 一键安装，即插即用
-
----
-
-## 2. 整体架构
-
-XiaoMa-CLI 采用**两层架构**设计，将内容与工具彻底分离，确保高扩展性和可维护性。
-
-```mermaid
-graph TB
-    subgraph ContentLayer["内容层 (src/)"]
-        subgraph CoreModule["Core 模块"]
-            CS["核心技能<br/>12个"]
-            CT["核心任务<br/>创建PRD等"]
-        end
-        subgraph XMCModule["XMC 模块 - 小马敏捷方法"]
-            AG["智能体<br/>9个"]
-            WF["工作流<br/>26个"]
-            TM["团队定义"]
-        end
-    end
-
-    subgraph ToolLayer["工具层 (tools/)"]
-        subgraph CLITools["CLI 命令行工具"]
-            CMD["命令系统<br/>install / status / uninstall"]
-            INS["安装器<br/>模块管理 / 配置收集 / 清单生成"]
-            IDE["IDE 管理器<br/>25+ 平台适配"]
-        end
-        SCH["Schema 验证<br/>Zod"]
-        FLT["代码扁平化工具"]
-    end
-
-    CS --> CMD
-    CT --> CMD
-    AG --> CMD
-    WF --> CMD
-    AG --> SCH
-    CMD --> IDE
-    INS --> IDE
-```
-
-**架构要点：**
-
-- **内容层**负责定义"做什么"——智能体的角色、工作流的步骤、技能的能力
-- **工具层**负责实现"怎么做"——CLI 交互、文件安装、Schema 校验、IDE 适配
-- 两层通过模块系统（`module.yaml`）连接，支持独立扩展
-
----
-
-## 3. 模块系统
-
-模块是 XiaoMa-CLI 的核心组织单元，每个模块通过 `module.yaml` 定义配置变量、提示语和目录声明。
-
-### Core 模块 (src/core/)
-
-- **模块代码：** `core`
-- **职责：** 提供基础技能和通用任务
-- **配置收集：** 用户名称、沟通语言、文档输出语言、输出目录
-- **12 个核心技能：** brainstorming、distillator、party-mode、editorial-review 等
-
-### XMC 模块 (src/xmc/) — 小马敏捷方法
-
-- **模块代码：** `xmc`
-- **职责：** 提供完整的敏捷开发智能体和工作流
-- **配置收集：** 项目名称、用户技能等级、规划产物路径、实施产物路径
-- **自动创建目录结构：** `planning_artifacts`、`implementation_artifacts`、`project_knowledge`
-
----
-
-## 4. CLI 安装流程
-
-以下时序图展示了用户执行 `npx xiaoma-cli install` 时的完整安装流程：
-
-```mermaid
-sequenceDiagram
-    participant U as 用户
-    participant CLI as xiaoma-cli
-    participant DET as 安装检测器
-    participant CFG as 配置收集器
-    participant MOD as 模块管理器
-    participant MAN as 清单生成器
-    participant IDE as IDE管理器
-
-    U->>CLI: npx xiaoma-cli install
-    CLI->>DET: 检测已有安装
-    DET-->>CLI: 安装状态
-    CLI->>CFG: 收集用户配置
-    CFG->>U: 交互式提问（项目名/语言/路径等）
-    U-->>CFG: 配置回答
-    CFG-->>CLI: 配置数据
-    CLI->>MOD: 安装模块（core + xmc）
-    MOD->>MOD: 复制文件 + 占位符替换
-    MOD->>MOD: 处理智能体 Sidecar
-    MOD-->>CLI: 模块安装完成
-    CLI->>MAN: 生成 CSV 清单
-    MAN->>MAN: agent-manifest / workflow-manifest / files-manifest
-    MAN-->>CLI: 清单生成完成
-    CLI->>IDE: 安装到选定 IDE
-    IDE->>IDE: 技能文件写入 .claude/skills/ 等
-    IDE-->>CLI: IDE 配置完成
-    CLI-->>U: 安装成功
-```
-
-**关键步骤说明：**
-
-1. **安装检测** — 自动识别项目中是否已安装 XiaoMa，支持升级和重装
-2. **配置收集** — 通过 `@clack/prompts` 提供交互式终端体验，收集项目和用户配置
-3. **模块安装** — 按依赖顺序安装 core 和 xmc 模块，执行占位符替换和 Sidecar 处理
-4. **清单生成** — 生成三份 CSV 清单（智能体/工作流/文件），用于运行时查询和完整性校验
-5. **IDE 配置** — 根据用户选择的 IDE 平台，写入对应的技能文件和配置
-
----
-
-## 5. 支持的 IDE 平台
-
-XiaoMa-CLI 采用**配置驱动**的 IDE 适配方案，通过 `platform-codes.yaml` 统一管理所有平台，无需为每个 IDE 编写定制代码。
-
-| 类别 | 平台 | 优先级 |
-|------|------|--------|
-| CLI | Claude Code | ⭐ 首选 |
-| IDE | Cursor | ⭐ 首选 |
-| IDE | Cline, Windsurf, Roo Code | 支持 |
-| IDE | Codex, OpenCode | 支持 |
-| 云端 | Google Antigravity, Kiro, Rovo Dev | 支持 |
-| CLI | Auggie, Gemini, Pi | 支持 |
-| 其他 | CodeBuddy, Crush, GitHub Copilot, iFlow, Trae 等 | 支持 |
-
-> 所有 IDE 的安装均通过 `platform-codes.yaml` 配置驱动，无需为单个 IDE 编写定制代码。新增 IDE 支持只需添加配置条目。
-
----
-
-## 6. 技术栈
-
-| 技术 | 用途 |
-|------|------|
-| Node.js >= 20 | 运行时环境 |
-| Commander.js | CLI 命令框架 |
-| @clack/prompts | 交互式终端 UI |
-| Zod | Schema 验证（智能体 YAML 校验） |
-| YAML | 配置和智能体定义格式 |
-| Markdown | 工作流和技能定义格式 |
-| Mermaid | 文档图表渲染 |
-| ESLint + Prettier | 代码质量与格式化 |
-| Husky + lint-staged | Git 钩子自动化 |
-
----
-
-## 7. 项目安装后目录结构
-
-以下展示了 XiaoMa-CLI 安装完成后，在用户项目中生成的目录结构：
-
-```
-{项目根目录}/
-├── _xiaoma/                       # 安装目录
-│   ├── core/config.yaml           # 核心配置
-│   ├── xmc/config.yaml            # XMC 模块配置
-│   ├── _config/                   # 清单文件
-│   │   ├── manifest.yaml          # 安装元数据
-│   │   ├── agent-manifest.csv     # 智能体注册表
-│   │   ├── workflow-manifest.csv  # 工作流注册表
-│   │   └── files-manifest.csv     # 文件完整性清单
-│   └── _memory/                   # 智能体记忆（Sidecar）
-├── _xiaoma-output/                # 产出目录
-│   ├── planning-artifacts/        # 规划产物（PRD/架构/史诗等）
-│   └── implementation-artifacts/  # 实施产物（Sprint/Story等）
-├── .claude/skills/                # Claude Code 技能
-├── .cursor/skills/                # Cursor 技能
-└── docs/                          # 项目知识库
-```
-
-**目录说明：**
-
-- **`_xiaoma/`** — XiaoMa 框架核心安装目录，包含所有智能体、工作流、技能定义和配置
-- **`_xiaoma/_config/`** — 安装清单和元数据，用于运行时查询和 `status` 命令
-- **`_xiaoma/_memory/`** — 智能体 Sidecar 记忆文件，支持跨会话上下文保持
-- **`_xiaoma-output/`** — 标准化的产出目录，分为规划阶段和实施阶段两大类
-- **`.claude/skills/` / `.cursor/skills/`** — 各 IDE 平台的技能入口文件