PM 审计整改状态

这是一份历史审计记录，不是当前主干的发布状态页。 下文的计数和原生回执仅适用于它们所指明的版本。 后续工作新增了共享 bundle 组装、签名包 E2E、稳定发布门槛、Termux APT 分发以及 Python 3.14。这些变更不会追溯性地延伸早期测试回执。

如需了解当前实现契约，请参阅 Package management、共享 bundle 构建、稳定发布 以及 bundle 更新验收。

本次变更整合了汇总分支审计中的修复内容。它不是发布证明。该审计对比了 49945b14029e09fef608db9ede899377cdb54e11 与合并基点 433f7196760e5d76f77ea6d5464ee7f1b602a4ee。

文档审计之后的运行时修复 {#runtime-repairs-after-the-documentation-audit}

审计发现 Electron 中存在 Python 布局不匹配、Nix 中 Python 族被写死、密码学依赖要求相互矛盾，以及干净 Windows 安装失败等问题。后续变更修复了各自的所属实现：

  • bundle 构建器检查完成后的载荷，并发布其启动路径。Electron 消费该契约，而不对载荷做探测、接管或创建。
  • Nix 从 pm/lock.json 选取 Python 的主/次版本号。uv2nix 环境、软件包覆盖、额外软件包和开发者 shell 都使用该版本族。真正的 Nix 求值和构建验收仍是 CI 门槛。
  • 直接的密码学依赖要求和安全覆盖与 uv.lock 中被补丁的版本一致。该覆盖仍绕过厂商 SDK 陈旧的版本上限。
  • bootstrap 等待 uv 结束，再直接通过 Python 运行 PM。PM 可以替换自己的 uv 入口，而不会被 bootstrap 占用其可执行文件。
  • PM 回执发布在共享锁下使用仅依赖标准库的原子 JSON 写入。失败报告不再通过 utils 导入 PyYAML。
  • 未使用的开发 shell 命令被移除。"安装加激活"和 deactivate 是唯一的 PM 开发者路径。

一次原生 Windows 检查在可丢弃 home 中、以空工具存储起步。安装完成、PM 发布了一份依赖生成物，PowerShell 激活运行了存储解释器和 source CLI。另一次独立的 PM 安装通过了其真实依赖检查。这些检查不能证明签名包安装、更新或 Nix 构建。更广泛的 PM 插件/配置 YAML 耦合保持不变。开发者工作流区分了运行时激活与独立的测试和编辑器环境。

已实施的修复 {#implemented-repairs}

发现项实现
C01、C11、C12、C24移除已删除的 TLS 导入；修复 ACP 文件解码、代理路径归属以及监控 SDK 调用。
C02恢复代码执行的 schema、注册和子进程生命周期处理。
C03、C04、C17保持更新元数据命令只读；同步插件更新；正确比较 feed 身份。
C05、C27、C28把托管 Python 纳入安装闭包；修复安装器阶段分发和运行时选择。
C06、C07、C09移除不受支持的 SCM 接口。保留计划任务监督，并在桌面退出时保护无关运行时。
C08、C19修正 App Installer 检查器，恢复有意义的更新状态。
C10修复卸载分发和归属链接移除。
C13、C14发布前准备一套完整的依赖环境。保留已声明的约束和显式锁定；允许兼容的传递升级。基础设施故障不会使插件被禁用。
C15、C18发布失败时保留可恢复的工具存储条目。使用原子的事实/配置写入和上下文本地回执。
C16、C29迁移被移除的依赖辅助函数，恢复缺失依赖的提示。
C20、C21修正平台测试选择，并让"已移除导入"守卫检查真实源码。
C22、C23在 feed 之前发布不可变的发布产物，并按目标解析 FFmpeg 产物。
C25保留暂停的下载、恢复句柄和单 worker 归属。
C26把启动和插件节奏路径接到其现有的归属方。

"已实施"并不意味着每个平台验收测试都已完成。更新器、备份、安装、语音-文本辅助以及若干插件现在对每个已调和的关注点都使用一套实现。运行时路径在 pm/environments.py 中有共享归属方。

收尾实现 {#closure-implementation}

契约归属方与证据
中断的发布hermes_cli/runtime_state.py 记录旧配置和提议配置的哈希。启动时在依赖激活前进行恢复。恢复拒绝覆盖无关的编辑。真实子进程测试在事实发布前后均有终止。
存活世代回收启动时在发布锁下持有一个世代租约。pm gc 只回收未被选中、由租约管理且没有存活读取者的世代。测试在回收运行时保持一个真实读取者存活。
回执关联PM 完成项携带发起它的更新 ID。更新器嵌入该完成项，包括失败步骤和拒绝原因。嵌套命令和被复制的上下文不能终结外层回执。
警告入口Doctor 使用更新检查器的本地来源规则。桌面读取同步状态，区分健康的 no-op 与嵌入的失败。
更新器归属electron/updater/checkout.ts 负责 checkout 检查和交接。main.ts 提供其依赖。
Windows 重启一个分离的 PowerShell 等待器在退出前快照包身份，等待原进程退出，再等待已安装版本发生变化。注册失败会产生手动重开警告。
测试完整性TCC 行为使用真实主机标记。安装器的源码 grep 断言已移除。运行时和安装器行为测试保留。

已验证的执行 {#verified-execution}

  • 最近一次完整的原生 Windows Python 运行报告：跨 3,746 个文件，44,557 通过、1 失败、1,404 跳过。整个运行期间 Python 源码哈希保持不变。它还报告了一个"重试后通过"的 HTTP 测试。安装 ID 竞态和该 HTTP 测试随后被修复。这两个文件无重试地通过了 35 项测试。这不是一次完整的最终主干套件通过。

  • 根目录 npm run check 以退出码零完成，包含 MSIX 打包。桌面 UI：7,231 通过。Electron：2,311 通过、23 跳过。TUI：1,719 通过、8 跳过。Dashboard：291 通过。根 JS：77 通过。类型检查和 lint 无错误。既有的 lint 警告保留。本次打包检查使用的是主构建目录中已有的载荷，而非单独验证过的全新审计载荷。

  • 真实核心项目通过工作区辅助工具完成解析和构建。导入从生成的工作区解析，源码锁未改变。

  • 一个全新的原生 ARM64 PM bundle 完成了其锁定工具检查和全 extras 环境构建。其 manifest 记录源码树为 60c9fb444c93e8a79ae22a01677c3291385343a6。

  • 重新构建的 thin 桌面在隔离 home 中两次启动其真实后端，应答 HTTP 200，并干净退出。home 条目在重启后保留。

  • 一个真实的隔离 API-server 消息网关在普通桌面退出后保留了其 PID 和启动时间。桌面后端停止了；网关没有。

  • 用真实打包工具链构建的 thin MSIX。Windows Sandbox 安装了版本 0.17.0.0，更新到 0.17.0.1，并在卸载后验证其已不存在。测试证书的创建和信任仅限于该可丢弃 guest。

  • 从载荷树 60c9fb44... 产出了另一个全新的 bundle MSIX。解包产物自带的 CLI 可运行，导入在其载荷内解析，hermes serve 应答 HTTP 200。Sandbox 部署尝试因解包路径错误而失败。它不能证明 bundle 安装。

  • 插件检查现在从第一次 housekeeping tick 就开始运行，网络检查受配置的间隔门槛控制。一个真实的隔离网关相隔一个 tick 写出两份成功的插件检查回执。自动应用被禁用。

这些回执覆盖不同层。thin 包部署和解包运行时启动不能证明 bundle 安装或 App Installer 触发的重启。没有任何测试发送 LLM 请求作为本次验收通过的证据。

可合并收尾 {#merge-ready-closeout}

该分支包含上游 5bd439d3ed4ae5f099857813383389dcd0ab4369。早前审计中的以下限制已解决：

  • 仅上下文的 home 在日志恢复、所选运行时状态和插件并集之间共享同一个依赖根。回归批次通过了 71 项测试，8 项因主机跳过。
  • tests/tools/test_subagent_steer.py 曾产生相对路径的 MagicMock 数据库。其 mock 父级现在显式地不持有数据库。委派验证批次通过，没有新增碎片。早前的碎片已归档到仓库之外。
  • Docker bootstrap 纳入了 PM 在第三方依赖存在之前就导入的标准库运行时路径和锁归属方。修复后两种架构的构建均通过。
  • 安装器路径探测不再读取缺失的锁文件。PowerShell 5.1 和 7 的安装器测试在 CI 中通过。
  • 服务运行时选择使用共享的所选环境解析器。PM 事实提供托管 Node 路径。原生 fixture 使用可丢弃 home。
  • Windows 更新器使用其已注册的 App Installer 源，除非配置了显式的 feed 覆盖。它在拆卸前下载描述符并打开本地文件。它不要求已禁用的 ms-appinstaller: 协议。

非 E2E 收尾 {#non-e2e-closeout}

a27cd5902a446eb4f1e457e09904d75edc616c2e 上的完整 CI 工作流成功完成：

  • Linux：46,041 通过、0 失败、492 跳过。无仅靠重试才通过的不稳定用例。
  • macOS：94 通过、0 失败、121 跳过。无仅靠重试才通过的不稳定用例。
  • Windows：178 通过、0 失败、174 跳过。一个 pipe-drain fixture 仅在重试时通过，因为其冷子进程超出了空闲窗口。

提交 04182813cfa74111c6e4e10bedcc0f9de6510f55 限制了 Windows 嵌套进程并发，而没有放宽该 fixture 的断言。它还修复了计算主机的 stdin 分帧：一个真实的 Windows 子进程收到了它的首轮，但没有通过文本流收到后续的控制帧。字节流读取器通过了真实的中断和第二轮测试。这些测试现在在每条原生操作系统流水线中运行。

其他测试修复区分了 worker 调度与被测行为。压缩等待引擎入口，cron 断言观察被阻塞的工作，孤儿拆卸断言恢复锁处于空闲，托管房间测试在并发快照后观察持久的已决状态。定向父进程验证通过了 638 项网关/委派测试、41 项 cron/卫生测试、4 项压缩隔离测试、53 项托管/计算测试以及 19 项真实子进程/计算协议测试。这些批次相互重叠；它们不是整套件的总数。

浏览器 BOM 回归在读取修复前失败、修复后通过。其文件通过了 79 项测试，2 项因主机跳过。完整的 Windows-footgun 和插件兼容性检查通过。

Bundle 验收（独立工作流）{#bundle-acceptance-separate-workstream}

从 07ee9299790e5635fd917da1769f969f14fc8030 构建的真实 bundle Windows ARM64 MSIX，在一个可丢弃的 Windows Sandbox 中以版本 0.17.0.0 安装。其已注册应用呈现了 UI，"关于"识别出内嵌的运行时，其自带的打包后端应答 HTTP 200。未签名构建产物的 SHA-256 为 31d3dfb53977e0e8fd662d0ef2475a7be92a31a49d6e514ceed812099867f304。测试签名和信任仅限于该 guest。

该 guest 在更新/重启验证完成前被终止。不存在自动更新的验收声明。该产物还早于后续的上游集成和计算主机修复。Bundle E2E 工作属于既有的安装/更新测试家族，而非第二条本地 Sandbox 流水线。

剩余门槛 {#remaining-gates}

  • 最终主干的原生 CI 必须确认最新修复没有仅靠重试才通过的失败。
  • 维护者必须决定 needs-decision 的处置方式，并在评审后打上 ci-reviewed。手动 CI 会跳过仅针对 PR 的评审门槛。
  • 自动包更新/重启仍归独立的 E2E 工作流负责。

PR #95281 因被 #102765 取代而关闭，这是遵循"只需一个规范 PM PR"的分诊请求。重复标签已移除。没有自我批准标签。

在 a27cd5902a 处已验证的 CI。精确主干验证在一条上游验证分支上使用同一工作流。早前的 GitHub graph 失败报告为 resource_exhausted: gitmon refuses to schedule us: fail-fast:network。

外部审计目录包含原始发现、精确的测试选择、逐轮日志、源码快照和评审裁决。主机应用、证书信任和生产服务在该审计期间保持不变。那次审计没有发布版本；本文不对后续运行做任何陈述。