平台交付矩阵

先区分桌面安装包与内核产物，再判断版本覆盖了哪些平台。Linux 内核产物不代表 Linux 桌面安装包，网站下载按钮也不能证明平台验证通过。

桌面交付矩阵

macOS 另提供 PKG 下载。PKG 使用 Developer ID Installer，DMG 使用 Developer ID Application，两者分别验证。更新器使用 DMG，不能把 PKG 放入其平台槽位。

PKG 证书配置错误阻断签名流水线；DMG 完成后出现的 PKG 外部打包或公证失败按降级规则记录。任一架构缺少 PKG 时，下载清单退化为双架构 DMG，不提供单架构 PKG 入口。

内核与桌面不是同一矩阵

内核仓库提供平台 bundle，桌面使用与版本绑定的 sidecar。Linux GNU 目标在内核发布记录中核对，不能算作桌面安装包，也不能用 npm 包或网站构建结果替代。

桌面联合发布使用的 bundle 必须覆盖 macOS arm64、macOS x64 与 Windows x64。每个目标都需证明版本、来源、摘要与运行结果。

包类型影响哪些验收结论

同一操作系统上的包类型承担不同交付路径。DMG 与 PKG 需要分别核对签名和安装结果；Windows 在线引导器还要验证它最终取得的完整安装包。只检查引导器能够启动，不能说明下载、校验和安装链路已经通过。

场景：可选 PKG 未齐套

先区分必需桌面产物是否完整与可选包是否完整。DMG 双架构和 Windows x64 是公开桌面更新的必需集合；PKG 入口要求双架构配套。只有一个架构的 PKG 时，不把这个单独入口作为完整 PKG 交付公开。

签名配置错误与 DMG 完成后的外部 PKG 打包或公证失败，按发布规则分别处理。矩阵记录失败阶段和降级后的实际交付范围，不把“提供 DMG”写成“PKG 验证通过”。这使发布负责人能够判断哪些入口可以上线，以及哪些平台或包仍需补齐。

记录平台结果

分别记录系统、架构、安装包 URL、源码 SHA、摘要、签名、平台校验、启动及更新演练。区分通过、失败、未执行和不在本次范围。

Pre/Beta 允许分平台交付，公开更新指针等待三个桌面目标齐套；Stable 必须全部满足门禁。详见验证与晋级。

如何填写一次交付矩阵

以“版本 × 系统 × 架构 × 包类型”为一行；内核 bundle 另列对应版本和摘要。每行至少记录来源提交、最终下载地址、签名结果、安装启动结果、更新结果和证据位置。没有运行的平台测试填写未执行，不借用另一架构的结果。

发布负责人先检查必需的三个桌面目标是否同号齐套，再检查可选 PKG 是否双架构同时可用。缺项必须明确阻断的是单个产物、公开更新指针还是 Stable 晋级；修复后只更新有新证据的行，并重新核对整套版本一致性。