csspilot 0.3.2 → 0.5.0

package/dist/skills/testpilot/SKILL.md

@@ -12,6 +12,7 @@ TestPilot is a **tool, not a business test project**. Business cases always belo
 
 Use TestPilot when the user wants to:
 
+- review test requirements for testability
 - create business test cases
 - validate test cases
 - run tests
@@ -20,12 +21,13 @@ Use TestPilot when the user wants to:
 ## Core workflow
 
 1. Understand user requirement
-2. Inspect project
-3. Identify test target
-4. Create TestPilot Case (`tests/e2e/cases/*.yaml`)
-5. Validate Case (`npx csspilot validate`)
-6. Run Case (`npx csspilot run`)
-7. Analyze result (`npx csspilot report`)
+2. Review requirements & produce test points (`workflows/test-requirements-review.md`)
+3. Inspect project
+4. Identify test target
+5. Create TestPilot Case (`tests/e2e/cases/*.yaml`, linked to test point IDs)
+6. Validate Case (`npx csspilot validate`)
+7. Run Case (`npx csspilot run`)
+8. Analyze result (`npx csspilot report`)
 
 ## Important rules
 
@@ -72,4 +74,5 @@ Read `references/` first (generated by `csspilot init` for this project):
 - `rules/dsl.md` — case structure and the V0.1 action set
 - `rules/locator.md` — locator forms and the no-invention rule
 - `rules/assertion.md` — assertions and variable references
-- `workflows/` — step-by-step workflows (create / validate / run / analyze)
+- `workflows/test-requirements-review.md` — requirements review, test point checklist
+- `workflows/` — step-by-step workflows (review / create / validate / run / analyze)

package/dist/skills/testpilot/manifest.yaml

@@ -2,12 +2,13 @@
 # `npx csspilot init` 会把整个 skills/testpilot/ 安装到业务项目 .agents/skills/testpilot/
 id: testpilot
 name: TestPilot
-version: 0.2.0
+version: 0.5.0
 
 description: >
   AI Native cross-platform testing skill.
 
 capabilities:
+  - test-requirements-review
   - create-case
   - validate
   - run
@@ -37,4 +38,4 @@ permissions:
       - npx
       - pnpm
       - npm
-      - testpilot
+      - csspilot

package/dist/skills/testpilot/workflows/analyze-result.md

@@ -2,11 +2,12 @@
 
 1. 执行 `npx csspilot report` 生成报告。
 2. 产物位于 `.testpilot/artifacts/runs/<run-id>/`:
-   - `report.json` —— 结构化结果,AI 优先读这个:`{ generatedAt, summary: { runId, status, totals, cases: [{ caseId, status, steps: [{ index, target, action, status, durationMs, error?, screenshot?, extracted? }] }] } }`
-   - `report.html` —— 人类可读报告
-   - `screenshots/`、`traces/`、`logs/` —— 失败取证
-3. 失败分析顺序:report.json 中失败步骤的 `error` 信息 → 对应 `screenshot` → `logs/run.log` → `events.ndjson`。
+   - `report.json` —— 结构化结果,AI 优先读这个:`{ generatedAt, summary: { runId, status, totals, cases: [{ caseId, status, steps: [{ index, target, action, status, durationMs, error?, screenshot?, extracted? }] }] }, history(最近 12 次运行趋势), failures(失败分类明细:category / caseId / message) }`;失败步骤的 `category` ∈ assert / element / adapter / env / timeout / other
+   - `report.html` —— 交互式报告(步骤树、失败分类筛选、历史趋势)
+   - `screenshots/`、`videos/`、`traces/`、`logs/` —— 失败取证
+3. 失败分析顺序:report.json 中失败步骤的 `category` 与 `error` → 对应 `screenshot` → `logs/run.log` → `events.ndjson`。
 4. 得出结论:
    - Case 问题(locator 过期、步骤错误)→ 修改 Case,重新 validate → run
    - 产品 bug → 停止修改 Case,向用户报告证据与结论
-5. 不要在未分析 Evidence 的情况下盲目重跑或修改 Case。
+5. 历史趋势中出现反复失败的用例(intermittent / flaky)要在结论中单独标注。
+6. 不要在未分析 Evidence 的情况下盲目重跑或修改 Case。

package/dist/skills/testpilot/workflows/create-case.md

@@ -1,13 +1,16 @@
 # Workflow:创建测试 Case
 
-输入:用户的一句业务需求(如"帮我测试用户下单")。
+输入:用户需求,或 `test-requirements-review` 产出的**测试点清单**(推荐先做需求评审)。
 
-1. 阅读本 Skill:`rules/dsl.md`、`rules/case-design.md`、`rules/locator.md`。
-2. 分析项目结构:确定被测端(miniapp / web)与业务入口页面。
-3. 找到业务路径上的真实页面与组件,收集证据(读代码 / DOM / 现有测试)。
-4. 确定测试路径:从入口到业务结果页的完整步骤。
-5. 按 DSL 规范生成 Case,写入 `tests/e2e/cases/<case-id>.yaml`。
+1. 尚无测试点清单时,先执行 `workflows/test-requirements-review.md`;已有清单则直接使用。
+2. 阅读本 Skill:`rules/dsl.md`、`rules/case-design.md`、`rules/locator.md`。
+3. 分析项目结构:确定被测端(miniapp / web)与业务入口页面。
+4. 针对测试点收集证据(读代码 / DOM / 现有测试),确定业务路径:从入口到业务结果页的完整步骤。
+5. 按 DSL 规范生成 Case,写入 `tests/e2e/cases/<case-id>.yaml`:
+   - 一条 Case 覆盖一个测试点(或一组强关联测试点)
+   - Case 的 `description` 注明关联的测试点编号(如 `测试点: TP-001`),保持需求可溯源
+   - 按评审产出的平台执行信息声明 `accountRef` / `workspace`;发现 `.env` 缺少某平台的地址或凭据变量时,向用户索取后写入 `.env`,**不写进 Case**
 6. 执行 `npx csspilot validate tests/e2e/cases/<case-id>.yaml`。
 7. 校验失败则修复 Case 后重新 validate,直到通过。
 
-禁止:跳过第 2-3 步直接生成 Case(AI 不能凭空生成测试)。
+禁止:跳过第 3-4 步直接生成 Case(AI 不能凭空生成测试)。

package/dist/skills/testpilot/workflows/test-requirements-review.md

@@ -0,0 +1,61 @@
+# Workflow:测试需求评审(可测性评审 + 测试点分析)
+
+输入:需求文档 / PRD / 用户的一句话(如"帮我测试用户下单")。
+产出:**测试点清单** + **平台执行信息表** + 澄清问题 + 评审结论。测试点清单是 `create-case` 的正式输入。
+
+## 步骤
+
+1. **复述理解**:用自己的话列出需求覆盖的功能点与业务流程,向用户确认理解偏差。
+2. **平台盘点**:识别需求涉及的执行端(miniapp / web / api)。跨端需求(如"小程序下单、Web 后台验证")必须逐平台澄清执行信息,见下方"多平台"一节。
+3. **可测性检查清单**(逐项过):
+   - 验收标准是否明确:输入 / 操作步骤 / 预期结果是否可判定
+   - 边界与异常:空值、极值、重复提交、并发、权限、网络异常
+   - 数据准备可行性:测试账号、mock 数据、上下游依赖是否可用
+   - 平台与入口:miniapp / web 的页面路径与入口是否真实存在(不确定时先看项目代码)
+   - 回归范围:改动是否影响现有功能,需要哪些已有 Case 回归
+4. **输出测试点清单**,每条包含:
+
+   | 字段 | 说明 |
+   | --- | --- |
+   | 编号 | `TP-001` 格式,Case 需回链 |
+   | 模块 | 所属功能模块 |
+   | 场景 | 一句话描述验证什么 |
+   | 类型 | 正向 / 边界 / 异常 |
+   | 优先级 | P0 / P1 / P2 |
+   | 平台 | miniapp / web / 双端 |
+
+5. **澄清阻塞项**:需求缺失、矛盾、不可判定时,列出问题向用户提问。**不猜测**。
+6. **给出评审结论**:
+   - 可测:测试点清单完整,直接进入 `create-case`
+   - 有条件可测:部分测试点依赖澄清,先对可执行部分建 Case
+   - 不可测:说明缺口,等待需求补充
+
+## 多平台:平台执行信息澄清
+
+需求涉及多个平台时,**每个平台都必须澄清以下三项**;缺任何一项,该平台相关测试点只能标记"有条件可测",不得开始写 Case:
+
+| 平台 | 必须澄清 | 落地位置 |
+| --- | --- | --- |
+| web | 测试地址(baseUrl)+ 页面入口路由 + 登录角色 | `.env` 的 `WEB_BASE_URL` / `TEST_BASE_URL`;`accountRef` |
+| miniapp | 小程序项目路径 + 起始页面路由 + 登录角色(连哪个环境后端) | `.env` 的 `MINIAPP_PROJECT_PATH`;`accountRef` |
+| api | 服务 baseUrl + 鉴权方式(token / session)+ 账号角色 | `.env` 的 `API_BASE_URL`;`accountRef` |
+
+规则:
+
+- **登录角色**:每个平台确认用什么角色(普通用户 / 管理员 / 游客),映射为 `accountRef`(如 `admin` / `test-user`);真实凭据放 `TESTPILOT_ACCOUNT_<REF大写>` 环境变量或 Server Secrets,**禁止写进 Case**
+- **测试地址**:一律指向测试环境,写入 `.env`(如 `WEB_BASE_URL`);**禁止把内网 / 生产地址写进 Case 或 testpilot.yaml**
+- **使用 Workspace 的项目**:以上信息应登记为 Workspace 的绑定(项目 → 环境),Case 用 `workspace: <名称>` 声明,不逐条硬编码
+
+### 澄清问题示例(多平台需求)
+
+- Web 后台的测试地址是什么?订单查询页面的入口路由是?
+- 小程序连接哪个环境的后端?小程序项目目录在本机哪里?
+- 各平台分别用什么角色登录(普通用户 / 管理员)?该角色是否有完成流程所需的权限?
+- 这些地址和账号是否已写入 `.env`?缺哪个我来补?
+
+## 铁律
+
+- 没有测试点清单,不要进入 `create-case`。
+- 涉及多平台但执行信息(地址 / 入口 / 登录角色)不全时,结论只能是"有条件可测",先澄清再建 Case。
+- 评审基于需求 + 项目代码/页面证据;两项都没有时先收集证据,不空谈。
+- 每个测试点必须可验证:都能回答"怎么判定通过"。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "csspilot",
-  "version": "0.3.2",
+  "version": "0.5.0",
   "description": "TestPilot — AI Native 跨端业务测试基础设施 CLI",
   "license": "MIT",
   "repository": {