用途：这是一个面向生产事故（incident）处理的团队规范技能。它强调事故工单不是普通 bug 报告，首要目标是先止血、后解释，而这两者常相互冲突。
主要能力与要求：按顺序建立事实。一是影响范围，谁受影响、严重程度如何（错误率从 0.01% 翻倍与从 4% 翻倍不是同一回事）。二是起始时间，先拿到时间戳再谈理论，第一个给出的时间戳通常是被人发现的时间而非事故开始时间。三是变更关联，调用 correlate_deploys，传入服务名和一个早于上一步时间戳的时间窗口；结果为空也有信息量，通常意味着问题不在部署上。不得跳过第三步直接下结论，落在窗口内的部署并不自动等于原因。
回滚：request_rollback 只提交变更请求，不会真正回滚，需由人批准。因此提交成本低，一旦有具体部署对象和理由就应尽早提交，而不是等到完全确定。填写的理由会原文进入变更记录，是审批人深夜看到的依据，要写证据而非结论，例如“checkout-api 错误率在 deploy d-4821 后 90 秒内从 0.2% 升至 6%；窗口内无其他部署；diff 涉及重试路径”。超出配置回滚窗口的部署会被拒绝，这是有意设计：彼时回滚通常比向前修复更危险，需由人决定而非工具调用。
工单记录：边处理边更新工单，而不是最后才写，否则工单沉默二十分钟会被理解为无人处理。时间线放在工单描述中，推理过程放在评论里——描述供半年后复盘阅读，评论供同事当下阅读。
禁止事项：不要因错误率恢复就把工单状态改为已完成，恢复与解决不同，事故需有人解释清楚才可关闭；不要静默地闭环，若已关联部署但无发现，应在工单上说明，这是真实结果，可避免他人重复劳动。