游戏质量验证

验证游戏能否可靠运行和完成，不给“好玩”伪造客观分数。

读取 qa-contract.md 定判据，读 test-design-method.md 定怎么设计这些检查。

产物语言由 PRODUCT_BRIEF.md 锁定；未锁定时跟随对话语言，不默认产出中文。

执行

1. 先做 suite discovery：依次查 package/build manifest scripts、CI workflow 实际命令、测试 目录/文件、BUILD_BRIEF.md 声明的 runner，再对照 qa/evidence/verify.log。把结果写成 suite | discovered from | files | runner | observed in verify | result；发现 required suite 存在 却未被权威命令执行，报告 ORPHANED_TEST_SUITE，严重度 major。vendored/build output/ 明确 archived fixture 不算 suite，但例外必须写理由。
2. 从项目脚本和 BUILD_BRIEF.md 发现目标平台、targetRuntime、testedRuntime 与启动方式， 使用当前环境中适合该运行时的测试能力；网页才使用浏览器测试。独立运行 brief 声明的 权威 verify，记录实际 command、exit code、duration、environment 和 source commit；不能只 接受实现方贴出的绿色摘要。提取不变量以 BUILD_BRIEF.md 回写后的「# 范围」与「最终范围对照」为依据；发现 brief 范围与代码 不一致（如 brief 三战、代码六战）先记 major 要求回写再验。
3. 审计 qa/verification.json：环境、verify、suites、completeRun、checkpoints 必须属于同一 source commit。复跑一条 clean start → 核心动作 → 设计结果 → restart，逐步核对 checkpoint； 缺字段、路径不存在或只有临时目录路径时不得通过。等价结构只有在 BUILD_BRIEF 与 QA_REPORT 给出稳定映射时接受。
4. 在 testedRuntime 启动真实构建，记录构建/导出失败、运行日志错误、崩溃和关键资源失败。 若 testedRuntime 不等于 targetRuntime，把目标平台独有的输入、性能、打包和发布项列为 NOT_RUN，不得借替代版本判过。
5. 证明画面非空且会变化；网页画布、引擎场景节点或窗口存在本身都不算渲染成功。
6. 从 GAME_DESIGN.md 提取会改变结果的关键不变量：把每个数值门槛、结局条件、破裂/冷却 条件，以及「三段弧」每期的结束标记与新增动词 / 可达空间、BUILD_BRIEF 的「同玩法动词 清单」，抄成期望表落盘 qa/evidence/design-invariants.md，逐项对照引擎常量或运行态 取值，记录一致或漂移及证据。后两项要跑实测取证，核对文档写没写不算数。
7. 使用真实输入走核心动作、进程变化、设计要求的结果和重开；确定性系统至少复现一次 相同状态与输入得到相同结果。
8. 在目标分辨率、窗口模式或设备朝向下检查遮挡、溢出、文字和控件可操作性；逐一切换策划要求的界面语言， 检查缺字、截断、阅读顺序、术语一致性和关键玩法信息。 显示模式、界面语言、控制方式与内容尺度按 PRODUCT_BRIEF.md 的目标平台与分级核对： 竖屏/横屏、单局结构、交互约束是否兑现，内容是否落在批准的分级内（未逾越，也未被下游 悄悄收回到更保守）。
9. 对文化关键名称、符号和提示抽查原作语义，避免翻译或本地化改变规则与角色关系。
10. 走一遍首次上手：先跑前提传达门——起一名不给任何策划 / 构建文档的干净上下文子代理 （两分钟理解度沿用同一名），只喂常速冷启动第一分钟按序截取的画面，四问一并作答（我是 什么 / 我要什么 / 什么会终结这一局 / 这是哪一类游戏——我主要在反复做什么、像我玩过的 哪款游戏），判据见 qa-contract 的「前提传达门」，逐字落盘 qa/evidence/premise-gate.md； 未跑或记 NOT_RUN 时首次上手不得判 PASS。再在正常速度下实测首个有意义动作与冷启动 节拍；两分钟理解度（"我是谁/要什么/往哪使劲"）须由未接触任何策划/构建文档的干净上下文 子代理基于顺序真实画面裁决， 无该能力时理解度记 NOT_RUN，首次上手不得判 PASS。再逐条对照 CONCEPT.md/GAME_DESIGN.md 的体验支柱与其"可观察试玩证据"，确认承诺的卖点在真实游玩里被演成了场面而非只剩数字， 并检查设计写明的失败现象有没有发生。判据与协议见 qa-contract.md。
11. 每条 blocker/major 按 qa-contract 的归属定义标注 build/design/product 并写入 发现与回流表；标 design 的本轮不得 PASS；回流路由由总入口执行。

BUILD_BRIEF 含动态媒体台账（视频 / 关键帧驱动演出 / 实时 3D）时，强制启用生成媒体 检查：逐镜对照参考图做漂移证伪（首 / 中 / 尾帧）、相邻镜头边界接续检查、API 证据链 核对，以及 3D 后端降级与资源释放证据核对——判据见 qa-contract.md 的生成媒体节，无台账则该节不适用。

BUILD_BRIEF 含语音资产台账时，强制启用语音与 TTS 检查：逐句核对生成真值、说话人 / casting_id、性别呈现与年龄感、音色权利、字幕映射、解码 / 时长 / 响度、真实试听、静音与 缺音降级、运行期网络和客户端密钥暴露；短反馈、 长段、情绪、停顿、专名、数字与每种目标语言按实际采用范围取样。判据见 qa-contract.md 的《语音与 TTS 证据》，无台账则该节不适用。

优先使用游戏已有可观察状态；只有无法判断结果时才增加最小测试钩子。不要为了 QA 重构游戏或强制一种调试接口。

输出

生成 qa/QA_REPORT.md（阻断交付物：无它不得报完成），记录环境、命令、通过/失败项、 证据路径、未测试范围，必填「独立验证」与「发现与回流表」、附「模型试玩手记」，以及三项 主观-但-可观察裁决：首次上手 / 核心幻想演出 / 招牌帧符合（各节最小内容见 qa-contract.md）。 只有零 blocker、零 major，且加载、核心动作、主要结果和重开都有证据时才标记 PASS； 把 PASS/FAIL 裁决与一句原因文本交回总入口，gate:qa 行由总入口核对后写入 _progress.md，本阶段不自记过门。趣味、长期平衡、留存 和商业完成度留给人工试玩，但试玩工具由本阶段交付：同时落盘 qa/PLAYTEST_PROTOCOL.md。