@pzy560117/opentest 0.1.9 → 0.1.10

package/assets/manifest.json

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

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.

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/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/`。

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.9",
+  "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();