hotfix

用途：hotfix 用于紧急缺陷的快速修复。它省略头脑风暴文档和计划文档，以速度优先，但测试与审查不可省略。

主要能力与流程：

1. 分诊：用一句话概括缺陷，识别症状与疑似涉及层/组件。
2. 定位：调用 @codebase-review-agent 聚焦查找相关代码，阅读文件与邻近代码，确定根因并用 2-3 句向用户说明；根因不明时用 AskUserQuestion 追问。
3. 分支：检查当前分支 git rev-parse --abbrev-ref HEAD；若不在 hotfix/ 分支，则按 hotfix/<kebab-slug> 命名（总长不超过 60 字符）并确认创建。
4. 修复：先做影响范围检查，若涉及超过 5 个文件、多层或需新抽象，则警告并让用户选择继续热修或改用 /plan；否则直接实施最小改动，不做无关重构，越界问题用 // TODO(hotfix): 注释标记。必须添加或更新可复现缺陷的测试（修复前应失败），覆盖修复路径与相关边界。
5. 审查：并行运行精简审查代理 @vgv-review-agent（报告名 vgv-review）与 @test-quality-review-agent（报告名 test-quality-review），报告写入 <PWD>/docs/hotfix-review/raw；随后合并去重、分配 FINDING-NN 编号，写入 docs/hotfix-review/review.md，修复 Critical 项并向用户展示 Important 项；完成后执行 rm -rf docs/hotfix-review/ 清理。
6. 交付：按项目套件（格式化、lint、测试）驱动到全绿，创建单一、便于 cherry-pick 的提交，格式为 fix: <描述>，正文含根因与 Bug 说明，推送分支并创建 PR（标题不超过 70 字符）。

限制与注意：不生成头脑风暴或计划文档；不得跳过测试；不得添加与缺陷无关的功能；修复超出原范围应停止并提示；共享依赖改动前需 grep 全部用法；涉及数据库、配置或 schema 迁移通常不适合热修，建议改用 /plan → /build；hotfix 分支使用 hotfix/ 前缀而非 fix/；若 docs/hotfix-review/ 存在旧报告需先删除。仅在根因不明、连续 3 次修复失败或缺少依赖时才询问用户。允许有意引入较低严重度副作用，但需用 // TODO(hotfix): 注释并在 PR 中说明。