用途：当生产环境出现故障、修复范围窄且明确、无法等待完整工作流时，wtf.hotfix 提供一条紧急修复路径。若修复较大、范围不清或需要设计评审，应改用常规 Trace 流程（wtf.write-feature → wtf.feature-to-traces）。
主要能力：先完成 GitHub CLI 配置校验；识别 bug（可用 gh issue view <bug_number> 获取，无 issue 时按 wtf.report-bug 快速路径创建，跳过 Gherkin 推导与统一语言映射）；确认热修范围（窄、非破坏、可测试）；加载 docs/steering/TECH.md 约束并静默应用；从 main 直接建热修分支；用 Agent 工具探查代码库；设范围门禁——若涉及超过 3–4 个文件、API 契约变更或 schema 迁移，须先报告并由用户决定继续或转入常规流程。
实现方式：先写失败测试，再做最小修复使其通过，遵循 wtf.implement-trace 第 9 步的 TDD 循环；运行完整测试套件，无关失败不相阻塞但需在 PR 正文记录为既有失败；按约定提交，提交信息使用 Bug: trailer，Closes #<n> 放在 PR 正文。随后以严格 STE 撰写 PR 正文，包含 Related、Impact、Root cause、Fix、Risk 及既有失败等部分，用 gh label create hotfix 与 python3 .wtf/gh-body.py create --pr 创建面向 main 的 PR 并打印 URL。最后询问是否回迁至 release 分支，选中后待热修 PR 合并再 cherry-pick。
限制：不适用于大范围或需求不清的修复；涉及 API 契约或 schema 变更需先确认；回迁依赖项目是否使用 release 分支；具体测试命令取决于 TECH.md 或 package.json，资料未提供固定命令。