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

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

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

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

一套单页应用的浏览器门禁在打开某个路由时失败。此前生产构建已经完成，体积预算和单元测试均为绿色，另外八条端到端用例也成功。失败页面报告无法从 Vite 开发服务器取得一个路由源码模块。

重新运行任务可能得到绿色结果，却会保留薄弱的验证边界。准备交付的是生成后的静态构建，浏览器门禁依赖的仍是开发期源码转换与按需模块交付。

最终改动让 Playwright 在每次执行时先构建应用，再启动全新的 Vite 生产预览。原有的网络失败注入也从源码文件 URL 改到构建后带哈希的 JavaScript 资产。修改后，九条浏览器用例、本地完整门禁和最终云端检查全部通过。

失败请求暴露了测试服务器边界

失败请 …

一个定时自动化把恢复状态保存在 Git 中。长任务运行期间，它会向专用分支提交租约心跳、检查点和回读结果。这些写入有明确用途：进程中断后，接手者可以重建所有权并安全恢复。

仓库的持续集成工作流却把每次状态写入都当成代码变化。打开 Pull Request 后，同一提交可能同时触发分支 push 和 pull_request 两条运行。测试夹具出现真实错误时，状态分支持续前进，相同失败便被反复通知。一个缺陷最终看起来像几十起新事故。

稳定处理方式是让 CI 跟随审查边界。状态提交继续保留审计能力；完整验证只在代码进入审查，以及审查结果进入默认分支时执行。

先把通知、运行和提交对齐

修改工作流前， …