游戏测试
像QA工程师一样测试游戏，使用Claude Code或包含项目文件的聊天会话。
工作流
- 读取规则：如果存在
RULES.md则打开（来自game-rules-core技能）。如果没有，则从代码中推断规则并先写下来。无法测试的规则属于规范中的缺陷。 - 映射代码：找到游戏循环、状态机、输入处理、碰撞、生成和计分代码。
- 静态审查：扫描
references/checklist.md中的常见缺陷。 - 编写测试：对纯逻辑（碰撞计算、计分、状态转换）进行单元测试，并在可能的情况下添加确定性模拟测试（固定种子、固定dt、脚本化输入）。
- 运行并观察：运行测试，如果浏览器工具可用，则玩游戏并捕获控制台错误。
- 报告：使用以下格式编写
BUG_REPORT.md。
测试类别（覆盖所有）
- 核心循环：开始、暂停、恢复、重新开始、游戏结束、胜利。每个状态转换都有效并重置正确的项。
- 输入：同时按键、暂停时按住键、快速点击、焦点丢失（模糊）、触摸和手柄（如果支持）。
- 碰撞/物理：高速穿模、角落卡住、站在边缘、移动平台、掉出世界。
- 规则：
RULES.md的每一行至少有一个测试：触发条件、条件、效果、边界情况。 - 计分/进度：正确地递增，不重复计数，重新开始时重置，持久化（localStorage）在重新加载后存活并能处理损坏数据。
- 生成：尊重上限，始终可通过，重新启动后没有残留实体，内存不随时间增长。
- 帧率独立性：在模拟的30、60和144 FPS下运行；游戏结果必须匹配。
- 性能：帧时间、实体数量增长、内存泄漏、绘制调用（3D）。
- 健壮性：调整窗口大小、切换标签页、快速重启、移动视口。
- 确定性：相同种子加上相同输入给出相同结果。
缺陷报告格式
对于每个缺陷：
- ID / 标题
- 严重性：关键（崩溃、软锁、进度丢失）/ 主要（规则被破坏）/ 次要（视觉、手感）/ 打磨
- 重现步骤（编号，精确）
- 预期 vs 实际
- 证据：文件和行号、控制台错误或失败的测试名称
- 建议修复（一至两行）
报告以总结表（按严重性计数）和未测试内容列表结束。
硬性规则
- 没有证据（失败的测试、日志或可指向的代码路径）绝不声称存在缺陷。
- 如果未实际运行，绝不声称某功能工作正常；应说明“已审查,未执行”。
- 优先使用确定性测试，而不是“我玩过了，感觉还行”。
- 除非要求，否则不要修改游戏代码；先报告，按请求修复。