产物验证与渠道晋级
EvoX Desktop 的发布链是 main → Pre → Beta → Stable。晋级固定的是已发布候选的源码提交，不能混入主分支的新改动。
区分公开入口与原生渠道
官网 Stable 下载入口按清单解析规则允许回退到 Beta。核对下载时记录请求渠道和实际解析渠道，不能仅凭打开 Stable 页面就认定原生 Stable 已发布。网站的原生渠道检查使用 --require-native-channel，要求目标渠道自身提供有效清单；入口可用检查与原生渠道验收分别记录。
各阶段的来源与门禁
| 阶段 | 来源 | 发布条件 |
|---|---|---|
| Pre | 发布时重新获取的最新 main | 为本次交付平台生成正式签名产物，验证来源、摘要和清单。 |
| Beta | 明确指定的一枚已发布 Pre | 桌面与内核都锁定该 Pre 的不可变标签提交，执行对应发布门禁。 |
| Stable | 最新验收通过的 Beta | 精确复用该 Beta 的提交，满足完整 required CI、平台齐套和发布审计门禁。 |
三通道使用相同的正式构建配方、签名、公证与更新身份。Pre/Beta 允许分平台交付，不允许交付签名失败的平台。Stable 桌面发布必须覆盖 macOS arm64、macOS x64 与 Windows x64。
晋级时固定什么，重新验证什么
晋级固定候选的代码来源，渠道名称变化不能成为引入额外代码的理由。验证仍针对本次实际交付的安装包、签名清单和公开入口进行。源码相同不能替代最终字节检查，最终字节通过也不能替代渠道指针检查。
| 验证层 | 需要回答的问题 | 保留的证据 |
|---|---|---|
| 候选来源 | 是否来自指定的 Pre 或 Beta 提交 | 标签、完整 SHA、关联发布记录 |
| 安装包 | 是否为正确平台的可验证最终产物 | 最终 URL、摘要、签名与平台验证 |
| 渠道清单 | 是否指向同号齐套的目标产物 | 清单版本、平台槽位与解析结果 |
| 用户入口 | 下载和更新实际提供哪一版 | 请求渠道、实际渠道、实际版本 |
场景：Beta 产物已经有了，官网仍显示旧版
先区分单个平台的 Release 产物与公开更新入口。Pre/Beta 的某个平台先完成时，候选产物可以存在，而公开指针继续保留上一完整版本。核对三项必需桌面目标是否同号齐套；未齐套时，这属于等待补齐的发布状态，不能直接判断为网站缓存故障。
齐套并完成指针切换后，再从最终入口核对版本和字节。请求 Stable 时还要记录是否解析为 Beta：入口成功下载说明可用性通过，只有目标渠道自身的清单满足检查，才能把原生渠道验收记为通过。
逐个验证候选产物
- 固定源码仓库、完整提交 SHA、版本与平台架构。
- 检查实际安装包的签名身份及平台验证结果。
- 上传后从最终 URL 重新下载，核对文件名、大小与 SHA-256。
- 验证签名清单与下载字节、平台及渠道一致。
- 分开记录机器检查和真实安装、启动、更新演练。未执行的人工步骤不能写成通过。
macOS 的结果不覆盖 Windows，DMG 的结果也不覆盖 PKG。
安装包发布与更新上线
Pre/Beta 的单平台安装包成功发布后，可从对应 GitHub Release 下载。桌面更新清单先进入 staging；只有同号 macOS 双架构和 Windows x64 都发布完成，才切换公开更新指针。补齐前，应用内更新和官网下载继续提供上一枚完整版本。
安装包存在、平台验证成功、公开更新入口上线是三个不同状态，需要分别确认。
阻断与修复
来源、版本或平台不匹配时停止晋级。签名、摘要或公证失败的平台不得交付；Stable 必需平台或检查缺失时停止 Stable 发布。
Beta 需要代码修复时，先合入 main，发布新的 Pre，再晋级新的 Beta。不可变标签和已发布文件不能覆盖复用。渠道指针回退也不等于已更新的客户端自动降级；恢复结果必须单独验证。
晋级完成的判定
保存候选标签与提交、各平台验证记录、批准记录和切换后的清单结果。分别核对 GitHub Release 产物、公开下载入口和应用更新入口，记录请求渠道、实际渠道与实际版本。
公开入口仍提供上一完整版本时，将当前候选记为已交付但未公开更新，不记为渠道上线。检查失败时停止后续晋级，修复候选或按发布流程回退指针，再重新检查最终入口；不能只凭流水线结束就宣告完成。