@zhanlucode/zl-darwin-arm64 1.6.4-moma.0

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/manual-test-case-generator/SKILL.md

@@ -0,0 +1,366 @@
+---
+name: manual-test-case-generator
+description: |
+  手工测试用例生成、查询并保存技能。根据用户指定的需求编号，自动拉取需求详情，基于需求描述和验收标准生成结构化手工测试用例（用例标题、前置条件、测试步骤、预期结果、优先级、用例类型），以 Markdown 列表形式展示，支持对话修改，并可批量保存至用例库指定目录；同时支持查询关联指定需求的已有测试用例。当用户提到"手工用例"、"测试用例"、"manual test case"、"生成用例"、"设计用例"、"编写用例"、"修改用例"、"保存用例"、"用例入库"、"查询用例"、"查看用例"、"关联需求的用例"时，务必使用此 skill。
+---
+
+# 手工测试用例生成与查询
+
+> 根据用户指定的需求编号，自动拉取需求详情，生成结构化手工测试用例，支持对话修改，并引导用户将用例保存至用例库；同时支持查询关联指定需求的已有测试用例。
+
+## 流程
+
+**重要：本流程各步骤依次执行，不要在步骤之间无故停下等待用户输入（使用 question 工具与用户交互的步骤除外）。**
+
+### 第 1 步：身份解析
+
+从本地认证文件读取当前用户身份信息。
+
+- **Windows 路径**：`C:\Users\Admin\.local\share\zhanlu\auth_zhanlu.json`
+- **macOS / Linux 路径**：`~/.local/share/zhanlu/auth_zhanlu.json`
+
+从 `metadata` 中提取 `userName`、`deputyAccountNumber`、`email`。
+
+### 第 2 步：意图识别与流程分流
+
+根据用户指令判断执行路径：
+
+| 用户指令特征 | 执行路径 |
+|-------------|---------|
+| 包含"生成用例"、"设计用例"、"编写用例"、"帮我写用例"等 | → **流程 A：生成用例**（第 3 步起） |
+| 包含"生成用例并保存"、"生成用例并入库"等 | → **流程 A：生成用例**（第 3 步起），生成完成后自动衔接第 5.4 步（保存MD）和第 7 步（保存至用例库） |
+| 包含"查询用例"、"查看用例"、"关联XX需求的用例"、"获取用例"等 | → **流程 B：查询用例**（阅读 `references/query-rules.md` 执行） |
+| 包含"保存用例"、"用例入库"等 | → **第 7 步：保存用例至用例库**（阅读 `references/save-rules.md` 执行） |
+| 包含"修改用例"等 | → **第 6 步：修改用例**（需上下文中已有用例数据） |
+
+---
+
+## 流程 A：生成用例
+
+### 第 3 步：查询获取需求列表
+
+使用 `mcp__cmdevops_req__list_req_item` 拉取需求列表，支持以下查询方式：
+
+| 用户说法 | 查询策略 |
+|----------|----------|
+| "帮我生成手工用例" | 查询当前用户作为负责人、处于未完成状态的需求 |
+| "为XX项目空间生成用例" | 按 `workspaceName` 筛选指定项目空间的需求 |
+| "为张三提交的需求生成用例" | 按 `approver`（审批人/提交人副账号）筛选指定人员提交的需求 |
+| "为 RR20260119400340 生成用例" | 按 `key` 精确匹配指定需求编号 |
+| "为登录相关需求生成用例" | 按 `name` 模糊匹配需求标题 |
+
+**筛选维度组合：** 以上条件可组合使用，例如"为演示项目中李四提交的需求生成用例"同时按 `workspaceName` + `approver` 筛选。
+
+**默认查询参数（list_req_item）：**
+- `queryMap.itemTypeName` ∈ ["初始需求", "用户故事"]
+- `queryMap.statusName` ∈ ["新建", "需求分派", "需求接收", "分析", "需求评审", "评审中", "评审完成", "设计", "开发", "测试", "待验收", "验收", "验收不通过", "采纳", "执行", "未开始", "进行中"]
+- `queryMap.values__assignee` = ["currentUser"]（当前用户作为负责人）
+- `from` = 0, `size` = 50
+- `fields` 不允许传值
+- 所有 MCP 调用的 `workspaceId` 参数均传 **空间编码**，非空间数据库ID
+
+**按提交人筛选时额外参数：**
+- `queryMap.approver` = 提交人副账号。若用户仅提供姓名，需先通过姓名匹配确认副账号。
+- 此时 `queryMap.values__assignee` 不再默认为 `currentUser`，改为查询该提交人名下的需求。
+
+如果用户指定了需求编号（1个或多个），直接用 `queryMap.key` 精确匹配，无需按状态和负责人过滤。
+
+### 第 4 步：展示需求列表并确认
+
+将查询到的需求以 Markdown 列表形式展示给用户确认，**必须包含业务背景、需求描述、验收标准，且这三个字段必须完整展示，禁止截断或省略**：
+```markdown
+📋 需求列表
+
+### 1. RR20260119400340 - 查看项目列表
+- **类型**: 初始需求
+- **状态**: 评审完成
+- **优先级**: P0
+- **业务背景**: 本项目隶属于XX项目，用来解决用户查看项目信息的问题，当前系统缺乏统一的项目信息展示入口...
+- **需求描述**: 支持按分页查看项目列表，包含项目名称、状态、负责人等字段，支持按名称模糊搜索...
+- **验收标准**: 1.分页功能正常 2.字段展示正确 3.支持按名称搜索 4.每页默认20条...
+
+### 2. RR20260119400341 - 用户登录功能
+- **类型**: 用户故事
+- **状态**: 开发
+- **优先级**: P1
+- **业务背景**: 移动云平台新增用户登录功能，支持多种登录方式
+- **需求描述**: 支持手机号+验证码或邮箱+密码两种登录方式
+- **验收标准**: 1.手机号登录可用 2.密码规则校验正确
+```
+以上是否为您要生成用例的需求？确认后继续，如需调整请直接输入修改内容。
+
+`question` 工具调用示例：
+
+```json
+{
+  "questions": [
+    {
+      "question": "以上是否为您要生成用例的需求？确认后继续，如需调整请直接输入修改内容。",
+      "header": "需求确认",
+      "options": [
+        { "label": "确认，继续生成用例", "description": "为以上需求生成手工测试用例" }
+      ]
+    }
+  ]
+}
+```
+
+`question` 工具默认启用 `custom` 模式，用户如需调整范围可直接在输入框中输入，**不要在 options 中添加"调整范围"选项**。
+
+### 第 5 步：拉取需求详情并生成用例
+
+#### 5.1 拉取需求详情
+
+从 `list_req_item` 返回结果中提取核心字段：
+
+| 字段 | 说明 | 生成用途 |
+|------|------|----------|
+| businessBackground | 业务背景 | 理解业务场景，设计测试场景 |
+| requirement | 需求描述 | 拆解功能点，生成测试用例 |
+| acceptanceCriteria | 验收标准 | 直接转化为预期结果和验证点 |
+
+若列表返回数据不完整，需再次调用 `mcp__cmdevops_req__list_req_item` 按 `key` 精确查询单条需求详情。
+
+#### 5.2 生成测试用例
+
+阅读 `references/generation-rules.md` 获取完整生成规则，然后根据需求信息生成用例。
+
+**核心原则：生成的测试用例必须针对需求本身描述的业务功能进行测试，而非针对"用户操作AI生成用例的流程"。** 测试步骤中的操作对象是需求描述中的功能模块（如页面、接口、按钮、数据），不是IDE对话框或AI交互流程。
+
+**错误示例**（针对AI交互流程，禁止）：
+```
+前置条件: 用户已登录灵畿平台，IDE中MCP服务连接正常
+测试步骤: 在IDE对话框中输入指令"为需求XX生成手工用例"
+预期结果: 系统返回需求详情
+```
+
+**正确示例**（针对需求功能本身）：
+```
+前置条件: 用户已登录系统，拥有需求管理模块操作权限
+测试步骤: 进入需求列表页面，输入需求编号CMSSAIYSYFXFS-330进行搜索
+预期结果: 列表展示需求CMSSAIYSYFXFS-330的详情，包含业务背景、需求描述、验收标准等完整字段
+```
+
+**输入来源：** 以 5.1 步提取的 `businessBackground`（业务背景）、`requirement`（需求描述）、`acceptanceCriteria`（验收标准）三个字段作为生成依据，从中拆解功能点，设计针对这些功能点的测试用例。
+
+**用户指定了用例类型或数量时，以用户要求为准，不再强制以下默认规则。** 例如用户说"只生成功能测试用例"则仅生成功能测试类型；用户说"每个需求生成2条用例"则按2条生成。
+
+未指定时，默认遵循以下规则：
+
+- 100% 覆盖所有识别到的测试点
+- 每个需求至少 4 条用例
+- 7 种用例类型均需覆盖（功能测试、兼容性测试、易用性测试、性能测试、安全测试、冒烟测试、可靠性测试）
+- 包含正向、负向、边界值三类场景
+- 步骤和预期结果必须一一对应
+
+#### 5.3 用例格式与展示
+
+**生成用例后，必须先在 IDE 中以 Markdown 格式完整展示所有用例内容，然后再询问保存路径。** 禁止仅展示用例标题摘要而省略详细内容。
+
+每条用例必须包含以下全部字段，缺一不可：用例编号、用例标题、用例类型、用例等级、前置条件、测试步骤、预期结果。
+
+按以下格式输出（Markdown 列表，不使用表格）：
+
+```markdown
+## 测试用例
+
+### 需求：{需求Key} - {需求标题}
+
+#### 用例 1: [模块-场景-预期状态]
+- **用例编号**: TC-001（三位数序号递增）
+- **用例类型**: [功能测试|兼容性测试|易用性测试|性能测试|安全测试|冒烟测试|可靠性测试]
+- **用例等级**: [P0|P1|P2|P3]
+- **前置条件**:
+  1. [独立占一行，不合并多条]
+- **测试步骤**:
+  1. [操作动作] + [输入内容/参数] + [附加说明]
+- **预期结果**:
+  1. [数据状态] + [系统响应] + [验证标准]
+
+#### 用例 2: [用例标题]
+- **用例编号**: TC-002
+- **用例类型**: ...
+- **用例等级**: ...
+- **前置条件**:
+  1. ...
+- **测试步骤**:
+  1. ...
+- **预期结果**:
+  1. ...
+```
+
+**展示完成后再执行 5.4 步保存操作。**
+
+#### 5.4 保存用例文档
+生成用例并展示后，保存仍须获得用户对精确目标路径的明确确认。当前对话已明确指定并批准该路径、且不涉及未批准的覆盖时，复用该确认并写入；否则使用 `question` 询问路径，禁止把默认路径或经过的时间当作批准。已有文件覆盖、需求回写和用例平台入库分别保留对应批准。
+**默认路径：** `当前项目/doc/manual_test_case/{需求Key}_{需求名称}.md`
+
+`question` 工具调用示例：
+
+```json
+{
+  "questions": [
+    {
+      "question": "请确认用例文档保存路径，默认保存至 doc/manual_test_case/",
+      "header": "保存路径",
+      "options": [
+        { "label": "使用默认路径", "description": "保存至 doc/manual_test_case/{需求Key}_{需求名称}.md" }
+      ]
+    }
+  ]
+}
+```
+
+`question` 工具默认启用 `custom` 模式，会自动附带输入框供用户输入自定义路径，**不要在 options 中添加"自定义路径"选项**。
+
+**必须等待用户选择或输入后再执行 `write` 操作。** 若目录不存在，需先创建目录。每条需求的用例保存为独立文件，特殊字符 `/\\:*?"<>|` 用下划线替代。
+
+**重要：无论用户是否要求保存至用例库，生成的用例都必须保存为 MD 文件。** 当用户输入"生成用例并保存至用例库"时，本步骤不可跳过，必须先保存 MD 文件再执行第 7 步。
+
+保存完成后展示文件路径：
+
+```
+📁 用例文档已保存：doc/manual_test_case/RR20260119400340_查看项目列表.md
+```
+
+后续引导：
+- 仅生成用例：`如需修改用例可直接编辑 MD 文件或通过对话调整。确认无误后，请输入"保存用例到XX用例库"进行入库。`
+- 生成并保存：直接继续执行第 7 步保存至用例库
+
+### 第 6 步：修改用例（按需）
+
+用户可通过两种方式修改用例：
+
+**方式一：对话修改** — 等级调整、内容修改、批量修改、增删用例等
+
+**方式二：直接编辑 MD 文件** — 用户可直接在 IDE 中编辑第 5.4 步保存的 MD 文件
+
+**同步更新规则：** 无论通过哪种方式修改，修改完成后必须将最新用例内容同步写入 MD 文件。对话修改后立即使用 `write` 工具更新；用户编辑 MD 文件后无需额外同步。
+
+修改完成后，主动引导用户保存用例：
+
+```
+用例修改完成，MD 文档已同步更新。如需保存到用例库，请输入"保存用例到XX用例库"进行入库。
+```
+
+### 第 7 步：保存用例至用例库
+
+阅读 `references/save-rules.md` 获取完整保存规则，包括：
+- 自然语言指令解析（用例库名、目录、测试计划）
+- 用例库及场景目录树查询与校验
+- 测试计划查询
+- 必填字段确认
+- Markdown 用例到平台格式的数据转换
+- `batch_create_case` API 调用
+- 保存结果展示
+
+**核心约束：**
+- `execType` 固定为 1（手工测试），所有保存的用例均为手工用例
+- `moduleId` 未指定目录时默认填 `"-1"`，指定目录时填对应的 moduleId 字符串
+- `priority`、`caseType`、`execType` 为 integer 类型，**禁止传字符串**（如 `"P0"`、`"功能测试"`），`caseName`、`directorId`、`creator`、`moduleId`、`demandList`、`projectId`、`productId` 等为 string 类型，类型必须与平台字段一致
+- `projectId`（项目编码）从当前需求的关联项目中获取，如果获取不到，则从当前登录研发空间的关联项目中自动提取，仅一个时自动填充，多个时让用户选择
+- `productId`（产品编码）从当前需求的关联产品中获取，如果获取不到，则从当前登录研发空间的关联产品中自动提取，仅一个时自动填充，多个时让用户选择
+- `remark` 为可选字段，用户有补充说明时填入，无则不传
+
+---
+
+## 流程 B：查询用例
+
+阅读 `references/query-rules.md` 获取完整查询规则，包括：
+- 需求编号解析（支持多个需求、标题模糊匹配）
+- `page_query_case` 分页查询与需求关联过滤
+- 查询结果展示与引导生成
+
+---
+
+## 用例等级速查
+
+| 等级 | 编码 | 定义 | 示例 |
+|------|------|------|------|
+| P0 | 0 | 核心产品/业务，高频用户感知 | 登录、核心控制台、订购流程 |
+| P1 | 1 | 关键业务正常逻辑 + 基础异常 | 备案、API、注销/恢复 |
+| P2 | 2 | 非关键业务正常，其他业务正常 | 非核心功能正常场景 |
+| P3 | 3 | 其他异常逻辑，低频场景 | 非核心/非高频的异常场景 |
+| P4 | 4 | 极低频、可降级场景 | 旁路功能、降级体验 |
+
+## 用例类型速查
+
+必须覆盖以下 7 种类型（括号内为保存到平台时的数字编码）：
+
+1. **功能测试**（0）— 验证业务功能正确性
+2. **兼容性测试**（1）— 多浏览器/OS/分辨率/版本兼容
+3. **易用性测试**（2）— 操作简洁性、提示清晰度、无障碍
+4. **性能测试**（3）— 验证响应时间、并发、资源占用
+5. **安全测试**（4）— 权限控制、注入防护、数据加密
+6. **冒烟测试**（6）— P0/P1 级核心功能快速验证
+7. **可靠性测试**（7）— 长时间运行、断网恢复、重复提交幂等
+
+## 关键约束
+
+- **数据脱敏**：敏感数据用 `***` 替代，保留语义描述
+- **步骤与预期一一对应**：每个测试步骤有且仅有一条预期结果
+- **前置条件独立成行**：禁止将多个条件用分号合并在同一行
+- **不编造信息**：前置条件只写权限、数据状态、基础环境
+- **中文输出**：所有内容使用简体中文
+- **不使用表格**：用例内容用 Markdown 列表格式
+
+## 异常处理
+
+### 无效需求编号
+
+用户输入的需求编号不存在时，**不要编造需求内容**，返回明确提示：
+
+```
+⚠️ 未找到需求编号"XX-999"，请确认编号是否正确。
+可尝试：1. 检查编号拼写 2. 输入"帮我生成手工用例"查看当前负责人下的需求列表
+```
+
+### 保存目录不存在
+
+用户指定的用例库目录不存在时，**不执行保存操作**，提示用户重新选择。详细规则见 `references/save-rules.md`。
+
+### MCP 服务调用异常
+
+`list_req_item`、`list_query_library`、`page_query_case`、`batch_create_case` 等 MCP 调用超时或返回网络错误时：
+
+```
+⚠️ 网络异常：MCP 服务调用超时，无法连接{服务名称}。
+请检查网络连接后重试。如持续失败，请联系平台运维。
+```
+
+### 权限不足
+
+MCP 返回权限相关错误时，给出明确提示：
+
+```
+⚠️ 权限不足：当前用户对{资源名称}没有{操作}权限。
+请联系空间管理员开通权限后重试。
+```
+
+### 保存/查询失败
+
+保存或查询操作部分或全部失败时，必须展示每条失败记录的具体原因，禁止仅提示"操作失败"：
+
+```
+❌ 失败详情：
+  - TC-003: 并发登录 → 失败原因：用例名称重复
+  - TC-005: XSS防护 → 失败原因：目录权限不足
+```
+
+## MCP 工具清单
+
+| 工具名称 | 用途 |
+|---------|------|
+| `mcp__cmdevops_req__list_req_item` | 拉取初始需求和用户故事列表 |
+| `mcp__cmdevops_ct__list_query_library` | 获取用例库ID及场景目录树 |
+| `mcp__cmdevops_ct__list_query_plan` | 查询研发空间下的测试计划列表 |
+| `mcp__cmdevops_ct__page_query_case` | 从用例库分页查询测试用例 |
+| `mcp__cmdevops_ct__batch_create_case` | 批量创建测试用例至用例库 |
+
+## 评审规则（可选）
+
+> 仅当用户明确要求"评审用例""需要评审"等表述时执行。
+
+阅读 `references/review-rules.md`，对照 8 个评审维度进行自我评审。评审的核心原则是**发现问题，而非确认通过**。
+
+评审不通过时执行一轮修正：修复所有不通过项、清理幻觉信息、补充缺失场景和类型。最多修正 1 轮。

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/manual-test-case-generator/references/generation-rules.md

@@ -0,0 +1,214 @@
+# 测试用例生成规则
+
+本文件定义了手工测试用例生成的完整规则。生成用例时，每一条规则都是必须遵守的底线，而非可选建议——违反任何一条都会导致用例在实际执行中出现质量问题。
+
+## 目录
+
+1. [核心使命](#核心使命)
+2. [覆盖要求](#覆盖要求)
+3. [用例设计方法](#用例设计方法)
+4. [质量标准](#质量标准)
+5. [步骤精确度标准](#步骤精确度标准)
+6. [预期结果精确度标准](#预期结果精确度标准)
+7. [步骤与预期结果格式规范](#步骤与预期结果格式规范)
+8. [用例类型详细定义](#用例类型详细定义)
+9. [设计原则](#设计原则)
+10. [质量检查清单](#质量检查清单)
+
+---
+
+## 核心使命
+
+确保 100% 测试点覆盖率——为测试点列表中的每一个测试点生成至少一个对应的测试用例，不遗漏任何测试点。每个需求设计的用例数不少于 4 条，可根据覆盖范围和需求内容增加实际用例数量。
+
+## 覆盖要求
+
+- **100% 测试点覆盖**：每个测试点至少对应一个用例
+- **关键路径重点覆盖**：主要业务流程多场景测试
+- **边界条件必须覆盖**：输入边界、状态边界等
+- **三类场景全覆盖**：正向（正常流程）、负向（异常/非法输入）、边界值
+
+## 用例设计方法
+
+使用以下方法组合设计用例，确保系统性和完整性：
+
+1. **等价类划分法**：将输入域划分为有效等价类和无效等价类
+2. **边界值分析法**：针对边界条件设计用例（最大/最小/临界值）
+3. **判定表法**：处理多条件组合的场景
+4. **因果图法**：分析输入条件之间的逻辑关系
+5. **场景法**：基于业务流程设计端到端场景
+6. **错误推测法**：基于经验推测可能的错误
+7. **正交试验法**：多因素多水平时减少组合数量
+8. **状态迁移法**：测试状态转换的正确性
+
+## 质量标准
+
+### 1. 可执行性
+- 操作步骤清晰具体，按序编号
+- 步骤描述详细，测试人员可准确执行
+- 无歧义的操作指令
+
+### 2. 可验证性
+- 每个步骤都有明确的预期结果
+- 预期结果具体、可衡量、可观察
+- 判断标准清晰明确
+
+### 3. 独立性
+- 每个用例聚焦验证对应测试点
+- 用例间相互独立，不产生依赖
+- 单个用例执行完整闭环
+
+### 4. 数据设计
+- **测试数据具体化**：提供确切的输入值
+- **场景数据多样化**：正常值、边界值、异常值
+- **业务数据真实化**：符合实际业务场景
+
+## 步骤精确度标准
+
+每个测试步骤必须达到以下详细程度，确保任何测试人员都能准确执行：
+
+### 界面操作要求
+- 明确指定页面/界面名称（如：登录页面、用户管理页面）
+- 精确描述界面元素（如：用户名输入框、确认按钮、第2行编辑图标）
+- 包含具体的操作动作（如：单击、双击、输入、选择、滚动）
+- 标明元素位置信息（如：页面右上角、表格第一行、弹窗中央）
+
+### 数据输入要求
+- 提供具体的测试数据值（敏感数据用 `***` 替代）
+- 说明数据格式要求（如：11位手机号格式、6-20位密码）
+- 包含特殊字符处理（如：包含空格、特殊符号、中文字符）
+- 明确数据选择范围（如：从下拉菜单选择"北京市"）
+
+### 系统交互要求
+- 描述等待时间（如：等待3秒页面加载完成）
+- 说明网络请求状态（如：等待API调用返回）
+- 包含系统状态检查（如：确认数据已保存）
+- 处理异步操作（如：等待弹窗出现）
+
+### 验证点要求
+- 明确验证的具体内容（避免"操作成功"等模糊描述）
+- 包含界面元素验证（如：按钮变为灰色、文字颜色变为红色）
+- 数据验证（如：数据库新增1条记录、API返回状态码200）
+- 用户体验验证（如：响应时间小于2秒、无404错误）
+
+## 预期结果精确度标准
+
+每个预期结果必须具备以下特征：
+
+### 可观察性
+- 描述具体的视觉变化（如：按钮文字变为"提交中..."）
+- 包含具体的文字内容（如：页面顶部显示绿色"保存成功"提示）
+- 说明数据显示格式（如：时间显示为"2024-01-15 14:30:25"）
+- 界面布局变化（如：表格新增一行、分页显示第2页）
+
+### 可测量性
+- 提供具体的数值标准（如：页面加载不超过3秒）
+- 包含数量验证（如：列表显示10条记录）
+- 状态码验证（如：HTTP状态码201）
+- 性能指标（如：内存使用率低于80%）
+
+### 完整性
+- 覆盖主要功能验证
+- 包含界面状态验证（如：必填字段标红显示）
+- 数据一致性验证（如：前端数据与后端一致）
+- 业务规则验证（如：库存正确扣减）
+
+## 步骤与预期结果格式规范
+
+操作步骤格式：
+```
+1. [操作动作] + [输入内容/参数] + [附加说明]
+2. [操作动作] + [输入内容/参数] + [附加说明]
+3. [操作动作] + [输入内容/参数] + [附加说明]
+```
+
+预期结果格式：
+```
+1. [数据状态] + [系统响应] + [验证标准] + [时间要求]
+2. [系统响应] + [验证标准] + [时间要求]
+3. [数据状态] + [系统响应] + [验证标准] + [时间要求]
+```
+
+要求每个操作步骤对应一条预期结果，逻辑清晰、可执行。
+
+## 用例类型详细定义
+
+7 种必选类型及其典型测试场景：
+
+### 功能测试
+验证业务功能正确性。包括：
+- 正常业务流程（正向）
+- 异常输入处理（负向）
+- 边界条件验证
+- 业务规则校验
+- 数据流转正确性
+
+### 性能测试
+验证响应时间、并发、资源占用。包括：
+- 页面加载时间
+- 接口响应时间
+- 并发用户数
+- 大数据量处理
+- 资源占用（CPU/内存）
+
+### 冒烟测试
+L0/L1 级核心功能的快速验证。包括：
+- 核心业务主流程
+- 关键功能入口可达性
+- 基础数据展示正确性
+
+### 兼容性测试
+多环境下的兼容性表现。包括：
+- 多浏览器（Chrome/Firefox/Safari/Edge）
+- 多操作系统（Windows/macOS/Linux）
+- 不同分辨率与缩放
+- 不同 API/数据格式版本
+- 第三方组件/依赖版本兼容
+
+### 易用性测试
+界面与交互的易用性。包括：
+- 操作步骤简洁可理解
+- 提示与错误信息清晰
+- 快捷键与焦点顺序
+- 无障碍与可访问性
+- 反馈与状态可见性
+
+### 可靠性测试
+长时间运行和异常恢复。包括：
+- 断网恢复后数据一致性
+- 服务重启后状态恢复
+- 重复提交幂等性
+- 超时与重试行为
+- 长时间运行稳定性
+
+### 安全测试
+权限控制和数据保护。包括：
+- 权限越权访问控制
+- 输入注入防护（SQL/XSS）
+- 敏感数据加密传输
+- 会话管理与超时
+- 日志审计完整性
+
+## 设计原则
+
+1. **完整性**：覆盖所有识别的功能点和测试场景
+2. **可执行性**：步骤清晰，易于执行
+3. **独立性**：用例之间相互独立
+4. **可重复性**：能够重复执行
+5. **易维护性**：便于后续维护和更新
+6. **数据脱敏**：敏感数据一律用 `***` 替代
+
+## 质量检查清单
+
+生成用例后，逐项确认：
+
+- [ ] 每个测试点都有对应用例
+- [ ] 用例编号唯一且符合 TC-XXX 命名规范
+- [ ] 操作步骤格式严格遵循规范
+- [ ] 每个步骤有对应预期结果
+- [ ] 7 种用例类型均有覆盖
+- [ ] 包含正向、负向、边界值场景
+- [ ] 敏感数据已脱敏
+- [ ] 前置条件独立成行，无合并
+- [ ] 所有内容使用简体中文
+- [ ] 无幻觉信息（无编造账号、URL、IP）

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/manual-test-case-generator/references/query-rules.md

@@ -0,0 +1,60 @@
+# 测试用例查询规则
+
+本文件定义了查询关联需求的已有测试用例的完整流程。
+
+## 重要约定：空间编码 vs 空间ID
+
+所有 MCP 接口中涉及研发空间参数（`workspaceId`、`X-Auth-ModuleId` 等）时，**统一传空间编码（字符串），非空间数据库数字ID**。`workspaceId` 虽然是 MCP 参数名，但值应为空间编码。
+
+## 流程入口
+
+当用户输入"查询用例"、"查看用例"、"关联XX需求的用例"、"获取用例"等指令时，进入查询流程。
+
+## 步骤
+
+### B1：解析需求编号
+
+从用户指令中提取需求编号：
+
+| 用户说法 | 解析结果 |
+|----------|----------|
+| "查询关联 RR20260119400340 的测试用例" | 需求编号 = RR20260119400340 |
+| "查看RR20260119400340和RR20260119400341的用例" | 需求编号 = RR20260119400340, RR20260119400341 |
+| "获取登录需求的用例" | 需按标题模糊匹配需求编号 |
+
+若用户仅提供需求标题关键词，需先调用 `mcp__cmdevops_req__list_req_item` 按 `name` 模糊查询获取需求编号。
+
+### B2：查询用例库中的测试用例
+
+1. 先调用 `mcp__cmdevops_ct__list_query_library` 获取用例库信息（`libraryId`）
+2. 调用 `mcp__cmdevops_ct__page_query_case` 从用例库中分页查询用例
+
+**page_query_case 调用参数（注意：`workspaceId` 传空间编码）：**
+- `queryParameters.workspaceId` = 空间编码
+- `queryParameters.libraryId` = 用例库ID
+- `queryParameters.page` = 1
+- `queryParameters.limit` = 200
+
+3. 从返回结果中，按 `demandList` 字段过滤出关联了目标需求编号的用例（客户端过滤，`demandList` 包含需求编号即匹配）
+4. 若单页未查完，继续翻页查询直到获取全部用例
+
+### B3：展示查询结果
+
+将关联该需求的用例以列表形式展示：
+
+```
+📋 需求 RR20260119400340（查看项目列表）关联的测试用例
+
+  1. TC-001: 查看项目列表-正常分页查询-功能测试-P0
+  2. TC-002: 查看项目列表-搜索无结果-功能测试-P1
+  3. TC-003: 查看项目列表-大数据量加载-性能测试-P2
+  ...
+
+共 3 条用例
+```
+
+若查询结果为空：
+
+```
+📋 需求 RR20260119400340 暂无关联的测试用例。可输入"为该需求生成手工用例"进行生成。
+```