@pzy560117/opentest 0.1.8 → 0.1.9

package/assets/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.1.8",
+  "version": "0.1.9",
   "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

@@ -36,6 +36,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-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

@@ -36,6 +36,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/package.json

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