一次 Windows 全量测试出现了两组错误，而且都发生在产品断言之前。第一组需要解析子进程返回的 JSON，却拿不到可用的 stdout；第二组刚创建临时 Git 仓库，工作区立即显示已有修改。

应用逻辑没有回归。测试夹具让工作站默认值参与了证据解码和仓库初始化。修复这两个边界后，34 个准备阶段错误消失，原本要验证的业务断言才能正常执行。

两组症状都指向产品代码之外

第一组共有 10 个子进程错误。子命令输出 UTF-8 文本，其中包含非 ASCII 字符。帮助函数使用 text=True 和 capture_output=True，却没有指定编码。受影响的 Windows 主机在捕获路径 …

一个仓库看起来只有普通文件冲突，实际同时保存着两类未完成工作。一份运行配置在 Git 索引中存在多个未合并条目；另一份源文件已经暂存了独立且需要保留的修改。仓库当时没有正在进行的 merge、rebase 或 cherry-pick，无法依赖某个完整操作的上下文，也没有适合直接执行的统一中止动作。

若使用范围宽泛的 reset、restore 或 checkout，状态列表可能很快变得简洁，另一份暂存工作也可能随之丢失。最终处理把索引视为需要保护的状态，只解决未合并路径，再分别验证冲突结果和原有暂存差异。任务范围没有包含 commit 与 push，因此处理在暂存区正确后结束。

状态列表里有两 …

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

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

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

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

搜索旧执行者名称会得到很多匹配，但这些匹配承 …