bug-report

用途：面向游戏开发项目，把口头描述整理成结构化缺陷报告，或扫描代码找出潜在缺陷，并跟踪缺陷的验证与关闭。\n\n模式：无关键字进入描述模式，依据描述生成报告；analyze [path] 进入分析模式，读取目标文件识别空引用、越界、竞态、未处理边界、资源泄漏、状态转换错误等潜在缺陷；verify [BUG-ID] 进入验证模式，确认修复是否真正解决缺陷；close [BUG-ID] 进入关闭模式，为已验证缺陷写入关闭记录。未提供参数时先询问缺陷描述。\n\n报告结构：含摘要（标题、ID、严重级别 S1-S4、优先级 P1-P4、状态、报告日期、报告人）、分类（类别、系统、频率、是否回归）、环境（构建、平台、场景、游戏状态）、复现步骤（前置条件、步骤、预期与实际结果）、技术背景（可能涉及文件、相关系统、可能根因）、证据与备注。严重级别与优先级沿用 bug-triage 的命名。\n\n用法要点：报告写入前会先分配 ID（扫描 production/qa/bugs/BUG-*.md 取最大编号加一，四位补零），并在写入前征求确认；验证模式会按编号查找缺陷文件，检查根因代码路径是否仍存在，若配置了 commands.test 则运行相关测试并报告通过与否，必要时通过 AskUserQuestion 询问是否在含修复的构建上复现；验证结论分为 VERIFIED FIXED、STILL PRESENT、CANNOT VERIFY。关闭前必须状态为 Verified Fixed，否则提示先运行 verify；关闭时追加关闭记录并更新顶层状态。\n\n自动化模式：通过 yaml-helper.sh 解析 modes.automation（project.local.yaml → project.yaml → 默认 collaborative），行为遵循 .claude/docs/automation-modes.md，collaborative 总是询问，guided 仅重大操作询问，autonomous 记录后继续，automation_always_ask 类别始终询问。\n\n后续建议：归档后运行 /bug-triage 排优先级，S1/S2 走 /hotfix；修复后先 verify 再 close，未验证不得关闭。\n\n限制：测试命令必须取自项目配置 commands.test，不得凭记忆编写（例如 gdUnit4 缺少 --remote-debug tcp://127.0.0.1:0 会挂起）；无测试运行或视觉/UI 类缺陷需人工游玩验证；未获用户确认不会写文件。官方说明、价格与平台支持等信息暂未提供。