postmortem

复盘

根据实际意图、结果和判断证据，回答有关已完成或已停止的目标、会话、变更或事件的明确因果回顾问题。 如果明确要求进行阶段性分析，应明确截止时间和待检查事项；其结论只描述该时间段，不代表最终结果。 相邻主题：尚未执行的计划可能如何失败，见 事前分析； 已完成的变更是否符合验收要求，见 验证。

首先检查：相关性还是因果关系？

将每一项因果陈述都视为假设，包括调用者提出的假设。 要将某项主张从相关性提升为因果关系，必须满足以下全部三项要求：

• 明确说明机制：具体指出该条件如何导致结果，且读者能够对照分析对象进行核查；
• 具有区分力的证据：观察结果符合该机制的预测，且至少一种合理的替代解释无法预测该结果；
• 反事实测试：说明如果该主张不成立，哪些情况应当有所不同，并引用证据证明这些情况确实有所不同。

事后将修复归因于原因——“我们改了 X，故障就停止了，因此 X 就是原因”——单凭这一点并不满足上述任何一项要求：症状可能是间歇性的，或者恢复和变更可能具有相同的未观察到原因。此类主张应保留为相关性，指出仍然成立的替代解释，并提出具有区分力的实验；基于尚未证实原因提出的建议，应表述为该实验，而不是已有证据支持的变更。要否定一项主张，同样需要具有区分力的证据，或证明证据与该主张的预测相矛盾。达不到这些要求的，都只能视为相关性或未知。

提示词

Postmortem last Thursday's release: the deploy needed four attempts and two
rollbacks before it stuck. Using the deploy log, the CI runs and the incident
channel notes, which failures were avoidable and what caused each one?
Answer inline.

关键约束

• 复盘是回顾性因果分析，不是泛化的经验总结，也不是代码验收关卡：代码判断绝不应等待复盘；当两者都被要求时，Plan 的 代码加回顾 规则会将两者分开处理。 除非明确要求进行阶段性分析，否则应等待结果明确后再开展复盘。
• 复盘不会重新执行验收验证、改变现有结论或捏造缺失的证明。现有的 verdict.v2 可作为可选证据；即使没有该文件，也不影响分析已停止或未经验证的对象。
• 后续行动由调用者负责，因此不要改写证明、操作跟踪器状态、变更剩余计划、重新开启工作或提升规则。
• 分析结果为空或无法得出结论都是合理的；有必要时应建议不做变更。不要凭空制造确定性或经验教训。

工作流

1. 用准确的 ID（提交、检查、消息、现有结论）明确问题、已接受的意图、主体身份、实际结果和可用判断；明确指出缺失的证据。对于事件，意图是预期的服务行为或 SLO，判断是告警和检查；第 2 步应在偏离发生前查找部署、配置更改、上游事件或缺失的信号。
2. 仅重建主张所依赖的时间线，并区分已交付的行为、失败或停止的工作以及流程输出。对于纠正或停止，找出首次可观察到偏离已接受行为的时刻，以及紧接其前的指令、工具结果或缺失输入。条件相似时，比较一个成功案例；否则指出缺少这项比较。调用方要求暂停属于预期行为。隐藏的作者推理不是事实；缺少判断不等于 PASS 或 FAIL。
3. 对每项因果主张执行上述首次检查。区分必要的验证和兼容性工作与可避免的返工；仅反复审查不能证明存在浪费。 如果输入包含同一主体的早期事后分析，在提出新建议前，应说明其建议的落实情况：已落实、部分落实、未落实或未知，并以此后提供的工作证据为依据。保留变更已获授权、被搁置或从未获批的状态；缺少应用证据不代表采纳失败。只有观察到目标故障再次发生时，才报告复发。对于反复未落实的建议，应指出已知障碍或尚未解决的问题，而不是简单重复建议。仅未落实本身不能证明原因、责任，也不能证明建议有帮助。
4. 对于时间或 token 的主张，说明来源、时间区间、单位、纳入和排除的参与方，以及不确定性。区分经过时间、重叠工作和统计范围；没有支持证据时，绝不能把总量等同于浪费、节省或金额。
5. 返回下方规定的输出，然后停止；建议不构成实施授权。

输出规范

• 默认使用简洁的行内 Markdown，无需强制提供报告或工作表：

  Question: <the causal question>
  Inputs: <intent, outcome and evidence, with exact ids>; missing: <gaps>
  Timeline: <only the events the claims depend on>
  Claims:
  - <claim>: supported | correlation | rejected | unknown
    mechanism / discriminating evidence / counterfactual: <each, cited, or "none">
    alternatives still standing: <rivals the evidence cannot rule out>
  Accounting (if claimed): <source, interval, units, actors, uncertainty>
  Unknowns: <what would settle them>
  Earlier advice (if supplied): <recommendation> - applied | partly applied | not applied | unknown, <evidence>
  Changes (at most three, or "no change"): <change> - <its limit, or the experiment that tests it>
  

• 每项更改都应针对下一次运行将遇到的问题，通常是第 2 步发现的指令、工具结果或缺失输入，而不是重新修复已修复的代码。可避免的遗漏类型决定了改进手段：

  • 操作失误（路径错误、跳过命令、调用了禁用项）：添加 lint 规则、测试、钩子或配置保护。先阅读仓库的检查命令、钩子和 CI；现有检查未运行或无法触发失败，就是需要改进的地方，而不是再添加一份重复检查。如果代码中没有可容纳此类检查的位置，则将 Architecture 列为后续工作，并明确指出该缺陷造成的痛点。
  • 判断失误：提出一项标准、运行手册步骤或指令行；编写这些内容需单独获得授权，属于 Memory 工作。
  • 查找事实耗时过长：提供一个搜索起点。事实无法获取：提供下次公开该信息的方式，例如记录日志或设置告警；更改访问权限需获得调用方授权。

• 仅在收到请求时，才将 YYYY-MM-DD-postmortem-<topic>.md 保存到调用方选定的受保护 Git 外部存储中。未指定保存位置不授权将其保存到仓库；应根据所有者政策保留已有的指定证据。

• 对任何经验进行筛选整理、支持和去向披露审查，均需单独获得授权，属于 Memory 工作；回顾性证据不能自行升级为经验。