用途：在生产事故中按正确顺序恢复服务——先止血，再定位根因，避免在线上调试或盲目修复不理解的变更。
主要能力：提供分步流程与检查清单。第0步分诊（60秒）：判断影响范围（单接口、单租户还是全部）、受影响用户数、最近变更（部署历史、发布分支 git log、配置与开关变更），并在事故频道开一条状态线程。第1步止血：按成本从低到高选择安全手段——回滚到上一个已知良好版本（ECS、Cloud Run、Vercel、Fly.io 等平台通常一条命令即可）、撤销导致问题的提交并发布该撤销、关闭功能开关后重新部署、在属于负载问题时扩容副本或调整队列/并发限制；确认恢复（健康检查、错误率下降、真实请求成功）后更新状态为 mitigated。第2步诊断：查看错误追踪的异常与堆栈、故障时间窗内的平台日志与告警，将错误起始时间与部署/开关时间关联，在本地或预发环境复现确认根因。第3步修复：写出真正的修复，运行 /gate、走评审与正常部署流水线，再重新启用此前关闭的开关。第4步收尾：状态线程标记 resolved 并写明一行原因，撰写简短复盘（时间线、根因、止血手段、预防措施），必要时更新 runbook 或 gate，并将预防工作建单。
限制与禁止事项：不要用缩容到零来“重启”（等于完全宕机）；事故中不要执行破坏性基础设施 apply（destroy、refresh 或从未合并分支 apply）；不要强制删除密钥来“重置”；不要反射式迁移或回滚数据库，除非迁移就是根因且下行迁移已被证明安全；不要通过改线上配置在 prod 调试。反模式包括：修复不理解的变更而不回滚、恐慌性缩容或破坏性操作、无状态线程与复盘的静默恢复、以“这是事故”为由跳过评审直接上生产。
适用场景：线上服务出现故障、错误率上升或部署后异常时的应急处理。具体平台命令与工具集成细节暂未提供。