第 5 节 · 约 35 分钟
退回代码之前，先管住正在写的那一笔。
在自己的隔离环境和合成工单上演练。五分钟是本次演练目标；是否真的达到，要靠时间记录和复验。
先讲
把一次发布固定成可找回的组合：代码提交或镜像摘要、提示词文件版本、工具 schema 版本、模型标识，以及影响行为的配置。模型提供方若只给会变化的别名，就记录测试日期与实际返回的版本信息；不能只写“最新版”。密钥只记录引用名，不复制密钥值。
回滚应用不会撤销已经提交的工单。发现异常先暂停新的写入，把在途操作标成待对账，再切回经过验证的组合。操作号与回执账本要保留；把数据库也回退到昨晚，可能丢掉去重记录，下一次重试又写一笔。
本课前几节的 Ledger 在内存里，只适合单进程演示；重启会丢记录，不能据此声称完成了可靠发布。选做真实接口演练时，要先有持久化操作记录。暂时没有环境，可以完成下面的纸面演练，并明确标注“尚未实际部署”。
- 候选提示词把已批准的 note 改了；写入保护正确拒绝，新增写入 0 次。这条安全断言仍应通过，正常任务成功率可能下降
- 若实际上写入了不同 note，才是“批准 A 执行 B”的否决失败；立即停写并保留脱敏证据
- 回退代码、提示词与工具兼容版本；不回退已产生的操作记录
- 复跑篡改 note 用例，期待写入 0 次；复跑正常关闭及超时用例，期待提交 1 次和同一回执
- 记录开始/恢复时间，再按原操作号核对在途关闭的最终结果
你来做
新案例：回滚完成了，用户却还在重试
14:03，v2 已提交 op_close_5100，回执丢失。14:04 发现新提示词异常；同事建议“恢复 v1 镜像，再恢复昨晚数据库，用户重新点”。请写出前五分钟动作、哪些状态必须保留、怎么回复用户，以及恢复写入口之前要跑哪些检查。
先写自己的步骤，再对照参考
先停新的写请求，保留 op_close_5100 为结果待确认；沿原号查询服务端回执，拿到后告知已完成，拿不到就告知待确认，不让用户换号盲重试。回退应用及兼容配置，保留幂等账本、审批审计与已提交事实；数据库恢复不是应用回滚的默认步骤。
恢复前验证：篡改/过期审批零写入，正常关闭一次提交，提交后超时返回同一回执，未授权数据不进入返回和日志。至少记录版本组合、命令、开始与结束时间、测试输出、在途操作处理结果。只有纸面步骤就标注“计划”，不能写“演练成功”。
下面是你的自报检查，不会读取环境或验证部署。
留下三步能照着做的回滚。下一节把这些写成一句不会碎的话。