用途：在故障、影响用户的缺陷、数据问题或未遂事件解决后，或在长时间故障的稳定节点撰写复盘报告（postmortem）。已影响用户的缺陷与未遂事件（被检查拦住而评审未发现的问题）同样值得记录。不应在故障处置过程中使用（此时遵循 runbook），也不用于追责或向利益相关方发送状态更新。
主要能力与结构：提供固定骨架，依次为标题（系统：症状、一行）、事件日期、持续时间（从检测到解决）、严重级别（按组织分类法）、状态（草稿/已评审）、摘要（用户可见影响与数字、根因一句话、当前状态）、影响（量化受影响的对象，估计须标注为估计）、时间线（带时间戳、仅事实、每条可追溯到证据）、根因与促成因素、响应中的错误方向、行动项（含负责人与验收检查并链接到工单）、签署（评审事件逐行记录）。
关键规则：无指责意味着结构性归因，指向角色、关口、依赖或缺失的防护，而非个人；时间线是证据而非叙述，时间戳取自系统而非记忆；错误修复也是内容；严重级别来自组织分类法，无分类法则明确留空；行动项遵循 writing-issues，无法提交时标注 [to file: <谁提交>]，链接存在前保持草稿状态；评审后不可变，新发现以带日期的附录形式追加；未遂事件使用同一骨架，影响部分描述本可能发生的情况并标注为反事实。复盘后产生的决定通过 recording-decisions 记录并链接，而非嵌入文中；故障暴露的 runbook 更新与修复同批通过 writing-runbooks 完成。
前置与限制：需要 technical-writing 技能作为硬性背景；资料未提供具体命令、安装方式、价格或平台等信息。