interface:
  display_name: "Game QA"
  short_description: "Verify the game runs and can be completed · 验证生成游戏能否完整运行和游玩"
  default_prompt: "Use $game-qa to test this generated game on its selected target runtime and report blocking issues."

# 质量验证契约

本契约只规定什么结论需要什么证据。测试框架、调试接口和实现结构由项目决定。

## 状态与事实源

状态只取 `NOT_RUN` / `FAIL` / `PASS`。未验证不是通过，安全失败也不是成功降级。

`qa/verification.json` schema v3 恰好使用以下顶层字段，`checks` 恰好只含六键：

```json
{
  "schemaVersion": 3,
  "status": "PASS",
  "verify": {"command": "<权威命令>", "exitCode": 0},
  "completeRun": {
    "id": "main-path",
    "cleanContext": true,
    "terminal": "designed-outcome",
    "restart": "initial-state",
    "evidence": "qa/evidence/run.json"
  },
  "checks": {
    "launch": "PASS", "render": "PASS", "input": "PASS",
    "coreLoop": "PASS", "outcome": "PASS", "restart": "PASS"
  },
  "limitations": [
    {"scope": "target device", "reason": "not available"}
  ]
}
```

`completeRun.evidence` 指向非空的 JSON 观察清单。清单只保存事实，不复制 command、exitCode 或
六项 PASS/FAIL：`schemaVersion: 1`、与 `completeRun.id` 相同的 `runId`、非空 `environment`、
非空 `inputTrace`，以及恰好包含六键的 `observations`。每项观察含非空 `id`、实际 `inputs` 和
`state`；`render.visual` 必须指向工作区内非空画面，`outcome.state` 与 `restart.state` 分别记录
`completeRun.terminal` 和 `completeRun.restart`。其他观察也可引用同次运行的画面。

权威命令无论成功失败都原子重写 `verification.json`，旧 PASS 不得在失败复跑后幸存。项目回归只放
`verify.suites` 或证据诊断；若其失败破坏六项之一，映射到该键。

## 最小可玩闭环

一次权威运行至少证明：

1. 候选在实际 `testedRuntime` 启动，无阻断错误；
2. 画面非空且会随时间或操作变化；
3. 真实输入引起可观察状态变化；
4. 核心循环完整执行；
5. 至少一个设计结果可达；
6. restart 回到定义初态。

步骤、状态和画面必须属于同一次 complete run；截图不能证明隐藏状态，状态 dump 不能证明真实画面。
目标运行环境与实际测试环境不同时，把目标独有输入、打包、性能和设备行为写 limitation；替代版本
不能证明目标平台已通过。

## 条件检查与边界

连续 3D、多语言、无障碍、语音、媒体或生成资产只在游戏实际采用时运行诊断。只看玩家能否正确
看到、听到、操作和完成核心流程；诊断不新增 checks，也不审计供应商请求、营销素材或生产身份。

只有 brief/ledger 预先批准的 fallback 才能继续，并证明核心动作、状态、结果、可读反馈和 restart
仍成立。安全失败仍是 FAIL；测试替身只证明测试层；placeholder 只描述完成度；历史证据只说明旧候选。

不要求真人试玩、人工审查或另写 QA 报告。主观趣味、平衡、沉浸、选择重量、权利合规和发布质量
不由本合同确定性证明；需要这类研究时另立任务，不影响本合同的机器 PASS。

# 测试设计方法

目标是用最少证据判断候选是否完成可玩闭环，而不是把项目变成测试工程展示。

## 一、从六项结果反推

为 launch、render、input、coreLoop、outcome、restart 各选择一条最小证据。

## 二、从设计承诺写断言

读取 GAME_DESIGN 中会改变结果的门槛、结局、失败条件、结束标记和核心动作，为每项选择一
个正例和一个有区分力的边界或反例。断言盯住玩家可观察结果，不绑定内部函数名。

叙事项目重点检查关键选择、持久状态读取、分支汇流、结局条件和人物知识边界；系统项目重点检查
状态迁移、门槛、资源、失败和重开。修复缺陷时补能重现原故障的回归，不只验证 happy path。

有事件日志时，保存规则版本、初态摘要、seed、输入序列和终态摘要，完整重放一次；随机探索只用于找
死路和失败 seed，不能代替真实路径。叙事生成存在时增加四类反例：事实冲突、承诺冲突、改写玩家已
提交行动、向未见证者泄密。模型输出只算候选，断言最终由规则器提交的状态与玩家可见反馈。

存在身份专属命令时，正例从固定规范化候选开始证明同状态/seed/版本得到同一执行轨迹与结果；解析层另用
同义表达、否定、条件、缺槽和互斥要求做契约检查，允许澄清或拒绝，不允许静默误命中。反例覆盖执行人
不在场、资源不足、空间无权限、人物未知情和承诺冲突，均须无提交；部分执行或泄露时，反馈必须与实际
证物、见证和知识变化一致。到期事项检查不早触发、到期重新上桌、只结算一次，并在存读/重开后不复活；
谈话产生的事实、承诺、权限、拒绝和见证也必须先通过规则验证。

局部 patch 后先重放原失败路径，再选一条共享上游状态但走相邻分支的反例。文本/资产替换可保持状态
摘要不变；变量语义、节点 id、动作效果或知识权限改变则要求存档/日志迁移，或明确旧版本拒绝载入。

## 三、一条完整路径胜过截图堆

从 clean start 走到设计结果再 restart。每个 checkpoint 只保留触发输入、预期变化、状态证据、运行
环境证据和必要代表帧。只有语义发生变化时留新 checkpoint；不要为每次点击保存一张图。

时序、动效、碰撞和连续镜头证据必须在正常速度下采集；慢放只用于定位，不能证明体验正常。

源码、攻略与隐藏状态可用于规则验证，不能据此证明玩家能自行理解提示或发现解法。
仅在评估引导、提示或解谜可发现性时，另用未接触解法的试玩上下文，只提供玩家可见信息与正常输入；
不向其开放源码、内部快照或答案文件。若已接触这些信息，结果只作知情验证，不冒充玩家视角试玩。
记录所见提示、实际尝试与卡点；这种代理试玩不代表真人理解或趣味，也不增加六项之外的必过门槛。

文字或叙事主导项目在目标视口检查当前动作、必要依据与反馈是否可达可读；滚动本身不是缺陷，
按批准的阅读方式判断遮挡、截断或不可操作。额外视口与溢出遍历按风险做诊断，不强制截图矩阵。

## 四、证据要求
证据用工作区相对路径且文件真实存在（不引用临时目录、缓存或个人桌面）；状态、runtime 和 visual 各证明自己的层，不互相冒充；其余状态取值与 limitation 按 qa-contract.md 记录。

大型录屏、逐点击截图、raw trace 和可重建 contact sheet 不长期进 Git；保留当前声明真正引用的最小
代表证据。问题按 product/design/art/build 归属，主观体验不计入机器 PASS 数量。