game-qa

# 游戏质量验证 验证游戏能否可靠运行和完成，不给“好玩”伪造客观分数。 读取 [qa-contract.md](references/qa-contract.md)。 ## 执行 1. 从项目脚本和 `BUILD_BRIEF.md` 发现运行方式，使用现有浏览器测试能力。提取不变量以 `BUILD_BRIEF.md` 回写后的「# 范围」与「最终范围对照」为依据；发现 brief 范围与代码 不一致（如 brief 三战、代码六战）先记 `major` 要求回写再验。 2. 启动真实页面，记录构建失败、页面异常、控制台错误和关键资源失败。 3. 证明画面非空且会变化；画布元素存在本身不算渲染成功。 4. 从 `GAME_DESIGN.md` 提取会改变结果的关键不变量：把每个数值门槛、结局条件、破裂/冷却 条件抄成期望表落盘 `qa/evidence/design-invariants.md`，逐项对照引擎常量或运行态取值， 记录一致或漂移及证据。 5. 使用真实输入走核心动作、进程变化、设计要求的结果和重开；确定性系统至少复现一次 相同状态与输入得到相同结果。 6. 在目标视口检查遮挡、溢出、文字和控件可操作性；逐一切换策划要求的界面语言， 检查缺字、截断、阅读顺序、术语一致性和关键玩法信息。 视口、界面语言、控制方式与内容尺度按 `PRODUCT_BRIEF.md` 的目标平台与分级核对： 竖屏/横屏、单局结构、交互约束是否兑现，内容是否落在批准的分级内（未逾越，也未被下游 悄悄收回到更保守）。 7. 对文化关键名称、符号和提示抽查原作语义，避免翻译或本地化改变规则与角色关系。 8. 走一遍首次上手：首个有意义动作与冷启动节拍在正常速度下实测；两分钟理解度（"我是谁/ 要什么/往哪使劲"）须由未接触任何策划/构建文档的干净上下文子代理基于顺序真实画面裁决， 无该能力时理解度记 `NOT_RUN`，首次上手不得判 `PASS`。再逐条对照 `CONCEPT.md`/`GAME_DESIGN.md` 的体验支柱与其"可观察试玩证据"，确认承诺的卖点在真实游玩里被演成了场面而非只剩数字， 并检查设计写明的失败现象有没有发生。判据与协议见 [qa-contract.md](references/qa-contract.md)。 9. 每条 `blocker`/`major` 按 qa-contract 的归属定义标注 `build`/`design`/`product` 并写入 发现与回流表；标 `design` 的本轮不得 `PASS`；回流路由由总入口执行。 优先使用游戏已有可观察状态；只有无法判断结果时才增加最小测试钩子。不要为了 QA 重构游戏或强制一种调试接口。 ## 输出 生成 `qa/QA_REPORT.md`（**阻断交付物：无它不得报完成**），记录环境、命令、通过/失败项、 证据路径、未测试范围，必填「独立验证」与「发现与回流表」、附「模型试玩手记」，以及三项 主观-但-可观察裁决：**首次上手 / 核心幻想演出 / 招牌帧符合**（各节最小内容见 qa-contract.md）。 只有零 `blocker`、零 `major`，且加载、核心动作、主要结果和重开都有证据时才标记 `PASS`； 把 `PASS`/`FAIL` 裁决与一句原因文本交回总入口，`gate:qa` 行由总入口核对后写入 `_progress.md`，本阶段...