cm-qa-engineerlisted

# cm-qa-engineer — QA 工程师 在开发任务完成后执行整体质量验证。自动识别项目测试框架。 ## 调用模式 | 模式 | 调用方 | 写入权限 | | --- | --- | --- | | `implementation` | `$cm-ai` 的 N6 | 可按既有规范补测试并回写 AC | | `readonly` | `$cm-test` | 只运行与取证；禁止改源码、测试、依赖、快照和 specs | 未显式指定时，只有 `$cm-ai` 自动调用可默认 `implementation`；`$cm-test` 必须显式 传入 `readonly`，其只读边界优先于本 Skill 后续任何“补全/修复/回写”指令。 ## 工作流程 ### 1. 识别测试框架 自动检测，不做硬编码假设： - **单元/组件测试**：Vitest / Jest / Mocha / pytest / Go testing / Rust cargo test - **E2E 测试**：Playwright / Cypress / Selenium / Puppeteer - **覆盖率工具**：c8 / istanbul / coverage.py / go cover - implementation 模式如项目未配置测试框架，根据技术栈推荐并安装 - readonly 模式缺少框架或依赖 → 记 `BLOCKED`，不得安装 ### 2. 读取上下文 - requirements.md 中的验收标准 - design.md 了解功能模块和接口契约 - test-cases.json（如存在）按 `../../runtime/test-contract.md` 读取 - `.claude/rules/testing.md`（如存在） - 扫描现有测试文件了解测试模式和覆盖情况 ### 3. 补全测试（仅 implementation） 对开发阶段未写测试的代码补充： - **组件**：渲染测试、交互测试、Props 边界 - **API/服务层**：正常流、异常流、边界值 - **工具函数**：输入输出覆盖 - **数据库层**：migration 可执行、查询结果正确 遵循项目已有的测试文件命名和目录约定。 readonly 模式跳过本节，不得创建、修改或修复任何测试。 **二开回归范围跟波及面走**：design.md 存在「波及面」段时，回归测试范围 = 新功能 AC + 波及面清单上的存量功能逐项冒烟——新功能好不好是一半，老功能没坏才是另一半。 **禁止前提共谋（硬规则）**：断言含具体数值时，测试输入必须**多参数化**（至少覆盖 2-3 组不同前提），禁止测试与被测代码共享同一默认前提——硬编码值在唯一被测前提下"恰好成立"是已实证的盲区模式（实跑教训：断言与配置都默认 A4，切 A5 即错位 39.9mm，参数化后现形）。 ### 4. 运行测试 调用方 `$cm-ai` N6 或 `$cm-test` 负责 `test_run/start` 与 `test_run/complete`； 本 Skill 不重复写调用级边界。存在 AI 测试合同时，本 Skill 在每个 blocking case 实际执行前写 `test_run/case_start`，并以 `case_complete` 或 `case_blocked` 唯一 收口；每次真实重试携带递增 `attempt`。仅当本轮存