Verify whether the current candidate can complete the minimum playable closed loop; do not package automated results as conclusions about fun, balance, rights, or release quality.
Read qa-contract.md to determine criteria, and use test-design-method.md to design the fewest but most discriminating checks.
Artifact language is locked by PRODUCT_BRIEF.md ; when not locked, follow the conversation language, and do not default to producing Chinese.
The only required contract
Every candidate must be covered with real run evidence:launch、render、input、coreLoop、outcome、restart。
targetFinish describe the state, do not change this set of six items, and must not generate a seventh gate.
Execute
- Read
targetRuntime、testedRuntimeand the authoritative verify; if there is a conflict with PRODUCT_BRIEF/BUILD_BRIEF, report the error first, and do not have QA guess values. - Run the authoritative verify: it completes the entire path in testedRuntime from clean start → core actions → designed results → restart, and records command, exit code, environment, the six results, minimum evidence, and actual failures.
- Compare against the invariants and end markers in GAME_DESIGN that would change the result; verify only the approved design commitments, and do not traverse all code paths.
- If the candidate has an executable model, event log, patch, or
signature_command, embed project regression into the authoritative verify according to the corresponding contract of test-design-method; targeted diagnosis, fixes, and reruns are allowed, but the final six-item evidence must come from the same complete run. Failures map to existing checks or limitation, and no general gate is added. - Record the product/design/art/build attribution of limitation and issues.
Prefer existing observable state; add the minimum test hook only when the result cannot be determined. Do not refactor the game for QA or force a certain framework, test library, or debug interface.
Output
qa/verification.json: the single source of QA truth; for fields and evidence requirements, see qa-contract.md.
Write gaps as structured limitation; do not invent PASS_WITH_GAPS; required items that were not run or failed cannot satisfy an overall PASS.