產物驗證與渠道晉級
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 產物、公開下載入口和應用更新入口，記錄請求渠道、實際渠道與實際版本。
公開入口仍提供上一完整版本時，將當前候選記為已交付但未公開更新，不記為渠道上線。檢查失敗時停止後續晉級，修復候選或按發佈流程回退指針，再重新檢查最終入口；不能只憑流水線結束就宣告完成。