自动化执行权交接：保留恢复证据，安全清理旧入口

自动化更换执行者，会同时改变行动主体、现行指令和恢复时可以信任的证据。只在一份文档里替换名称，无法完成这次迁移。旧调度仍可能运行，过期手册仍可能授予权限，过度清理分支还可能删除中断任务恢复时需要的状态。

一次脱敏交接同时暴露了这三类风险。仓库的现行运营文档仍指向旧执行者；历史运行分支和交付产物又属于恢复模型的一部分；部分停用发表入口也有保留价值，因为其中的硬拒绝实现能够证明禁用操作继续不可用。

安全处理先为所有状态分类。当前权限整体迁移，历史证据保持可读，停用写入路径继续显式拒绝，只有确认可丢弃的对象才进入清理范围。

一个仓库里可能同时存在四类状态

搜索旧执行者名称会得到很多匹配，但这些匹配承担的职责不同。

状态类别	示例	交接动作
当前控制面	协作规则、运行契约、调度归属、现行运营手册	作为一个整体更新
恢复证据	运行分支、回读记录、历史产物、审计说明	按保留策略继续保存
已停用执行路径	禁用命令、拒绝测试、迁移说明	保留硬拒绝边界
可丢弃本地状态	已确认干净的闲置 worktree、缓存、临时目录	只读核对后删除

若把四类状态都当作“旧内容”，会产生方向相反的故障。保留过期控制面会留下两个表面执行者；删除恢复证据会削弱重试和审计；把禁用命令连同拒绝测试一起移除，也会让后续回归更难发现。

因此，分类必须先于清理。

把执行权作为一个控制面迁移

现行控制面包含仓库规则、运营契约、调度提示、运营手册、交接文档和当前状态说明。它们共同回答三个问题：

1. 下一次动作由哪个执行者负责？
2. 动作开始前必须具备哪些证据？
3. 哪些操作继续位于执行者权限之外？

只更新其中一项会造成内部不一致。本次实现同步修改现行文档，并增加独立的运营运行契约。草稿交付自动化继续保持原有的 draft_only 边界；运营路径拥有自己的前置条件和失败关闭浏览器规则。

这种拆分避免了权限随执行者身份悄悄扩大。新执行者获得预期运营职责，同时不会继承无关的发表 API、凭据访问或历史状态改写权限。

保留证据，不延续过期权限

历史运行分支已经不再承担功能开发，看起来很像普通杂项。本次案例中的运行分支保存了对账和恢复所需的来源版本与交付状态。删除它们能让分支列表变短，却会破坏控制器的证据链。

交接过程保留运行分支、历史产物和审计说明，也保留了拒绝旧发表路径的代码。它们继续存在并不会授予权限：当前运行契约定义唯一活动路径，测试则让旧路径保持关闭。

这一区分同样适用于 Git 之外的系统。队列记录、部署清单、外部对象身份或回读凭据即使不再参与日常操作，仍可能服务于故障恢复。保留期限应由证据用途决定，不能只按年龄或分支前缀判断。

只有形成完整处置证明，才执行删除

清理只覆盖本地 worktree、缓存、临时目录和已合并功能分支。删除前的只读检查需要同时证明：对象处于干净状态，已退出活动链路，恢复流程也没有引用它。

实际顺序如下：

1. 清点活动任务、分支、worktree 和现行契约；
2. 迁移权限并增加回归测试；
3. 合并经过精确审查的变更；
4. 核对新控制面和调度状态；
5. 删除已经证明可丢弃的对象；
6. 回读最终分支与任务清单。

破坏性清理发生在替代控制面能够验证之后。即使某项删除失败，也可以单独报告，不会让系统停留在两个执行者之间。

验证同时覆盖权限与恢复能力

本次实现同步更新现行责任文档，新增运营契约，修正缺少依据的状态断言，并增加回归覆盖。验证记录包含 74 项内容策略测试和 323 项仓库自动化测试；送审 head 随后通过仓库检查。

最终复核还覆盖真实运营边界：

• 现行文档不再把活动职责交给旧执行者；
• 草稿交付仍没有发表权限；
• 停用发表路径继续失败关闭；
• 恢复分支与历史证据仍然可用；
• 闲置 worktree 和过期功能分支已经清理；
• 仓库与调度清单指向预期执行者。

单纯搜索文本只能证明第一项。权限、拒绝规则、恢复证据和真实运行归属全部一致，才能证明交接完成。

适用边界

这套方法要求历史分支与产物具有明确的恢复或审计用途。没有这类依赖的仓库，可以使用更短的保留策略。若证据包含敏感数据，仍需设置访问控制和明确删除周期；恢复用途不能成为无限期保留的理由。

两个主机可能并发运行时，调度迁移还需要分阶段暂停。本次脱敏案例只有一个活动主机，并且完成了任务归属回读，因此不能据此宣称已经验证多主机零停机交接。

可复用原则是先按功能映射状态，再迁移自动化执行权：当前控制面整体移动，能够重建旧工作的证据继续保留，停用入口维持可证明的关闭状态，本地或远端对象只有在处置证明完整后才删除。