紧急修复（Hotfix）

归属：docs/guides/sops/ 触发：线上 P0/P1 缺陷，需立即修复并尽快发版关联概念：01-bug-fix、08-rollback、flow-release、Worktree Lifecycle

场景定义

对已发布线上版本的紧急缺陷，以最短路径修复并立即产出一个 patch 补丁发布。区别于常规 Bug 修复（01-bug-fix）：Hotfix 有明确时效约束，跳过非必要的流程步骤，并需在发布前后做回滚就绪。

借鉴 GitFlow 的 hotfix 分支约定与事故处理：

严重度升级：只有 P0/P1 才走 Hotfix 路径；P2/P3 走常规 01-bug-fix。
从生产基线拉分支：基于最近发布 tag / release 分支创建 hotfix/<slug>，而非开发最新分支——避免夹带未发布改动。
最小修复 + 针对性测试：只改暴露缺陷的代码；跑针对性测试 + 关键回归，确保修补不引入新问题。
快速合并 + patch 发版：合并回默认分支并立即打 patch tag（版本规则 fix → patch），发布流程走项目 GitHub Actions release workflow。
双向合并：修复同时合并回默认分支与当前开发主干，防止主开发线继续带病。
回滚就绪：发布前确认回滚策略（08-rollback），发布后监控，失败即回滚。
事后复盘：发布稳定后补 RCA 与预防措施（转 01-bug-fix 的复盘步骤）。

拉生产基线分支：

bash

LAST_TAG=$(git describe --tags --abbrev=0)
git worktree add ".worktree/<slug>" -b "hotfix/<slug>" "$LAST_TAG"

最小修复 + 针对性测试：在 worktree 内修复，跑受影响模块测试 + 关键回归（复用 flow-tdd 的 RED→GREEN，但允许聚焦、不放宽门禁）。
创建并合并 Hotfix PR：gh pr create 指向默认分支；CI 绿 + 快速审查（flow-review）后 --match-head-commit 合并。
patch 发布：复用 flow-release 的 patch 路径——版本规则 fix → patch，更新版本文件 → Release PR → 合并打 tag → 触发 GitHub Actions release workflow，监控成功。
合并回开发主干：若默认分支与开发主干分离，将修复 cherry-pick / 合并到主干，防止复发。
回滚预案 + 监控：确认 08-rollback 策略；发布 workflow 失败区分「瞬时失败 rerun」与「代码缺陷 → Corrective Flow + 新版本」。
复盘：稳定后补 RCA、根因、预防措施。

复用：flow-tdd、flow-review、flow-release（patch 路径）、goal 工具、Worktree Lifecycle。
新增（缺口）：Hotfix 最短路径入口、patch 发布通道、hotfix/<slug> 分支约定。