Back to Details

threejs-qa-release

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Three.js QA Release

Three.js QA发布流程

Purpose

目标

Prove the game works as a player encounters it, then prepare a shippable browser build with known risks.
证明游戏在玩家实际体验时能正常运行，随后准备一个带有已知风险的可发布浏览器构建版本。

QA Workflow

QA工作流

Load 
references/qa-release-checklists.md
as the first action before broad QA, mobile verification, bug reporting, production preview, static-hosting checks, or release preparation. Track it in a reference ledger with yes/no, path, and failure reason. Do not mark QA/release complete while this reference is skipped for QA or release work.
Load 
references/checklists/visual-verification.md
for screenshot/canvas verification, 
references/checklists/playtest-qa.md
for player-loop QA, and 
references/checklists/release.md
for production release checks. Load 
references/prompt-templates.md
only when the user asks for reusable QA/release prompts or a task template.
Load 
references/visual-test-harness.md
and 
references/checklists/visual-test-harness.md
when the game warrants screenshot baselines, visual regression testing, release-ready visual evidence, UI/generated-asset regression protection, or premium visual QA. If a harness is not warranted, report the skip reason.
Load 
references/playtest-bot.md
and 
references/checklists/bot-playtest.md
for release-ready gameplay claims, difficulty/fairness verification, or when the playable loop has never been driven by scripted input. Report the bot playtest decision as added/extended/skipped with reason.
  1. Install dependencies if needed.
  2. Run build/typecheck.
  3. Start dev or preview server.
  4. Open browser target.
  5. Capture console/page/network errors.
  6. Verify nonblank canvas pixels.
  7. Capture desktop and mobile screenshots.
  8. Trigger main input, objective progression, fail/retry, and recent risky paths.
  9. Check HUD text fit, safe areas, touch targets, responsive layout.
  10. Decide whether to add or extend a visual test harness. For premium/release UI or generated-asset work, prefer a harness unless determinism is a real blocker. 10b. Decide whether to run the bot playtest (
    tests/bot-playtest.template.ts
    in scaffold games). For release-ready gameplay claims, run it and report the metrics JSON.
  11. If audio changed, verify user-gesture unlock, SFX triggers, ambience loop start/stop, pause/restart cleanup, mute/volume behavior, and decode/load errors.
  12. Record artifacts and issues.
在开展全面QA、移动端验证、Bug上报、生产预览、静态托管检查或发布准备工作前，首先加载
references/qa-release-checklists.md
文件。在参考台账中记录完成情况（是/否）、文件路径及失败原因。若跳过该参考文件开展QA或发布工作，不得标记QA/发布完成。
加载
references/checklists/visual-verification.md
用于截图/画布验证，加载
references/checklists/playtest-qa.md
用于玩家循环QA，加载
references/checklists/release.md
用于生产发布检查。仅当用户要求可复用的QA/发布提示词或任务模板时，才加载
references/prompt-templates.md
。
当游戏需要截图基准、视觉回归测试、可发布的视觉证据、UI/生成资产回归保护或高级视觉QA时，加载
references/visual-test-harness.md
和
references/checklists/visual-test-harness.md
。若无需使用该工具，需报告跳过原因。
当需要验证可发布的游戏玩法声明、难度/公平性，或游戏可玩循环从未由脚本输入驱动时，加载
references/playtest-bot.md
和
references/checklists/bot-playtest.md
。需报告机器人测试的决策（新增/扩展/跳过）及原因。
  1. 如有需要，安装依赖。
  2. 运行构建/类型检查。
  3. 启动开发或预览服务器。
  4. 打开目标浏览器。
  5. 捕获控制台/页面/网络错误。
  6. 验证画布像素非空白。
  7. 捕获桌面端和移动端截图。
  8. 触发主要输入、目标进度、失败/重试以及近期存在风险的路径。
  9. 检查HUD文本适配、安全区域、触摸目标、响应式布局。
  10. 决定是否添加或扩展视觉测试工具。对于高级/发布级UI或生成资产工作，除非确定性是真正的障碍，否则优先使用该工具。 10b. 决定是否运行机器人测试（脚手架游戏中的
    tests/bot-playtest.template.ts
    ）。对于可发布的游戏玩法声明，需运行该测试并上报指标JSON。
  11. 若音频有变更，验证用户手势解锁、音效触发、氛围循环启动/停止、暂停/重启清理、静音/音量调节行为，以及解码/加载错误。
  12. 记录工件和问题。

Packaged Canvas Inspector

打包画布检查器

Use the bundled inspector when the target project does not already include one:
bash
node <this-skill-dir>/scripts/inspect-threejs-canvas.mjs --url http://127.0.0.1:5188
For mobile emulation, add 
--mobile
. Add 
--state <name>
(and optionally 
--seed <n>
) to drive the game's 
__THREE_GAME_TEST_HOOKS__
before capture, so every named state (active-play, fail, stress) can be measured deterministically without live play — outputs are suffixed per state. Generated games from the packaged scaffold also include their own 
scripts/inspect-threejs-canvas.mjs
and 
npm run inspect:canvas
.
The inspector JSON includes a 
metrics
block (color entropy, edge density, luminance contrast, dominant-color share) and a 
renderBudget
comparison against starting-point tier budgets. Cite these as the Measured Evidence in the visual scorecard (
threejs-aaa-graphics-builder/references/visual-scorecard.md
); over-budget rows need a documented tradeoff, and blank-canvas or error conditions still exit nonzero.
当目标项目未内置检查器时，使用捆绑的检查器：
bash
node <this-skill-dir>/scripts/inspect-threejs-canvas.mjs --url http://127.0.0.1:5188
如需移动端模拟，添加
--mobile
参数。添加
--state <name>
（可选搭配
--seed <n>
）以在捕获前驱动游戏的
__THREE_GAME_TEST_HOOKS__
，这样无需实时游玩即可确定性地测量每个命名状态（活跃游玩、失败、压力测试）——输出结果会按状态添加后缀。从打包脚手架生成的游戏也包含各自的
scripts/inspect-threejs-canvas.mjs
和
npm run inspect:canvas
命令。
检查器的JSON包含一个
metrics
块（颜色熵、边缘密度、亮度对比度、主色调占比），以及与起始层级预算对比的
renderBudget
数据。将这些数据作为视觉评分卡（
threejs-aaa-graphics-builder/references/visual-scorecard.md
）中的实测证据；超出预算的行需要记录权衡方案，空白画布或错误情况仍会以非零状态退出。

Release Workflow

发布工作流

  1. Inspect package scripts, Vite config, base path, public/assets.
  2. Gate debug UI/logging/test helpers.
  3. Run production build and preview/static server.
  4. Verify built output desktop/mobile.
  5. Review bundle and large assets.
  6. Document deploy command, host assumptions, and residual risks.
  1. 检查包脚本、Vite配置、基础路径、public/assets资源。
  2. 启用调试UI/日志/测试辅助工具的门控。
  3. 运行生产构建并启动预览/静态服务器。
  4. 验证构建输出在桌面端/移动端的表现。
  5. 审查包文件和大型资产。
  6. 记录部署命令、主机假设及剩余风险。

Final Response

最终响应

Lead with pass/fail. Include the reference ledger, QA matrix/checklist result, commands, URL, controls, screenshots/artifacts, issues found/fixed, deployment notes, and risks. When visual baselines are in scope, include the harness decision, states covered, update/compare commands, artifact paths, thresholds/masks, and flake risks. When the bot playtest ran, include its metrics JSON (frames, score progression, distance, softlock windows, seed) and the added/extended/skipped decision.
首先说明通过/失败结果。包含参考台账、QA矩阵/检查清单结果、命令、URL、控件、截图/工件、发现/修复的问题、部署说明及风险。 当视觉基准在范围内时，需包含工具决策、覆盖的状态、更新/对比命令、工件路径、阈值/遮罩以及波动风险。 当运行了机器人测试时，需包含其指标JSON（帧数、分数进度、距离、软锁窗口、随机种子）以及新增/扩展/跳过的决策。