@pzy560117/opentest 0.1.8 → 0.1.10

package/assets/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.1.8",
+  "version": "0.1.10",
   "languages": [
     {
       "id": "en",

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

@@ -25,3 +25,17 @@ Allowed evidence status:
 Blocked evidence must include a reason such as unavailable MCP, unavailable environment, missing seed data, auth requirement, or external service failure.
 
 UI feedback evidence should record the actual location and shape of feedback, for example field-level inline error, form-level alert, toast, modal, page-level error panel, disabled control, loading indicator, or retry action.
+
+## Case Granularity Rules
+
+Acceptance matrices must distinguish render validation, functional validation, and side-effect validation. Do not treat "the screen can open" as complete acceptance.
+
+- Render validation: confirm that the entry point, dialog, form, list, or key control renders in the real page.
+- Functional validation: confirm that the business result actually takes effect after the user completes the key action.
+- Side-effect validation: confirm that dialogs, overlays, loading states, disabled states, toasts, or error states do not remain and mislead the next action.
+
+Any case with form submission, create, edit, delete, upload, authorization, state transition, or another write operation must include the full "fill/input -> submit/confirm -> verify result took effect" chain. Examples:
+
+- Address form can open (render validation).
+- User can fill and submit the form, and the new address appears in the list or detail view (functional validation).
+- After submission, the dialog closes, no overlay or stale loading state remains, and the next action is still usable (side-effect validation).

package/assets/skills/opentest/references/complete-testing-workflow.md

@@ -8,6 +8,12 @@ Use this reference only when the phase skill asks for detailed coverage rules.
 plan -> matrix -> fixtures -> tests -> run -> accept -> smoke -> pre-push -> verify -> archive
 ```
 
+## Requirement-First Acceptance
+
+`plan` and `author` happen before implementation and must turn requirements into acceptance contracts. Use requirements, design notes, user workflows, business rules, and risk boundaries as sources. Use current code only to discover execution facts such as commands, existing frameworks, routes, fixtures, and reusable helpers.
+
+Unit, component, integration, contract, E2E, smoke, and browser acceptance are evidence layers. They describe how to prove a requirement after or during implementation; they do not decide what the requirement is. If code does not exist yet, keep the acceptance case and mark code-dependent evidence as pending or blocked with a reason.
+
 ## Test Data
 
 Create `docs/opentest/fixtures/` for changes that touch data, files, roles, permissions, APIs, or stateful workflows.
@@ -36,6 +42,21 @@ For persisted data, APIs, forms, files, or stateful flows, include these matrix
 
 If a leg is not applicable, record why in `gap/blocker`.
 
+## Interaction Acceptance Hard Rules
+
+When Playwright CLI, browser MCP, or manual real-page acceptance executes CRUD, form submission, file upload, authorization, state transition, or another write operation, it must include post-submit assertions. Screenshots or "the page did not crash" are not enough.
+
+Recommended execution chain:
+
+```text
+open -> snapshot -> fill/input -> click(submit/confirm) -> snapshot -> read/assert changed result -> screenshot -> PASS/FAIL
+```
+
+- Read-after-write validation: after submission, re-read at least one trustworthy result surface such as the page, list, detail view, API response, storage record, or logs, and confirm the value changed.
+- Dialog/overlay validation: after a successful write, assert that the dialog closes, overlay is removed, loading stops, button state recovers, and the next action is usable.
+- Failure-path validation: for validation failure, permission failure, or network/API errors, assert the feedback location, input retention strategy, and recovery path.
+- Evidence recording: PASS must state the changed result that was asserted. If no result surface can be read, mark the evidence as `blocked` or `risk-accepted` and record why.
+
 ## Run Gates
 
 - targeted: evidence linked to changed matrix rows

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

@@ -2,8 +2,10 @@
 
 ## Minimal Columns
 
-| ID | Intent | Trigger/Input | Expected behavior | Risk | Evidence layer | Required evidence | Status |
-| --- | --- | --- | --- | --- | --- | --- | --- |
+| ID | Requirement source | Intent | Trigger/Input | Expected behavior | Risk | Evidence layer | Required evidence | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+
+`Requirement source` is mandatory. Use a requirement ID, design section, user story, business rule, risk note, issue, or explicit user request. Do not use a function name, component path, or existing test file as the source of acceptance.
 
 ## Optional Columns
 
@@ -17,6 +19,8 @@ Only add optional columns when risk or change type needs them.
 
 ## Evidence Layers
 
+Evidence layers describe how a requirement will be proven. They do not create or limit requirements.
+
 - `unit`: pure functions, validation rules, state calculation.
 - `component`: form feedback, button states, local UI states.
 - `integration`: module collaboration, API client, state management, mock server.

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

@@ -16,6 +16,14 @@ Traditional TDD can easily cover only explicit requirements and happy paths. Rea
 
 These scenarios should enter the acceptance-to-test matrix before evidence layers are selected.
 
+## Requirement-First Contract
+
+OpenTest `plan` and `author` phases produce a requirement acceptance contract before implementation. Acceptance cases must come from requirements, design notes, user workflows, business rules, risk boundaries, and expected interaction feedback.
+
+Current code may be inspected to discover project facts such as existing test frameworks, commands, routes, fixtures, or reusable helpers. Current code must not decide whether a requirement is accepted, which user-visible behavior is required, or whether a requirement can be dropped.
+
+Evidence layers such as `unit`, `component`, `integration`, `contract`, or `e2e` describe how the requirement will be proven after or during implementation. They are not requirement sources. If no code exists yet, the matrix still records the required behavior and marks implementation-dependent evidence as pending.
+
 ## Recommended Order
 
 ```text
@@ -42,6 +50,8 @@ Requirement / OpenSuper design
 
 ## Output Requirements
 
+- Every matrix row must cite a requirement source, such as a requirement ID, design section, user story, business rule, risk note, or explicit user request.
+- Acceptance wording must be implementation-independent: describe user-observable behavior and business result, not current function names, component internals, or existing test files.
 - Every required scenario must have an evidence layer and execution surface.
 - blocked is not pass; it must include a reason and recovery path.
 - Missing evidence for high-risk scenarios defaults to fail unless the user explicitly accepts the risk and the reason is written down.

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

@@ -1,13 +1,13 @@
 # Acceptance-to-Test Matrix
 
-| ID | Intent | Coverage dimension | Trigger/Input | Expected behavior | Risk | Evidence layer | Framework/command | Required evidence | Gap/blocker | Status |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| ACC-001 | create succeeds | create | valid fixture entity | entity is created and visible in list/detail | high | integration + acceptance | `python -m pytest` + real workflow | create evidence, UI/API/DB assertion, fixture used | none | pending |
-| ACC-002 | read/list/detail succeeds | read/list/detail | seeded entity | list, search/filter, and detail show correct data | high | integration + acceptance | `python -m pytest` + real workflow | read/list/detail evidence and data consistency check | none | pending |
-| ACC-003 | update succeeds | update | edited fixture entity | updated values persist after read back | high | integration + acceptance | `python -m pytest` + real workflow | update evidence and read-back assertion | none | pending |
-| ACC-004 | delete succeeds safely | delete | existing fixture entity | confirm/cancel behavior works; deleted item disappears after confirmation | high | integration + acceptance | `python -m pytest` + real workflow | delete evidence, cancel evidence, post-delete read check | none | pending |
-| ACC-005 | failure and boundary paths are handled | failure/boundary | invalid, empty, duplicate, unauthorized, or stale fixture data | clear feedback without corrupting data | high | unit/integration/acceptance | `python -m pytest` + acceptance | validation, permission, duplicate, stale-state evidence | none | pending |
-| ACC-006 | data consistency holds | data consistency | create/update/delete flow | UI, API, database/storage, files, and logs agree | high | integration | project command or `python -m pytest` | consistency evidence across surfaces | none | pending |
-| ACC-007 | end-to-end CRUD flow works | end-to-end CRUD | create -> list -> detail -> update -> read back -> delete | full user workflow completes and leaves clean state | high | E2E/acceptance | browser/API workflow | full-chain steps, screenshots/logs, cleanup evidence | none | pending |
-| ACC-008 | smoke gate passes | smoke | app starts and core entry points open | core route/API/CRUD happy path does not crash | high | smoke | project smoke command or targeted workflow | smoke_report path | none | pending |
-| ACC-009 | pre-push gate passes | pre-push | staged change before push | format/lint/type/unit/integration/smoke/diff checks pass or block push | high | pre-push | project command sequence | pre_push_report path | none | pending |
+| ID | Requirement source | Intent | Coverage dimension | Trigger/Input | Expected behavior | Risk | Evidence layer | Framework/command | Required evidence | Gap/blocker | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| ACC-001 | REQ-001 / user story | create succeeds | create | valid fixture entity | entity is created and visible in list/detail | high | integration + acceptance | `python -m pytest` + real workflow | create evidence, UI/API/DB assertion, fixture used | none | pending |
+| ACC-002 | REQ-001 / design list view | read/list/detail succeeds | read/list/detail | seeded entity | list, search/filter, and detail show correct data | high | integration + acceptance | `python -m pytest` + real workflow | read/list/detail evidence and data consistency check | none | pending |
+| ACC-003 | REQ-002 / edit workflow | update succeeds | update | edited fixture entity | updated values persist after read back | high | integration + acceptance | `python -m pytest` + real workflow | update evidence and read-back assertion | none | pending |
+| ACC-004 | REQ-003 / delete rule | delete succeeds safely | delete | existing fixture entity | confirm/cancel behavior works; deleted item disappears after confirmation | high | integration + acceptance | `python -m pytest` + real workflow | delete evidence, cancel evidence, post-delete read check | none | pending |
+| ACC-005 | Risk: invalid and unauthorized input | failure and boundary paths are handled | failure/boundary | invalid, empty, duplicate, unauthorized, or stale fixture data | clear feedback without corrupting data | high | unit/integration/acceptance | `python -m pytest` + acceptance | validation, permission, duplicate, stale-state evidence | none | pending |
+| ACC-006 | Business rule: data consistency | data consistency holds | data consistency | create/update/delete flow | UI, API, database/storage, files, and logs agree | high | integration | project command or `python -m pytest` | consistency evidence across surfaces | none | pending |
+| ACC-007 | User workflow: full CRUD | end-to-end CRUD flow works | end-to-end CRUD | create -> list -> detail -> update -> read back -> delete | full user workflow completes and leaves clean state | high | E2E/acceptance | browser/API workflow | full-chain steps, screenshots/logs, cleanup evidence | none | pending |
+| ACC-008 | Quality gate requirement | smoke gate passes | smoke | app starts and core entry points open | core route/API/CRUD happy path does not crash | high | smoke | project smoke command or targeted workflow | smoke_report path | none | pending |
+| ACC-009 | Delivery gate requirement | pre-push gate passes | pre-push | staged change before push | format/lint/type/unit/integration/smoke/diff checks pass or block push | high | pre-push | project command sequence | pre_push_report path | none | pending |

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

@@ -17,8 +17,9 @@ Turn the matrix into executable tests, fixtures, seed/teardown notes, and accept
 ## Steps
 
 1. Read `matrix` and `fixtures` from `.opentest.yaml`.
-2. For code evidence, use the project framework; if none exists, Default to pytest with tests under `tests/` runnable by `python -m pytest`.
-3. Create/update fixtures, seed, teardown, users, roles, entities, files/images, and assertion surfaces.
-4. For CRUD/data changes, author the full acceptance flow: create -> list -> detail -> update -> read back -> delete -> confirm absence -> teardown.
-5. Record any gap/blocker with reason and risk.
-6. Write `.opentest.yaml` fields: `fixtures`, `acceptance`, then run `bash "$OPENTEST_GUARD" author --apply`.
+2. Preserve each row's requirement source and expected behavior. Do not rewrite acceptance cases around current implementation names, component internals, or existing test files.
+3. For code evidence, use the project framework; if none exists, default to pytest with tests under `tests/` runnable by `python -m pytest`. Missing implementation means evidence stays pending; it does not remove the requirement acceptance case.
+4. Create/update fixtures, seed, teardown, users, roles, entities, files/images, and assertion surfaces.
+5. For CRUD/data changes, author the full acceptance flow: create -> list -> detail -> update -> read back -> delete -> confirm absence -> teardown.
+6. Record any gap/blocker with reason and risk.
+7. Write `.opentest.yaml` fields: `fixtures`, `acceptance`, then run `bash "$OPENTEST_GUARD" author --apply`.

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

@@ -15,13 +15,13 @@ Create `docs/opentest/plans/`, `docs/opentest/matrices/`, and a fixtures plan be
 
 ## Steps
 
-1. Read project rules, requirements/design/diff, existing commands, and detection output.
-2. Classify risk, applicable coverage, test data, and whether code tests use an existing framework or default `pytest`.
+1. Read project rules, requirements/design/user request/diff, existing commands, and detection output.
+2. Treat requirements, design, user workflows, business rules, and risk notes as acceptance sources. Inspect current code only for project facts such as commands, routes, test framework, fixtures, or reusable helpers.
 3. Apply the CRUD baseline and test data requirements from the workflow reference for data-writing/API/form/file/stateful changes.
-4. Produce a matrix with coverage dimension, framework/command, required evidence, gap/blocker, and status.
+4. Produce a requirement-first matrix with requirement source, user-observable expected behavior, coverage dimension, framework/command, required evidence, gap/blocker, and status.
 5. Write `.opentest.yaml` fields: `plan`, `matrix`, `fixtures`.
 6. Update handoff if present, then run `bash "$OPENTEST_GUARD" plan --apply`.
 
 ## Gate
 
-Every applicable behavior, failure path, boundary, and risk surface needs evidence or a written gap/blocker. CRUD baseline and test data are default requirements unless the matrix says why they are not applicable.
+Every applicable behavior, failure path, boundary, and risk surface needs evidence or a written gap/blocker. Every matrix row must cite a requirement source. Do not drop or narrow acceptance because current code has no matching function, component, API, or test file. CRUD baseline and test data are default requirements unless the matrix says why they are not applicable.

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

@@ -25,3 +25,17 @@
 `blocked` 证据必须包含原因，例如 MCP 不可用、环境不可用、缺少 seed data、需要认证，或外部服务失败。
 
 UI 反馈证据应记录反馈实际出现的位置和形态，例如字段级行内错误、表单级警告、轻提示、模态框、页面级错误面板、禁用控件、加载指示或重试操作。
+
+## 用例粒度规则
+
+验收矩阵必须区分渲染验证、功能验证和副作用验证，不能把“界面能打开”当成完整验收。
+
+- 渲染验证：确认入口、弹窗、表单、列表或关键控件能被真实页面渲染出来。
+- 功能验证：确认用户完成关键操作后，业务结果真实生效。
+- 副作用验证：确认操作完成后的弹窗、遮罩、loading、禁用态、toast 或错误态不会残留或误导下一步操作。
+
+凡是有表单提交、创建、编辑、删除、上传、授权、状态流转或其他写操作的用例，必须包含“填写/输入 -> 提交/确认 -> 验证结果生效”的完整链路。示例：
+
+- 地址表单能打开（渲染验证）。
+- 能填写表单并提交，新地址出现在列表或详情中（功能验证）。
+- 提交后弹窗关闭，页面无遮罩、无残留 loading，后续操作仍可继续（副作用验证）。

package/assets/skills-zh/opentest/references/complete-testing-workflow.md

@@ -8,6 +8,12 @@
 plan -> matrix -> fixtures -> tests -> run -> accept -> smoke -> pre-push -> verify -> archive
 ```
 
+## 需求先行验收
+
+`plan` 和 `author` 发生在实现前，必须把需求转成验收契约。来源只能是需求、设计说明、用户流程、业务规则和风险边界。当前代码只用于发现执行事实，例如命令、已有框架、路由、fixtures 和可复用 helper。
+
+unit、component、integration、contract、E2E、smoke、browser acceptance 都是证据层级。它们描述实现期间或实现后如何证明需求，不能决定需求是什么。如果代码还没出现，保留验收用例，并把依赖代码的证据标成 pending 或 blocked 且写明原因。
+
 ## 测试数据
 
 变更涉及数据、文件、角色、权限、API 或有状态流程时，创建 `docs/opentest/fixtures/`。
@@ -36,6 +42,21 @@ plan -> matrix -> fixtures -> tests -> run -> accept -> smoke -> pre-push -> ver
 
 不适用的环节必须在 `缺口/阻塞` 中写明原因。
 
+## 交互验收硬规则
+
+Playwright CLI、浏览器 MCP 或人工真实页面验收执行 CRUD、表单提交、文件上传、授权、状态流转等写操作时，必须包含提交后断言，不能只截图或只确认页面未崩溃。
+
+推荐执行链路：
+
+```text
+open -> snapshot -> fill/input -> click(submit/confirm) -> snapshot -> read/assert changed result -> screenshot -> PASS/FAIL
+```
+
+- 写后读验证：提交后必须重新读取页面、列表、详情、API 响应、存储记录或日志中的至少一个可信结果面，确认值已变更。
+- 弹窗/遮罩验证：写操作成功后必须断言弹窗关闭、遮罩移除、loading 停止、按钮状态恢复，且下一步可操作。
+- 失败路径验证：校验失败、权限失败、网络/API 错误时，必须断言错误反馈位置、输入保留策略和可恢复路径。
+- 证据记录：PASS 必须说明断言到的变更结果；若无法读取结果面，状态应为 `blocked` 或 `risk-accepted`，并写明原因。
+
 ## 运行质量门
 
 - targeted：与变更矩阵行相关的证据

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

@@ -2,8 +2,10 @@
 
 ## 最小列
 
-| ID | 意图 | 触发/输入 | 期望行为 | 风险 | 证据层级 | 必需证据 | 状态 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
+| ID | 需求来源 | 意图 | 触发/输入 | 期望行为 | 风险 | 证据层级 | 必需证据 | 状态 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+
+`需求来源` 是必填项。可填写需求 ID、设计章节、用户故事、业务规则、风险说明、issue 或用户明确请求。不要把函数名、组件路径或已有测试文件当成验收来源。
 
 ## 可选列
 
@@ -17,6 +19,8 @@
 
 ## 证据层级
 
+证据层级只描述如何证明需求，不能产生或限制需求本身。
+
 - `unit`：纯函数、校验规则、状态计算。
 - `component`：表单反馈、按钮状态、局部 UI 状态。
 - `integration`：模块协作、API client、状态管理、mock server。

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

@@ -16,6 +16,14 @@ OpenTest 驱动开发不是传统 TDD 的替代名词。它把 TDD 放进更大
 
 这些场景需要先进入验收到测试矩阵，再决定证据层级。
 
+## 需求先行契约
+
+OpenTest 的 `plan` 和 `author` 阶段是在实现前生成需求验收契约。验收用例必须来自需求、设计说明、用户流程、业务规则、风险边界和预期交互反馈。
+
+可以读取当前代码来发现项目事实，例如已有测试框架、命令、路由、fixtures 或可复用 helper。当前代码不能决定某个需求是否需要验收、用户可见行为应该是什么，或某个需求是否可以删除。
+
+`unit`、`component`、`integration`、`contract`、`e2e` 等证据层级只描述实现期间或实现后如何证明需求，不是需求来源。如果代码还没出现，矩阵仍然要记录必需行为，并把依赖实现的证据标为 pending。
+
 ## 推荐顺序
 
 ```text
@@ -42,6 +50,8 @@ OpenTest 驱动开发不是传统 TDD 的替代名词。它把 TDD 放进更大
 
 ## 输出要求
 
+- 每条矩阵行必须引用需求来源，例如需求 ID、设计章节、用户故事、业务规则、风险说明或用户明确请求。
+- 验收表述必须与实现无关：描述用户可观察行为和业务结果，不描述当前函数名、组件内部结构或已有测试文件。
 - 每个 required 场景必须有证据层级和执行面。
 - blocked 不能直接等于 pass；必须写原因和恢复路径。
 - high-risk 场景缺证据默认 fail，除非用户明确接受风险并写明理由。

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

@@ -1,13 +1,13 @@
 # 验收到测试矩阵
 
-| ID | 意图 | 覆盖维度 | 触发/输入 | 期望行为 | 风险 | 证据层级 | 框架/命令 | 必需证据 | 缺口/阻塞 | 状态 |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| ACC-001 | 新增成功 | 新增 | 有效 fixture 实体 | 创建成功，并能在列表/详情中看到 | high | integration + acceptance | `python -m pytest` + 真实工作流 | 新增证据、UI/API/DB 断言、使用的测试数据 | 无 | pending |
-| ACC-002 | 查询/列表/详情成功 | 查询/列表/详情 | 已 seed 的实体 | 列表、搜索/筛选、详情显示正确数据 | high | integration + acceptance | `python -m pytest` + 真实工作流 | 查询/列表/详情证据和数据一致性检查 | 无 | pending |
-| ACC-003 | 修改成功 | 修改 | 编辑 fixture 实体 | 保存后回读仍是新值 | high | integration + acceptance | `python -m pytest` + 真实工作流 | 修改证据和回读断言 | 无 | pending |
-| ACC-004 | 删除安全成功 | 删除 | 已存在 fixture 实体 | 删除确认/取消正确；确认删除后不可见 | high | integration + acceptance | `python -m pytest` + 真实工作流 | 删除证据、取消证据、删除后回读检查 | 无 | pending |
-| ACC-005 | 失败/边界路径可控 | 失败/边界 | 非法、空、重复、无权限或过期 fixture 数据 | 给出清晰反馈且不污染数据 | high | unit/integration/acceptance | `python -m pytest` + 验收 | 校验、权限、重复提交、过期状态证据 | 无 | pending |
-| ACC-006 | 数据一致性成立 | 数据一致性 | 新增/修改/删除闭环 | UI、API、数据库/存储、文件和日志一致 | high | integration | 项目命令或 `python -m pytest` | 跨界面一致性证据 | 无 | pending |
-| ACC-007 | 端到端 CRUD 链路可用 | 端到端 CRUD | 新增 -> 列表 -> 详情 -> 修改 -> 回读 -> 删除 | 完整用户链路通过并留下干净状态 | high | E2E/acceptance | 浏览器/API 工作流 | 全链路步骤、截图/日志、清理证据 | 无 | pending |
-| ACC-008 | 冒烟质量门通过 | 冒烟 | 应用启动且核心入口可访问 | 核心路由/API/CRUD 主路径不崩 | high | smoke | 项目冒烟命令或 targeted workflow | smoke_report 路径 | 无 | pending |
-| ACC-009 | pre-push 质量门通过 | pre-push | push 前 staged change | format/lint/type/unit/integration/smoke/diff 检查通过，否则阻止 push | high | pre-push | 项目命令序列 | pre_push_report 路径 | 无 | pending |
+| ID | 需求来源 | 意图 | 覆盖维度 | 触发/输入 | 期望行为 | 风险 | 证据层级 | 框架/命令 | 必需证据 | 缺口/阻塞 | 状态 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| ACC-001 | REQ-001 / 用户故事 | 新增成功 | 新增 | 有效 fixture 实体 | 创建成功，并能在列表/详情中看到 | high | integration + acceptance | `python -m pytest` + 真实工作流 | 新增证据、UI/API/DB 断言、使用的测试数据 | 无 | pending |
+| ACC-002 | REQ-001 / 列表设计 | 查询/列表/详情成功 | 查询/列表/详情 | 已 seed 的实体 | 列表、搜索/筛选、详情显示正确数据 | high | integration + acceptance | `python -m pytest` + 真实工作流 | 查询/列表/详情证据和数据一致性检查 | 无 | pending |
+| ACC-003 | REQ-002 / 编辑流程 | 修改成功 | 修改 | 编辑 fixture 实体 | 保存后回读仍是新值 | high | integration + acceptance | `python -m pytest` + 真实工作流 | 修改证据和回读断言 | 无 | pending |
+| ACC-004 | REQ-003 / 删除规则 | 删除安全成功 | 删除 | 已存在 fixture 实体 | 删除确认/取消正确；确认删除后不可见 | high | integration + acceptance | `python -m pytest` + 真实工作流 | 删除证据、取消证据、删除后回读检查 | 无 | pending |
+| ACC-005 | 风险：非法和无权限输入 | 失败/边界路径可控 | 失败/边界 | 非法、空、重复、无权限或过期 fixture 数据 | 给出清晰反馈且不污染数据 | high | unit/integration/acceptance | `python -m pytest` + 验收 | 校验、权限、重复提交、过期状态证据 | 无 | pending |
+| ACC-006 | 业务规则：数据一致性 | 数据一致性成立 | 数据一致性 | 新增/修改/删除闭环 | UI、API、数据库/存储、文件和日志一致 | high | integration | 项目命令或 `python -m pytest` | 跨界面一致性证据 | 无 | pending |
+| ACC-007 | 用户流程：完整 CRUD | 端到端 CRUD 链路可用 | 端到端 CRUD | 新增 -> 列表 -> 详情 -> 修改 -> 回读 -> 删除 | 完整用户链路通过并留下干净状态 | high | E2E/acceptance | 浏览器/API 工作流 | 全链路步骤、截图/日志、清理证据 | 无 | pending |
+| ACC-008 | 质量门需求 | 冒烟质量门通过 | 冒烟 | 应用启动且核心入口可访问 | 核心路由/API/CRUD 主路径不崩 | high | smoke | 项目冒烟命令或 targeted workflow | smoke_report 路径 | 无 | pending |
+| ACC-009 | 交付门禁需求 | pre-push 质量门通过 | pre-push | push 前 staged change | format/lint/type/unit/integration/smoke/diff 检查通过，否则阻止 push | high | pre-push | 项目命令序列 | pre_push_report 路径 | 无 | pending |

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

@@ -17,8 +17,9 @@ description: "OpenTest 阶段 2：根据矩阵补齐测试资产、fixtures 和
 ## 步骤
 
 1. 读取 `.opentest.yaml` 的 `matrix` 和 `fixtures`。
-2. 代码级证据优先用项目框架；没有框架时默认使用 pytest，测试放入 `tests/` 并可用 `python -m pytest` 运行。
-3. 创建/更新 fixtures、seed、teardown、用户、角色、实体、文件/图片和断言界面。
-4. CRUD/数据变更必须补全链路：新增 -> 列表 -> 详情 -> 修改 -> 回读 -> 删除 -> 确认消失 -> 清理。
-5. 记录 gap/blocker 的原因和风险。
-6. 写入 `.opentest.yaml` 的 `fixtures`、`acceptance`，再运行 `bash "$OPENTEST_GUARD" author --apply`。
+2. 保留每条矩阵行的需求来源和期望行为。不要围绕当前实现命名、组件内部结构或已有测试文件重写验收用例。
+3. 代码级证据优先用项目框架；没有框架时默认使用 pytest，测试放入 `tests/` 并可用 `python -m pytest` 运行。实现缺失只表示证据 pending，不能删除需求验收用例。
+4. 创建/更新 fixtures、seed、teardown、用户、角色、实体、文件/图片和断言界面。
+5. CRUD/数据变更必须补全链路：新增 -> 列表 -> 详情 -> 修改 -> 回读 -> 删除 -> 确认消失 -> 清理。
+6. 记录 gap/blocker 的原因和风险。
+7. 写入 `.opentest.yaml` 的 `fixtures`、`acceptance`，再运行 `bash "$OPENTEST_GUARD" author --apply`。

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

@@ -15,13 +15,13 @@ description: "OpenTest 阶段 1：分析变更、风险和项目事实，生成
 
 ## 步骤
 
-1. 读取项目规则、需求/设计/diff、现有命令和 detect 输出。
-2. 判断风险、适用覆盖面、测试数据，以及代码测试使用项目框架还是默认 `pytest`。
+1. 读取项目规则、需求/设计/用户请求/diff、现有命令和 detect 输出。
+2. 把需求、设计、用户流程、业务规则和风险说明当成验收来源。读取当前代码只用于发现项目事实，例如命令、路由、测试框架、fixtures 或可复用 helper。
 3. 数据写入、API、表单、文件或有状态流程默认套用 CRUD 基线和测试数据要求。
-4. 生成矩阵，包含覆盖维度、框架/命令、必需证据、缺口/阻塞和状态。
+4. 生成需求先行矩阵，包含需求来源、用户可观察期望行为、覆盖维度、框架/命令、必需证据、缺口/阻塞和状态。
 5. 写入 `.opentest.yaml` 的 `plan`、`matrix`、`fixtures`。
 6. 如存在 handoff，同步 plan/matrix/fixtures 路径，然后运行 `bash "$OPENTEST_GUARD" plan --apply`。
 
 ## 质量门
 
-每个适用行为、失败路径、边界和风险面都要有证据或明确 gap/blocker。CRUD 基线和测试数据默认必需；不适用时必须在矩阵写明原因。
+每个适用行为、失败路径、边界和风险面都要有证据或明确 gap/blocker。每条矩阵行都必须引用需求来源。不得因为当前代码没有对应函数、组件、API 或测试文件就删除或缩小验收。CRUD 基线和测试数据默认必需；不适用时必须在矩阵写明原因。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pzy560117/opentest",
-  "version": "0.1.8",
+  "version": "0.1.10",
   "description": "OpenTest quality evidence lifecycle skills for Codex",
   "keywords": [
     "opentest",

package/scripts/smoke-test.js

@@ -182,7 +182,7 @@ function assertDefaultPytestContracts() {
   assert(stateScript.includes('test_framework|'), '[PYTEST] state script must allow test_framework field updates');
   assert(detectScript.includes('default_test_framework: pytest'), '[PYTEST] detect summary must report pytest as default framework');
   assert(detectScript.includes('pytest_command:'), '[PYTEST] detect summary must report pytest command status');
-  assert(englishAuthor.includes('Default to pytest'), '[PYTEST] English author skill must default missing framework to pytest');
+  assert(englishAuthor.includes('default to pytest'), '[PYTEST] English author skill must default missing framework to pytest');
   assert(chineseAuthor.includes('默认使用 pytest'), '[PYTEST] Chinese author skill must default missing framework to pytest');
   assert(englishRun.includes('python -m pytest'), '[PYTEST] English run skill must document pytest command');
   assert(chineseRun.includes('python -m pytest'), '[PYTEST] Chinese run skill must document pytest command');
@@ -192,6 +192,34 @@ function assertDefaultPytestContracts() {
   assert(chineseMatrix.includes('覆盖维度') && chineseMatrix.includes('框架/命令') && chineseMatrix.includes('缺口/阻塞'), '[COVERAGE] Chinese matrix template must include coverage, command, and gap columns');
 }
 
+function assertRequirementFirstAcceptanceContracts() {
+  const englishWorkflow = readFileSync('assets/skills/opentest/references/complete-testing-workflow.md', 'utf8');
+  const chineseWorkflow = readFileSync('assets/skills-zh/opentest/references/complete-testing-workflow.md', 'utf8');
+  const englishDriven = readFileSync('assets/skills/opentest/references/opentest-driven-development.md', 'utf8');
+  const chineseDriven = readFileSync('assets/skills-zh/opentest/references/opentest-driven-development.md', 'utf8');
+  const englishMatrixFormat = readFileSync('assets/skills/opentest/references/matrix-format.md', 'utf8');
+  const chineseMatrixFormat = readFileSync('assets/skills-zh/opentest/references/matrix-format.md', 'utf8');
+  const englishPlan = readFileSync('assets/skills/opentest-plan/SKILL.md', 'utf8');
+  const chinesePlan = readFileSync('assets/skills-zh/opentest-plan/SKILL.md', 'utf8');
+  const englishAuthor = readFileSync('assets/skills/opentest-author/SKILL.md', 'utf8');
+  const chineseAuthor = readFileSync('assets/skills-zh/opentest-author/SKILL.md', 'utf8');
+  const englishMatrix = readFileSync('assets/skills/opentest/templates/matrix-template.md', 'utf8');
+  const chineseMatrix = readFileSync('assets/skills-zh/opentest/templates/matrix-template.md', 'utf8');
+
+  assert(englishDriven.includes('Requirement-First Contract'), '[REQFIRST] English driven-development reference must define requirement-first contract');
+  assert(chineseDriven.includes('需求先行契约'), '[REQFIRST] Chinese driven-development reference must define requirement-first contract');
+  assert(englishWorkflow.includes('Requirement-First Acceptance'), '[REQFIRST] English workflow must include requirement-first acceptance gate');
+  assert(chineseWorkflow.includes('需求先行验收'), '[REQFIRST] Chinese workflow must include requirement-first acceptance gate');
+  assert(englishMatrixFormat.includes('Requirement source') && englishMatrixFormat.includes('Do not use a function name'), '[REQFIRST] English matrix format must require requirement source and reject implementation-derived sources');
+  assert(chineseMatrixFormat.includes('需求来源') && chineseMatrixFormat.includes('不要把函数名'), '[REQFIRST] Chinese matrix format must require requirement source and reject implementation-derived sources');
+  assert(englishMatrix.includes('Requirement source') && englishMatrix.includes('REQ-001'), '[REQFIRST] English matrix template must include requirement source examples');
+  assert(chineseMatrix.includes('需求来源') && chineseMatrix.includes('REQ-001'), '[REQFIRST] Chinese matrix template must include requirement source examples');
+  assert(englishPlan.includes('current code only for project facts') && englishPlan.includes('Do not drop or narrow acceptance'), '[REQFIRST] English plan skill must prevent implementation-derived acceptance');
+  assert(chinesePlan.includes('读取当前代码只用于发现项目事实') && chinesePlan.includes('不得因为当前代码没有对应函数'), '[REQFIRST] Chinese plan skill must prevent implementation-derived acceptance');
+  assert(englishAuthor.includes('Missing implementation means evidence stays pending'), '[REQFIRST] English author skill must keep requirements when implementation is missing');
+  assert(chineseAuthor.includes('实现缺失只表示证据 pending'), '[REQFIRST] Chinese author skill must keep requirements when implementation is missing');
+}
+
 function assertCompleteTestingWorkflowContracts() {
   const stateScript = readFileSync('assets/skills/opentest/scripts/opentest-state.sh', 'utf8');
   const detectScript = readFileSync('assets/skills/opentest/scripts/opentest-detect.sh', 'utf8');
@@ -575,6 +603,7 @@ runManifestPathRelativitySelfCheck();
 assertManifestStructure();
 assertPrepublishGateCoversManifestAssets();
 assertDefaultPytestContracts();
+assertRequirementFirstAcceptanceContracts();
 assertCompleteTestingWorkflowContracts();
 assertProgressiveDisclosureContracts();
 assertOpenTestSearchRootsCoverPlatforms();