@pzy560117/opentest 0.1.3 → 0.1.5

package/assets/skills/opentest/templates/matrix-template.md

@@ -1,6 +1,6 @@
 # Acceptance-to-Test Matrix
 
-| ID | 意图 | 触发/输入 | 期望行为 | 风险 | 证据层级 | 必需证据 | 状态 |
+| ID | Intent | Trigger/Input | Expected behavior | Risk | Evidence layer | Required evidence | Status |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| ACC-001 | 主路径成功 |  |  | low | smoke | targeted review | pending |
-| ACC-002 | 失败/边界路径 |  |  | medium | acceptance | UI/API 验收 | pending |
+| ACC-001 | Happy path succeeds |  |  | low | smoke | targeted review | pending |
+| ACC-002 | Failure or boundary path |  |  | medium | acceptance | UI/API acceptance | pending |

package/assets/skills/opentest/templates/plan-template.md

@@ -1,28 +1,28 @@
-# OpenTest 测试策略
+# OpenTest Test Strategy
 
-## 变更摘要
+## Change Summary
 
-- 变更类型:
-- 风险等级:
-- 影响面:
+- change type:
+- risk level:
+- impact area:
 
-## 适用覆盖面
+## Applicable Coverage
 
-- 必需:
-- 不适用:
+- required:
+- not applicable:
 - gap:
 
-## 隐性场景挖掘
+## Implicit Scenario Mining
 
-- 空输入/非法输入:
-- 网络/服务端失败:
-- 权限/会话:
-- 重复提交/并发/过期状态:
+- empty/invalid input:
+- network/server failure:
+- permissions/session:
+- duplicate submit/concurrency/stale state:
 - loading/empty/error/retry:
-- 移动端/可访问性:
-- 安全/敏感信息:
+- mobile/accessibility:
+- security/sensitive information:
 
-## 证据计划
+## Evidence Plan
 
-| 证据层级 | 适用场景 | 命令或执行面 | 产物路径 | 状态 |
+| Evidence layer | Applicable scenario | Command or execution surface | Artifact path | Status |
 | --- | --- | --- | --- | --- |

package/assets/skills/opentest/templates/report-template.md

@@ -1,4 +1,4 @@
-# OpenTest 验证报告
+# OpenTest Verification Report
 
 ## Summary
 

package/assets/skills/opentest-accept/SKILL.md

@@ -1,25 +1,25 @@
 ---
 name: opentest-accept
-description: "OpenTest 阶段 4：执行自然语言验收、MCP 验收或真实链路验收，并回写证据。"
+description: "OpenTest phase 4: execute natural language, MCP, or real workflow acceptance and write back evidence."
 ---
 
 # OpenTest Accept
 
-## 目标
+## Goal
 
-执行必需验收项，并把 PASS、FAIL 或 blocked evidence 回写到验收用例和矩阵。
+Execute required acceptance items and write PASS, FAIL, or blocked evidence back to acceptance cases and the matrix.
 
-## 步骤
+## Steps
 
-1. 读取矩阵和 `docs/opentest/acceptance/`。
-2. 对前端交互，优先用 Chrome DevTools MCP 执行真实页面验收。
-3. 对 API 或后台链路，使用项目已有命令或直接 API 检查。
-4. 对反馈类场景，必须观察实际呈现位置和形态；例如字段错误不能只记录“失败”，要记录是否在字段下方、表单顶部、toast、modal 或页面错误区显示。
-5. 工具、环境或前置数据不可用时，记录 blocked evidence。
-6. 更新验收记录。
-7. 更新 `docs/loop-handoff/latest.md`（如果项目使用 Loop Handoff），记录验收结果、截图/步骤证据路径、blocked evidence 和下一步。
-8. 运行 `bash "$OPENTEST_GUARD" accept --apply`。
+1. Read the matrix and `docs/opentest/acceptance/`.
+2. For frontend interactions, prefer Chrome DevTools MCP to execute real page acceptance.
+3. For APIs or backend workflows, use existing project commands or direct API checks.
+4. For feedback scenarios, observe the actual rendered location and shape. For example, field errors must not be recorded only as "failed"; record whether they appear below the field, at the top of the form, in a toast, in a modal, or in a page error region.
+5. When tools, environment, or seed data are unavailable, record blocked evidence.
+6. Update acceptance records.
+7. If the project uses Loop Handoff, update `docs/loop-handoff/latest.md` with acceptance result, screenshot/step evidence paths, blocked evidence, and next step.
+8. Run `bash "$OPENTEST_GUARD" accept --apply`.
 
 ## Existing Skill Routing
 
-前端交互验收优先使用自然语言用例加 Chrome DevTools MCP。执行前先确认用例覆盖的是本次适用维度；执行后把 PASS、FAIL 或 blocked 写回对应 ACC ID。
+For frontend interaction acceptance, prefer natural language cases plus Chrome DevTools MCP. Before execution, confirm that the case covers a dimension applicable to this change. After execution, write PASS, FAIL, or blocked back to the matching ACC ID.

package/assets/skills/opentest-archive/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: opentest-archive
-description: "OpenTest 阶段 6：归档已通过验证的质量证据并关闭状态。"
+description: "OpenTest phase 6: archive verified quality evidence and close state."
 ---
 
 # OpenTest Archive
 
-验证通过后，将 plan、matrix、acceptance、runs、reports 和可用截图或日志复制到 `docs/opentest/archive/`，运行 `bash "$OPENTEST_GUARD" archive --apply`。验证未通过时拒绝完成归档。
+After verification passes, copy plan, matrix, acceptance, runs, reports, and available screenshots or logs into `docs/opentest/archive/`, then run `bash "$OPENTEST_GUARD" archive --apply`. Refuse to complete archive when verification has not passed.

package/assets/skills/opentest-author/SKILL.md

@@ -1,27 +1,27 @@
 ---
 name: opentest-author
-description: "OpenTest 阶段 2：根据矩阵补齐测试资产和自然语言验收用例。"
+description: "OpenTest phase 2: create test assets and natural language acceptance cases from the matrix."
 ---
 
 # OpenTest Author
 
-## 目标
+## Goal
 
-根据 acceptance-to-test matrix 创建或更新测试资产。
+Create or update test assets from the acceptance-to-test matrix.
 
-本阶段把矩阵变成可执行证据：能用项目测试框架证明的写测试；更适合真实链路、浏览器、API 或人工可复验步骤证明的，写自然语言验收用例。不要为了“像 TDD”而把所有交互反馈硬塞进 unit test。
+This phase turns the matrix into executable evidence. Write tests for behavior that the project's test framework can prove. Write natural language acceptance cases for real workflows, browser checks, APIs, or manually reproducible steps. Do not force all interaction feedback into unit tests just to imitate TDD.
 
-## 步骤
+## Steps
 
-1. 读取 `.opentest.yaml` 中的 `matrix`。
-2. 对 unit/component/integration/contract 证据，按项目已有测试框架创建或更新测试文件。
-3. 对 E2E、smoke、browser acceptance、真实 API 或跨页面流程，写入 `docs/opentest/acceptance/` 自然语言验收用例。
-4. 对前端反馈类用例，写清反馈位置和形态，例如字段下方错误、表单顶部错误、toast、modal、inline status 或页面错误态。
-5. 对不适用或当前无法补齐的证据，记录原因和风险。
-6. 写入 `.opentest.yaml` 的 `acceptance` 字段。
-7. 更新 `docs/loop-handoff/latest.md`（如果项目使用 Loop Handoff），记录测试资产、自然语言验收用例、gap/risk 和下一步。
-8. 运行 `bash "$OPENTEST_GUARD" author --apply`。
+1. Read `matrix` from `.opentest.yaml`.
+2. For unit/component/integration/contract evidence, create or update test files using the project's existing test framework.
+3. For E2E, smoke, browser acceptance, real APIs, or cross-page flows, write natural language acceptance cases under `docs/opentest/acceptance/`.
+4. For frontend feedback cases, specify the feedback location and shape, such as field-level errors, form-level errors, toast, modal, inline status, or page error state.
+5. Record reasons and risk for evidence that is not applicable or cannot currently be created.
+6. Write the `.opentest.yaml` `acceptance` field.
+7. If the project uses Loop Handoff, update `docs/loop-handoff/latest.md` with test assets, natural language acceptance cases, gaps/risks, and next step.
+8. Run `bash "$OPENTEST_GUARD" author --apply`.
 
 ## Existing Skill Routing
 
-当矩阵要求代码级测试证据时，优先加载现有 TDD guidance。若项目规则要求特定测试框架，遵循项目规则。若当前任务更适合真实验收而不是新增测试框架代码，记录原因并交给 `opentest-accept`。
+When the matrix requires code-level test evidence, load the existing TDD guidance first. If project rules require a specific test framework, follow those rules. If the current task is better proven by real acceptance than by adding test framework code, record the reason and hand it to `opentest-accept`.

package/assets/skills/opentest-heal/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: opentest-heal
-description: "OpenTest 恢复阶段：修复测试资产问题，不掩盖产品行为失败。"
+description: "OpenTest recovery phase: repair test asset issues without hiding product behavior failures."
 ---
 
 # OpenTest Heal
 
-只处理 selector、等待策略、过期 label、过期自然语言步骤等测试资产问题。若失败说明产品行为不满足验收，停止 heal 并记录需要回到 author、run 或 verify。
+Only handle test asset issues such as selectors, wait strategy, stale labels, or stale natural language steps. If the failure shows that product behavior does not satisfy acceptance, stop heal and record that the work must return to author, run, or verify.

package/assets/skills/opentest-plan/SKILL.md

@@ -1,30 +1,30 @@
 ---
 name: opentest-plan
-description: "OpenTest 阶段 1：分析变更、风险和项目事实，生成测试策略与 acceptance-to-test matrix。"
+description: "OpenTest phase 1: analyze the change, risks, and project facts, then produce a test strategy and acceptance-to-test matrix."
 ---
 
 # OpenTest Plan
 
-## 目标
+## Goal
 
-生成 `docs/opentest/plans/` 下的测试策略和 `docs/opentest/matrices/` 下的矩阵。
+Create a test strategy under `docs/opentest/plans/` and a matrix under `docs/opentest/matrices/`.
 
-本阶段是 OpenTest-driven development 的入口。它必须在实现前把“需求没写但成熟产品默认应该处理”的场景显性化，避免只根据字面需求写少量 happy path 测试。
+This phase is the entry point for OpenTest-driven development. Before implementation, it must make scenarios explicit even when the requirement did not spell them out but a mature product should handle them. Do not produce only a few happy-path tests from the literal requirement.
 
-## 步骤
+## Steps
 
-1. 读取项目规则、需求、设计、diff、现有测试命令和 `opentest/references/codex-harness-coverage-heuristics.md`。
-2. 如果存在前端、表单、导航、CRUD、状态反馈或动效，优先读取项目内 `docs/frontend/DESIGN.md` 和可用的 `harness-frontend-design` / `product-ui-defaults` 规则。
-3. 判断变更类型、风险等级和适用覆盖面。
-4. 做隐性场景挖掘：空输入、非法输入、网络失败、权限不足、重复提交、长内容、空数据、错误映射、移动端、可访问性、跨页面返回和状态恢复。
-5. 生成窄矩阵，至少包含 `ID`、`意图`、`触发/输入`、`期望行为`、`风险`、`证据层级`、`必需证据`、`状态`。
-6. 对适用但未覆盖的证据面标记 `gap`。
-7. 写入 `.opentest.yaml` 的 `plan` 和 `matrix` 字段。
-8. 更新 `docs/loop-handoff/latest.md`（如果项目使用 Loop Handoff），记录 plan、matrix 路径、当前阶段和下一步。
-9. 运行 `bash "$OPENTEST_GUARD" plan --apply`。
+1. Read project rules, requirements, design, diff, existing test commands, and `opentest/references/codex-harness-coverage-heuristics.md`.
+2. If the change involves frontend UI, forms, navigation, CRUD, status feedback, or motion, first read the project's `docs/frontend/DESIGN.md` and any available `harness-frontend-design` / `product-ui-defaults` rules.
+3. Classify the change type, risk level, and applicable coverage.
+4. Mine implicit scenarios: empty input, invalid input, network failure, missing permissions, duplicate submission, long content, empty data, error mapping, mobile behavior, accessibility, cross-page return paths, and state restoration.
+5. Produce a narrow matrix with at least `ID`, `intent`, `trigger/input`, `expected behavior`, `risk`, `evidence layer`, `required evidence`, and `status`.
+6. Mark applicable but uncovered evidence as `gap`.
+7. Write the `.opentest.yaml` `plan` and `matrix` fields.
+8. If the project uses Loop Handoff, update `docs/loop-handoff/latest.md` with the plan path, matrix path, current phase, and next step.
+9. Run `bash "$OPENTEST_GUARD" plan --apply`.
 
-## 约束
+## Constraints
 
-不要把 Codex Harness 全量 checklist 展开成固定必需项。低风险变更保留轻量覆盖摘要，高风险闭环再展开详细验收维度。
+Do not expand the full Codex Harness checklist into fixed required items. Keep a lightweight coverage summary for low-risk changes, and expand detailed acceptance dimensions only for high-risk loops.
 
-不要把所有证据都写成 unit test。矩阵要明确哪些用 unit/component/integration/contract/E2E/smoke/browser acceptance/security review 证明。
+Do not force all evidence into unit tests. The matrix must state which behavior is proven by unit, component, integration, contract, E2E, smoke, browser acceptance, or security review evidence.

package/assets/skills/opentest-run/SKILL.md

@@ -1,28 +1,28 @@
 ---
 name: opentest-run
-description: "OpenTest 阶段 3：按 targeted、fast、full 或 ci-like 模式运行项目测试命令。"
+description: "OpenTest phase 3: run project test commands in targeted, fast, full, or ci-like mode."
 ---
 
 # OpenTest Run
 
-## 目标
+## Goal
 
-执行项目已有验证命令并写入运行报告。
+Run existing project verification commands and write a run report.
 
-## 模式
+## Modes
 
-- `targeted`：只运行与矩阵相关的测试命令。
-- `fast`：运行快速反馈命令，例如 type、lint、unit。
-- `full`：运行项目完整测试命令。
-- `ci-like`：尽量复现 CI 验证顺序。
+- `targeted`: run only test commands related to the matrix.
+- `fast`: run fast feedback commands, such as type, lint, and unit.
+- `full`: run the project's full test command set.
+- `ci-like`: reproduce CI verification order as closely as practical.
 
-证据层级由矩阵决定。不要因为存在 `npm test` 就只跑 unit test；如果矩阵要求 integration、contract、E2E、smoke 或安全检查，必须运行对应项目命令，或记录 missing command / blocked。
+Evidence layers are decided by the matrix. Do not run only unit tests just because `npm test` exists. If the matrix requires integration, contract, E2E, smoke, or security checks, run the matching project command or record missing command / blocked.
 
-## 步骤
+## Steps
 
-1. 读取 `.opentest.yaml` 的 `run_mode` 和矩阵。
-2. 优先使用项目显式命令，按矩阵中的证据层级选择 targeted、fast、full 或 ci-like。
-3. 记录命令、退出码、摘要和日志路径到 `docs/opentest/runs/`。
-4. 写入 `.opentest.yaml` 的 `run_report` 字段。
-5. 更新 `docs/loop-handoff/latest.md`（如果项目使用 Loop Handoff），记录已运行验证、未运行验证、失败/阻塞、run report 路径和下一步。
-6. 运行 `bash "$OPENTEST_GUARD" run --apply`。
+1. Read `run_mode` and the matrix from `.opentest.yaml`.
+2. Prefer explicit project commands, and select targeted, fast, full, or ci-like mode based on matrix evidence layers.
+3. Record command, exit code, summary, and log path under `docs/opentest/runs/`.
+4. Write the `.opentest.yaml` `run_report` field.
+5. If the project uses Loop Handoff, update `docs/loop-handoff/latest.md` with verification already run, verification not run, failures/blockers, run report path, and next step.
+6. Run `bash "$OPENTEST_GUARD" run --apply`.

package/assets/skills/opentest-verify/SKILL.md

@@ -1,24 +1,24 @@
 ---
 name: opentest-verify
-description: "OpenTest 阶段 5：应用质量门并生成验证报告。"
+description: "OpenTest phase 5: apply quality gates and generate a verification report."
 ---
 
 # OpenTest Verify
 
-## 目标
+## Goal
 
-应用质量门，输出结构化验证报告，并把结果写回状态文件。
+Apply quality gates, produce a structured verification report, and write the result back to the state file.
 
 ## Verification Order
 
-验证报告按 build、type、lint、test、security、diff 组织。若项目没有某类命令，记录为 missing command 或 not applicable，不把未知状态写成 pass。
+Organize the verification report by build, type, lint, test, security, and diff. If the project has no command for a category, record missing command or not applicable instead of treating unknown status as pass.
 
-按 build、type、lint、test、security、diff 的顺序组织证据。必需测试、必需验收、构建、类型或 lint 失败时标记 `fail`。非必需缺口可记录为 `risk-accepted`。写入 `docs/opentest/reports/` 和 `.opentest.yaml` 的 `verification_report`、`verification_result`。
-如果项目使用 Loop Handoff，同时把 OpenTest verification report 路径、verification result、已运行验证、未运行验证、失败/阻塞和下一步写入 `docs/loop-handoff/latest.md`。
+Organize evidence in build, type, lint, test, security, diff order. Mark `fail` when required tests, required acceptance, build, type, or lint fail. Non-required gaps may be recorded as `risk-accepted`. Write to `docs/opentest/reports/` and to the `.opentest.yaml` `verification_report` and `verification_result` fields.
+If the project uses Loop Handoff, also write the OpenTest verification report path, verification result, verification already run, verification not run, failures/blockers, and next step to `docs/loop-handoff/latest.md`.
 
-验证报告还必须回看矩阵，确认：
+The verification report must also review the matrix and confirm:
 
-- 每个 required evidence 都有 pass、fail、blocked 或 risk-accepted 结论。
-- 高风险行为不能因为没有工具、没有测试框架或没有 seed data 就直接通过。
-- blocked evidence 必须包含阻塞原因和后续恢复路径。
-- 若产品行为失败，不进入 `heal` 修测试资产；应返回实现或需求修正。
+- Every required evidence item has a pass, fail, blocked, or risk-accepted conclusion.
+- High-risk behavior does not pass merely because tooling, a test framework, or seed data is missing.
+- Blocked evidence includes a blocker reason and recovery path.
+- If product behavior fails, do not enter `heal` to patch test assets; return to implementation or requirement correction.

package/assets/skills-zh/opentest/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: opentest
+description: "OpenTest 路由入口。自动检测 .opentest.yaml、初始化测试生命周期状态，并分发到 plan/author/run/accept/verify/heal/archive 阶段。"
+---
+
+# OpenTest 路由入口
+
+OpenTest 是面向 AI 编程变更的测试决策与质量证据生命周期。它不是单纯的 TDD 包装，也不是只在实现结束后跑命令；它应在实现前先把显性需求、隐性边界、失败路径、交互反馈和风险场景整理成测试矩阵，再用矩阵驱动代码、验收和质量门。
+
+## 产出语言契约
+
+- 面向用户输出和生成文档默认使用中文。
+- 命令、路径、frontmatter key、代码标识符和 API 名称保持原文。
+
+## 第 0 步：定位脚本
+
+运行：
+
+```bash
+OPENTEST_SEARCH_ROOTS=("." ".codex/skills" ".claude/skills" ".cursor/skills" ".opencode/skills" ".gemini/skills" ".qwen/skills" ".qoder/skills" "$HOME/.codex/skills" "$HOME/.claude/skills" "$HOME/.cursor/skills" "$HOME/.config/opencode/skills" "$HOME/.gemini/skills" "$HOME/.qwen/skills" "$HOME/.qoder/skills")
+OPENTEST_STATE="${OPENTEST_STATE:-$(find "${OPENTEST_SEARCH_ROOTS[@]}" -path '*/opentest/scripts/opentest-state.sh' -type f -print -quit 2>/dev/null)}"
+OPENTEST_GUARD="${OPENTEST_GUARD:-$(find "${OPENTEST_SEARCH_ROOTS[@]}" -path '*/opentest/scripts/opentest-guard.sh' -type f -print -quit 2>/dev/null)}"
+OPENTEST_DETECT="${OPENTEST_DETECT:-$(find "${OPENTEST_SEARCH_ROOTS[@]}" -path '*/opentest/scripts/opentest-detect.sh' -type f -print -quit 2>/dev/null)}"
+```
+
+若任一脚本缺失，停止并提示安装或复制 OpenTest 分发包。
+
+## 第 1 步：状态检测
+
+如果存在 `docs/loop-handoff/latest.md`，先读取 handoff，确认上次 OpenTest 阶段、矩阵/验收/报告路径、阻塞项和下一步。handoff 只作为恢复线索，不替代 `.opentest.yaml`。
+
+如果 `.opentest.yaml` 不存在，运行：
+
+```bash
+bash "$OPENTEST_STATE" init
+```
+
+然后运行：
+
+```bash
+bash "$OPENTEST_STATE" check
+bash "$OPENTEST_DETECT" summary
+```
+
+## 第 2 步：阶段分发
+
+读取 `phase`：
+
+```bash
+bash "$OPENTEST_STATE" get phase
+```
+
+分发规则：
+
+- `archived: true`：报告 OpenTest 已完成。
+- `phase: plan`：调用 `opentest-plan`。
+- `phase: author`：调用 `opentest-author`。
+- `phase: run`：调用 `opentest-run`。
+- `phase: accept`：调用 `opentest-accept`。
+- `phase: verify`：调用 `opentest-verify`。
+- `phase: heal`：调用 `opentest-heal`。
+- `phase: archive`：调用 `opentest-archive`。
+
+若状态与可验证文件冲突，以文件状态为准，并用 `opentest-state.sh set` 修正；如存在 handoff，也同步更新 handoff 的“当前阶段/下一步/失败阻塞”。
+
+## OpenTest-Driven Development 用法
+
+当用户想“以测试驱动开发”，或需求包含前端交互、登录、表单、权限、API、数据写入、跨页面流程或高风险行为时，OpenTest 必须前置到 build 之前：
+
+```text
+需求 / OpenSuper design
+  -> opentest plan    # 隐性场景挖掘 + acceptance-to-test matrix
+  -> opentest author  # 测试资产 / 自然语言验收用例
+  -> build            # 按矩阵实现
+  -> opentest run     # unit / integration / smoke / e2e 命令
+  -> opentest accept  # 真实页面、API 或链路验收
+  -> opentest verify  # 质量门报告
+```
+
+`plan` 阶段不能只复述需求。它必须主动检查：
+
+- 主路径、失败路径、边界输入、空数据、权限、网络、重复提交、并发或过期状态。
+- 前端反馈位置：字段下方、表单顶部、轻提示、模态框、行内状态、页面错误态。
+- 证据分层：unit、component、integration、contract、E2E、smoke、visual/browser acceptance、security/review。
+- 哪些证据是必需，哪些是不适用，哪些是 gap 或 risk-accepted 候选。
+
+实现完成后，`OpenSuper verify` 可以引用 OpenTest 的 verification report，但不能替代 OpenTest 的矩阵、运行记录和验收证据。
+
+## Loop Handoff 衔接
+
+OpenTest 每完成 `plan`、`author`、`run`、`accept`、`verify` 任一阶段后，应更新 `docs/loop-handoff/latest.md`，至少记录 `.opentest.yaml` 路径、当前阶段、测试资产路径、已运行验证、未运行验证、失败/阻塞和下一步。
+
+`opentest-verify` 生成的 verification report 路径必须写入 handoff，方便 OpenSuper verify 或新会话恢复时直接引用。

package/assets/skills-zh/opentest/references/acceptance-evidence.md

@@ -0,0 +1,27 @@
+# 验收证据
+
+自然语言验收用例必须包含：
+
+- ID
+- 意图
+- 背景
+- 执行角色
+- 触发/输入
+- 操作步骤
+- 期望结果
+- UI 反馈相关场景的期望反馈位置
+- 执行界面
+- 证据状态
+- 产物或观察备注
+
+允许的证据状态：
+
+- pending
+- pass
+- fail
+- blocked
+- risk-accepted
+
+`blocked` 证据必须包含原因，例如 MCP 不可用、环境不可用、缺少 seed data、需要认证，或外部服务失败。
+
+UI 反馈证据应记录反馈实际出现的位置和形态，例如字段级行内错误、表单级警告、轻提示、模态框、页面级错误面板、禁用控件、加载指示或重试操作。

package/assets/skills-zh/opentest/references/codex-harness-coverage-heuristics.md

@@ -0,0 +1,83 @@
+# Codex Harness 覆盖启发参考
+
+## 用途
+
+本文件随 OpenTest 分发，用于给 `/opentest-plan` 和 `/opentest-accept` 提供轻量覆盖启发。它不是强制清单，也不是 Codex Harness 全量内容副本。
+
+OpenTest 应根据变更类型、风险和项目事实选择适用覆盖面。适用但缺少证据的点应记录为 `gap`；不适用的点应在覆盖摘要中说明，不需要展开用例。
+
+## 来源
+
+本参考从本地 Codex Harness 知识库中抽取短规则，主要对应：
+
+- `tdd-workflow`
+- `e2e-runner`
+- `browser-e2e-testing`
+- `verification-loop`
+- `code-reviewer`
+- `speckit-checklist`
+
+## 选择规则
+
+| 变更类型 | 默认考虑的证据 |
+| --- | --- |
+| 纯函数、工具函数、状态计算 | unit 证据 |
+| 服务、模块协作、数据库读写 | integration 证据 |
+| API、契约、错误处理 | contract、integration、error 证据 |
+| 前端渲染或交互 | UI 验收，必要时 component 或 E2E 证据 |
+| 权限、支付、安全、数据写入、跨页面闭环 | high-risk 验收或 E2E 证据 |
+| 文案、配置、小范围无行为变更 | targeted review 或轻量证据 |
+
+## 前端验收维度
+
+前端或真实链路验收可从以下维度中选择适用项，不要求每次全部覆盖：
+
+| 维度 | 含义 |
+| --- | --- |
+| D1 页面渲染 | 标题、文案、结构、主要元素存在 |
+| D2 交互功能 | 点击、输入、选择、弹窗、菜单 |
+| D3 数据展示 | API 数据、格式化、状态展示 |
+| D4 表单验证 | 必填、格式、边界、关联校验 |
+| D5 导航流转 | 菜单、链接、返回、跨页面传参 |
+| D6 状态管理 | 加载状态、空状态、错误状态、重试 |
+| D7 权限控制 | 角色、路由守卫、越权拦截 |
+| D8 UI 反馈 | 轻提示、模态框、加载指示 |
+| D9 组件联动 | 筛选、tab、数量、级联变化 |
+| D10 边界情况 | 空数据、长文本、特殊输入、前置数据缺失 |
+
+## 隐性场景默认挖掘
+
+OpenTest plan 阶段默认检查以下问题；适用则进入矩阵，不适用则简短说明：
+
+| 类别 | 默认追问 |
+| --- | --- |
+| 输入为空 | 空字段是否阻止提交，错误显示在字段下方还是表单顶部 |
+| 输入非法 | 格式、长度、范围、重复值、依赖字段如何反馈 |
+| 网络失败 | 是否显示网络错误、重试入口，是否保留用户输入 |
+| 服务端失败 | 4xx/5xx 是否区分，是否避免泄露技术细节 |
+| 认证/会话 | token 过期、未登录、已登录访问登录页如何处理 |
+| 权限不足 | 操作隐藏、禁用还是显示权限说明 |
+| 重复提交 | 提交中按钮状态、防重复请求、幂等或冲突处理 |
+| 空数据 | 初始无数据和筛选无结果是否区分 |
+| 长内容/大数据 | 分页、截断、虚拟化、长文本和极端数量 |
+| 移动端 | 键盘遮挡、触控目标、窄屏布局和返回路径 |
+| 可访问性 | 键盘路径、焦点、错误关联、屏幕阅读器提示 |
+| 安全 | 敏感信息、越权、注入、CSRF/重复操作风险 |
+
+## 输出约束
+
+`/opentest-plan` 应优先输出窄矩阵：
+
+```markdown
+| ID | 意图 | 风险 | 必需证据 | 状态 |
+| --- | --- | --- | --- | --- |
+| ACC-001 | 用户保存后看到成功反馈 | medium | UI 验收 | pending |
+```
+
+只有当风险或变更类型需要时，才增加覆盖维度、命令、证据路径和阻塞原因列。
+
+## 质量门启发
+
+验证建议按 build、type、lint、test、security、diff 的顺序组织。构建、类型、lint、必需测试或必需验收失败时应阻塞通过；非必需证据缺口可以作为可解释风险记录。
+
+工具、环境、前置数据或 MCP 不可用时，记录 `blocked` 证据，不得声称验收通过。

package/assets/skills-zh/opentest/references/command-routing.md

@@ -0,0 +1,9 @@
+# OpenTest 命令路由
+
+`/opentest` 是唯一自动路由入口。
+
+如果 `.opentest.yaml` 缺失，初始化它并设置 `phase: plan`。
+
+路由入口不直接写测试，也不直接运行产品验证。它只检测状态并调用下一阶段 skill。
+
+当 metadata 与文件冲突时，优先相信可验证文件，并修复 `.opentest.yaml`。

package/assets/skills-zh/opentest/references/lifecycle.md

@@ -0,0 +1,16 @@
+# OpenTest 生命周期
+
+## 阶段
+
+`plan -> author -> run -> accept -> verify -> archive`
+
+`heal` 是失败恢复阶段，只在测试资产过期或验收执行路径失效时进入。
+
+## 退出条件
+
+- plan: `docs/opentest/plans/*.md` 和 `docs/opentest/matrices/*.md` 存在。
+- author: 必需测试资产或验收用例存在，或缺口已明确记录。
+- run: 运行报告存在，并记录命令、退出码和摘要。
+- accept: 必需验收证据为 pass，或 blocked 且包含原因。
+- verify: 验证报告存在，result 为 pass、fail 或 risk-accepted。
+- archive: verification 通过后，archive 才能标记完成。

package/assets/skills-zh/opentest/references/matrix-format.md

@@ -0,0 +1,27 @@
+# 验收到测试矩阵格式
+
+## 最小列
+
+| ID | 意图 | 触发/输入 | 期望行为 | 风险 | 证据层级 | 必需证据 | 状态 |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+
+## 可选列
+
+- 覆盖面
+- 命令
+- 证据路径
+- 阻塞原因
+- 风险接受说明
+
+只有风险或变更类型需要时，才增加可选列。
+
+## 证据层级
+
+- `unit`：纯函数、校验规则、状态计算。
+- `component`：表单反馈、按钮状态、局部 UI 状态。
+- `integration`：模块协作、API client、状态管理、mock server。
+- `contract`：请求/响应字段、错误码、权限响应。
+- `e2e`：跨页面、登录、权限、关键业务闭环。
+- `smoke`：关键页面或主路径不崩。
+- `browser-acceptance`：真实浏览器交互、反馈位置、响应式和视觉状态。
+- `security-review`：权限、敏感信息、越权、重复提交、注入风险。

package/assets/skills-zh/opentest/references/opentest-driven-development.md

@@ -0,0 +1,48 @@
+# OpenTest 驱动开发
+
+## 定位
+
+OpenTest 驱动开发不是传统 TDD 的替代名词。它把 TDD 放进更大的质量证据链里：先做隐性场景挖掘和风险矩阵，再决定哪些用 unit/component/integration/contract/E2E/smoke/browser acceptance/security review 证明。
+
+## 为什么不是只写 TDD
+
+传统 TDD 容易只覆盖显性需求和 happy path。真实产品行为还包括：
+
+- 空输入、非法输入和字段依赖。
+- 网络失败、服务端失败、认证过期和权限不足。
+- 错误反馈到底显示在字段下方、表单顶部、轻提示、模态框还是页面错误区。
+- 加载状态、空状态、重试、禁用、提交中、长内容、移动端。
+- 跨页面跳转、返回恢复、数据刷新和重复提交。
+
+这些场景需要先进入验收到测试矩阵，再决定证据层级。
+
+## 推荐顺序
+
+```text
+需求 / OpenSuper design
+  -> OpenTest plan: 隐性场景 + 风险 + 证据层级
+  -> OpenTest author: 测试资产和自然语言验收
+  -> build: 按矩阵实现
+  -> OpenTest run: 跑项目命令
+  -> OpenTest accept: 真实验收
+  -> OpenTest verify: 质量门报告
+  -> OpenSuper verify/archive
+```
+
+## 登录示例
+
+| ID | 意图 | 触发/输入 | 期望行为 | 风险 | 证据层级 | 必需证据 | 状态 |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| ACC-001 | 正确账号登录成功 | 合法账号密码 | 跳转目标页并建立会话 | high | e2e | 登录流程验收 | pending |
+| ACC-002 | 用户名为空 | 空用户名 + 任意密码 | 用户名字段下方错误，不发请求 | medium | component | 表单测试或 UI 验收 | pending |
+| ACC-003 | 密码错误 | 正确用户名 + 错误密码 | 表单顶部或密码区域显示认证失败，保留用户名 | high | integration | API mock + UI 验收 | pending |
+| ACC-004 | 网络断开 | 登录请求网络失败 | 显示网络错误和重试，不误报密码错误 | high | e2e | 网络失败验收 | pending |
+| ACC-005 | 重复点击提交 | 请求中再次点击 | 按钮进入加载状态且不重复提交 | medium | component | UI 状态测试 | pending |
+| ACC-006 | token 过期 | 访问受保护页面 | 回登录页并保留来源路径 | high | e2e | 会话过期验收 | pending |
+
+## 输出要求
+
+- 每个 required 场景必须有证据层级和执行面。
+- blocked 不能直接等于 pass；必须写原因和恢复路径。
+- high-risk 场景缺证据默认 fail，除非用户明确接受风险并写明理由。
+- 产品行为失败不能通过 heal 掩盖，必须回到实现或需求修正。