Verify whether the current candidate can complete the minimum playable loop, and do not package automated results as conclusions about fun, balance, rights, or release quality.
Read qa-contract.md to determine the criteria, and design the minimum but discriminating checks according to test-design-method.md .
The 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 runtime evidence:launch、render、input、coreLoop、outcome、restart。
targetFinish describes the state, does not change this set of six items, and must not generate a seventh gate.
Execution
- Read
targetRuntime、testedRuntimeand the authoritative verify; when it conflicts with PRODUCT_BRIEF/BUILD_BRIEF, report the error first, and do not let QA guess the value. - Run the authoritative verify: it completes the entire path in testedRuntime from clean start → core action → designed result → restart, and records the command, exit code, environment, 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 the 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 new general gate is added. - Record the limitation and the product/design/art/build attribution of the issue.
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 only source of QA truth; for fields and evidence requirements, see qa-contract.md.
Write gaps as structured limitation, and do not invent PASS_WITH_GAPS; required items that were not run or that failed cannot satisfy an overall PASS.