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

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

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

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

IDE 已经完成编译和产物准备，应用服务器却没有进入部署。真正中断启动的是调试器监听器绑定失败：配置的地址无法绑定，日志提示该地址已被使用。

常见判断是“另一个进程占用了端口”。本次现场却出现了一个容易误导排查的现象：稍后检查时，没有普通进程在监听；Windows 返回的排除 TCP 端口区间却包含这个配置值。只修改调试端口后，完整启动链路恢复。

这说明 Windows 上的固定开发监听器不能只做进程占用检查，还要避开机器当前的动态分配范围和显式排除区间。

先把故障放回启动时序

IDE 启动应用服务器时，会依次跨过多个边界：

编译源码
  -> 构建产物
  -> 绑定调试套接字 …

Typora 的导出菜单里已经出现 DOCX 与 EPUB，但选择后无法启动转换器。编辑器本身工作正常，原生输出路径也没有异常。缺失的环节是这些扩展格式依赖的外部程序。

Typora 官方文档说明，HTML、PDF 和图片可以直接输出，Word、RTF、EPUB 等格式则会调用 Pandoc。文档还建议安装后重启应用；若仍无法发现 Pandoc，应在导出设置中手动选择其可执行文件（Typora 导出文档）。

本次处理严格限制范围：先确认转换器状态，只安装一份 Pandoc，显式绑定可执行文件，再检查真实 DOCX 与 EPUB 包。流程没有增加 PDF 引擎，也没有改写其他 Typora 高级 …

一个桌面任务存储在归档近期任务时持续返回“找不到文件”。会话内容仍可读取，源文件确实存在，状态数据库的完整性检查也正常；重复调用归档接口，结果没有变化。

排查线索落在路径身份上。部分旧记录保存的是物理存储根目录，当前应用则统一从逻辑主目录访问数据。目录链接让两种写法都能读到同一份字节，但归档事务没有把它们视为可互换的路径。

这个案例说明，“文件存在”只覆盖了路径故障的一部分。持久化路径身份与应用当前使用的根目录发生漂移，同样会让有状态事务失败。

先分开现象与证据

界面报错可能来自源文件丢失、权限不足、数据库损坏或路径过期。任何修复之前，先用只读检查缩小范围：

• 目标记录仍在状态库中，归档状态没 …

在 Windows 下，rg（ripgrep）是非常常用的文本搜索工具，但在客户端升级、环境改动后，它可能突然从 PowerShell 的可执行搜索路径中消失。

这次是一次比较典型的“只报 command not found”问题：PowerShell 返回 rg : The term 'rg' is not recognized...，却难以快速判断是软件没装、PATH 失效，还是会话缓存导致。

问题点

从现场行为看有三类风险点：

1. 当前会话无法发现 rg.exe；
2. 之前处理方案依赖了固定路径，缺少迁移弹性；
3. 后续执行链条未加入足够的命令可用性兜底。

因此修复策略是将重点放在“命令恢复 + …

Windows Store 的商品页可以正常打开，开始安装时却只显示通用的稍后重试。前台应用与安装服务读取了不同的网络状态：桌面会话使用当前可用的本地代理，服务级 WinHTTP 配置仍指向已经没有监听进程的旧回环端点。

对齐代理后，目录与许可请求恢复，随后又出现了独立故障：大文件下载长时间停在同一字节数，而对实际内容主机进行直连和代理测速都很快。最终处理把两段故障分开，允许微软大文件 CDN 直连，并只重建已经证实卡住的 Delivery Optimization 下载项。安装包随后完成下载与部署，系统始终没有开启全局 TUN。

目录可用无法证明安装路径可用

通用错误很容易让人直接重置 …