threejs-qa-release

Three.js QA 发布

按照玩家实际体验游戏的方式验证游戏，然后准备一个可交付的构建，并说明已知风险。

从实际加载的技能文件解析 <this-skill-dir> 和本地引用；使用运行器发现的替代项之前，先解析该文件旁的同级技能。在安装了 npm 依赖的游戏项目中运行检查器。

参考资料

文件	适用情况
references/release-checks.md	移动端验证、生产发布、性能证据或发布失败陷阱
references/visual-test-harness.md	截图基线、视觉回归、UI 或生成资源回归保护
references/playtest-bot.md	可发布游戏的声明、难度与公平性检查，或从未通过脚本输入驱动的游戏循环

QA 流程

完整游戏执行以下完整流程。对于范围较窄的编辑，选择覆盖受影响行为、状态和目标视口的检查。复用同一代码修订版本中有效的专项证据；负责人负责统筹一次完整检查。仅在相关变更、失败或尚未解决的问题出现后重复检查。明确限定为仅桌面端的范围，无需额外添加移动端游戏体验。

1. 安装依赖，运行构建和类型检查，启动开发或预览服务器。
2. 打开浏览器目标，捕获控制台、页面和网络错误。
3. 确认画布像素非空且存在视觉变化。
4. 在每个目标视口（默认包括桌面端和移动端）捕获游戏进行中的画面，而不只是标题画面。
5. 测试主要输入、目标推进、失败与重试，以及最近更改的内容。
6. 检查 HUD 文本适配、安全区域、触控目标和响应式布局。
7. 音频发生变更时：检查用户手势解锁、音效触发、环境音循环的启动和停止、暂停与重新开始时的清理、静音和音量、解码错误。
8. 决定是否使用视觉测试框架。对于高品质、可发布、UI 密集或使用生成资源的工作，通常值得使用；无论如何都要说明决定。
9. 对可发布游戏的声明运行机器人游戏测试（脚手架游戏使用 tests/bot-playtest.template.ts），并报告其指标 JSON。
10. 动画发生变更时，捕获一段短暂的未暂停序列，并使用 references/visual-test-harness.md 检查移动、动画片段切换、足部、骨架变形以及攻击/接触时机。

仅凭截图无法覆盖游戏体验变更。

画布检查器

node <this-skill-dir>/scripts/inspect-threejs-canvas.mjs --manifest artifacts/evidence.json --url http://127.0.0.1:5188 --seed 42

先在 artifacts/evidence.json 中声明本轮的视口/状态组合，并使用新的运行 ID；格式和测试钩子约定见 director 的 references/evidence-manifest.md。一条命令即可在同一个浏览器中捕获所有已声明的组合，并为每次捕获打印一行：PASS/FAIL、GPU、像素指标、超预算行、错误计数，以及报告和截图路径。只有当某行需要更多细节时才打开对应报告文件。包含所有要求的状态；不要为了让清单通过而删除失败项。单次检查可使用 --state <name> [--mobile] 捕获单个视图；省略 --state 则只检查当前视图。脚手架游戏有自己的副本，可通过 npm run inspect:canvas 使用。

这些指标是 threejs-aaa-graphics-builder/references/visual-scorecard.md 中视觉评分卡的实测证据。超预算行需要记录权衡说明；画布空白或存在错误时，命令将以非零状态码退出。

发布流程

检查 package 脚本、Vite 配置、基础路径和公共资源 → 阻止调试 UI、日志和测试辅助工具进入发布包 → 运行生产构建，并通过静态服务器预览 → 在目标视口检查构建产物 → 检查捆绑包和大型资源 → 记录部署命令、主机假设和剩余风险。

报告

先说明结果和未解决的缺陷。将详细命令、清单、捕获内容、动作证据、已测试的控件、已修复的问题和部署说明放入项目的证据报告中。在适用时，加入测试框架的决策和机器人指标。将产物路径交给负责人；像素通过检查且状态钩子已确认，并不能单独证明美学质量或游戏成功。