/sop-runbook

name: sop-runbook
description: 把重复任务和故障处理写成有前提、分支、回执、恢复与交接的规程 SOP runbook incident response

可执行操作规程与故障手册

把专家隐性步骤转成执行者能判断下一步的操作规程，并明确哪些动作需要权限、观察和人工接手。

开始前

• `task`：任务目标、触发、范围、执行角色和成功状态 缺失时：先定义范围和可观察完成条件
• `currentProcedure`：现有步骤、系统版本、输入输出、历史故障/演练记录 缺失时：未执行内容保持设计状态
• `operatingConstraints`：权限、资源、危险动作、恢复方式和升级责任 缺失时：关键权限/恢复缺失时阻断对应动作

执行

1. 阅读 [工作方法](references/professional-method.md)，先确定适用条件与证据范围。 2. 沿 [专业方法](method.json) 的 `steps` 执行具体操作，再用 [完整交付模板](references/delivery-template.md) 整理当前产物；诊断问题与空字段不能充当完成。 3. 按 [专业质量规则](method.json) 中的具体输出规则选择检查方法，保存本次输入/产物定位及未观察项。 4. 对照 [作者正反例](evals/professional-cases.json) 检查常见专业错误；作者预期不算本次评测结果。 5. 把规则结果、实际产物、未决问题交回调用方；缺口仅影响相关结论。

交付

• `procedure`：有判断条件的完整规程。
• `recovery`：失败、重试、恢复与升级规则。
• `validationRecord`：实际演练或执行证据。
• `maintenance`：交接和更新依据。
• `facts`：当前输入、来源、期间单位及证据缺口。
• `limitations`：未执行、未观察、方法假设和外推边界。
• `handoff`：当前产物、规则结果、证据定位与待解决事项交调用方。

有可选 `workContext` 时，按 [交付模板的事项交接例](references/delivery-template.md) 将身份、采用版本、实际接手回执和经验候选放进 facts / validationRecord / maintenance / handoff。没有事项上下文时不增加登记或确认；scopeRef 不授予权限。

关键验收条件

• `procedure`：每步有前提、角色、输入、动作、可观察预期、失败分支和记录位置。 拒收：只写检查/处理/完成等动作名，或依赖未写出的专家常识。
• `recovery`：分清动作未发生/已发生/结果未知，非幂等动作先核状态，恢复有前提与验证。 拒收：超时就无限重试付款/发送，或任何失败都盲目回滚。
• `validationRecord`：记录版本、环境、执行者、步骤、预期/实际和未测分支；无执行写未观察。 拒收：用完整文档或作者样例声称演练通过。
• `maintenance`：规程有责任人、版本、依赖、变更触发和已失效步骤处理，保留关键经验依据。 拒收：系统变更后仍引用旧命令，或删除历史证据使原因不可追踪。

全部检查方法、证据要求和阻断标记以 [method.json](method.json) 为准。规则未执行时记录未观察；教学案例不是已经完成的专业评测。

边界

编写规程不授予生产、付款、发送消息或危险操作权限；演练记录不能冒充真实恢复。

不可逆动作、生产变更和对外通告按本任务已有授权及相应责任流程处理；文档完善与只读核查继续。

只读本次指定材料；实际联网、命令、发布、业务变更或外部消息依当前宿主授权。方法不接管跨组件调度、持久记忆或最终验收。合同和示例检查不证明真实宿主或行业效果；无执行证据保留 needs_probe / not_evaluated。