驗證版本發佈

驗證版本發佈 是做什麼的？

當被問及 OpenClaw 版本是否已完整發佈、公告、推廣、通過冒煙測試或即時驗證時，使用此技能。這是一個驗證技能，而非發佈技能；在變更發佈狀態之前，請使用 $release-openclaw-maintainer。

規則

• 將像 .27 這樣的簡短後綴，解析為基於當前日期/上下文產生的具體 CalVer 版本，然後說出解析後的版本。
• 先解析軌道。兩個軌道都使用共享的 GitHub Release 證據分類帳。常規的 beta/stable 也使用平台圖；extended-stable 則使用其規範分支、npm 選擇器和 Gateway 面。不要從一個軌道要求另一個軌道的原生或 ClawHub 成品。
• 驗證即時狀態。不要相信本機 checkout 狀態、版本說明或舊的記憶是當前的真相。
• 如果 checkout 目錄是髒的或有分歧，僅將其用於腳本/參考。對於版本元數據，從 GitHub release/tag 獲取，或在 /tmp 下解壓縮標籤的 tarball。
• 絕不打印機密。僅將繼承的即時金鑰用於範圍限定的冒煙命令。
• 保持最終報告簡潔：是/否、證據條列、注意事項、清理步驟。

常規 beta/stable 檢查

僅對常規編排的發佈軌道使用這些檢查。

1. GitHub Release：
   • gh release view v<VERSION> --repo openclaw/openclaw --json tagName,name,publishedAt,isDraft,isPrerelease,targetCommitish,url,body,assets
   • 確認 stable 版本不是 draft 或 prerelease。
   • 確認版本說明的 body 在需要時包含 npm、CI、plugin npm、ClawHub、mac/appcast 的證據連結。
   • 確認 stable mac 版本預期的資產已上傳：zip、dmg、dSYM、依賴證據、不可變的完整驗證清單、發佈後證據以及 stable-main 結案清單。
   • 下載每個不可變的證據資產及其 .sha256 伴隨檔案，然後在信任發佈記錄之前驗證校驗和。
2. Root npm：
   • npm view openclaw@<VERSION> version dist-tags.latest dist.tarball dist.integrity time.<VERSION> --json
   • 對於 stable，latest 必須等於 <VERSION>。
   • 記錄 tarball、完整性、發佈時間。
   • 確認發佈後證據記錄了 npmRegistrySignaturesVerified: true 和 npmProvenanceAttestationMatched: true。
3. Plugin 發佈集合：
   • 從 GitHub 獲取確切的標籤元數據，當本機 checkout 是髒的時不使用它：下載 https://api.github.com/repos/openclaw/openclaw/tarball/v<VERSION> 到 /tmp/openclaw-v<VERSION>-src。
   • 使用記錄的發佈 Tooling SHA，從發佈軌道的規範發佈規劃器/收集器推導出完整的預期 npm 和 ClawHub 套件集合，並使用確切標籤的套件元數據。 不要計算原始發佈標誌：openclaw.build.bundledDist === true 即使是設定發佈標誌也會明確推遲外部發佈。單獨記錄推遲的套件名稱和原因。
   • 使用不可變的發佈計劃、註冊表回讀和工作流程作業，在原始發佈、先前發佈的版本以及選擇的恢復執行之間，調解預期的套件標識、版本和數量。選擇的恢復子集不得縮小完整的預期發佈集合：gh api repos/openclaw/openclaw/actions/runs/<RUN>/jobs --paginate。
   • 每個預期的 npm 外掛的版本必須是 <VERSION> 並且 dist-tags.latest === <VERSION>。
4. ClawHub：
   • 檢查 Plugin ClawHub Release 工作流程的結論和發佈作業計數。
   • 使用 OpenClaw 本身進行即時註冊表證明：openclaw plugins search <known-plugin> --json。
   • 從 ClawHub 以隔離的 HOME 安裝一個官方外掛，其版本為請求的確切發佈版本：openclaw plugins install clawhub:@openclaw/matrix@<VERSION>。 除非該外掛不在預期集合中，否則偏好使用 matrix。ClawHub 版本屬於規範；--pin 僅支援 npm 安裝。
5. 發佈工作流程：
   • 驗證發佈說明證據連結的結論：Full Release Validation, OpenClaw Release Checks, OpenClaw NPM Release, Plugin NPM Release, Plugin ClawHub Release, mac preflight/validation/publish（當 stable mac 資產被預期時）。
   • 對於 stable，驗證 OpenClaw Stable Main Closeout 已成功，且其清單記錄了匹配的發佈標籤、目前的回滾演練、stable 浸泡以及阻塞性能證據。
   • 僅總結相關的成功/失敗作業；忽略常規的跳過可選通道，除非版本說明了它們。

長期穩定版（Extended-stable）檢查

Extended-stable 有一個包含共享發佈證據的 GitHub Release，但沒有原生或 ClawHub 成品。同時根據即時標籤、工作流程、註冊表、來源證明和影像狀態進行驗證。

1. 身份： 要求最終的 v<VERSION> 在補丁 33+，沒有後綴，包含在 extended-stable/YYYY.M.33 中。只有一個活躍的候選者必須等於尖端。根套件和每個可發佈的官方外掛都必須宣告 <VERSION>。要求 Git 標籤以及一個公開的、非 prerelease 的 GitHub Release，其標題和規範 body 與標籤匹配。要求 isLatest=false、依賴證據、不可變的 Full Release Validation 清單、發佈後證據及其校驗和。要求沒有原生或 ClawHub 資產。
2. 工作流程鏈： 找到成功的父發佈執行，以及其 preflight、完整驗證、plugin npm 和核心發佈子執行。要求一個受保護的 release-publish/* 父執行和一個規範的 release-ci/* 驗證生產者，並帶有已驗證的工作流程 SHA 來源證明。驗證必須使用 rerun_group=all、release_profile=stable、阻塞性浸泡/性能以及保存的嘗試。核心發佈必須引用所有三個執行 ID，並將其清單、工作流程引用和 tarball 摘要綁定到發佈 SHA。
3. 註冊表： 要求精確和 extended-stable 選擇器為根套件、每個 preflight corePackageTarballs 條目以及每個從標籤推導出的 publishToNpm === true 的官方外掛返回 <VERSION>。比較外掛計劃、作業和完整的回讀；永遠不要從差異推斷庫存。
4. 來源證明： 從受信任的當前工具，執行 node --import tsx scripts/openclaw-npm-postpublish-verify.ts <VERSION>。要求簽名、規範分支來源證明以及發佈/preflight 摘要綁定到發佈 SHA。保留輸出和工作流程 URL。
5. Docker： 驗證兩個註冊表中的確切 default、slim、browser 和架構影像以及證明。只有三個 extended-stable* 別名可以解析為那些摘要。要求成功的 OpenClaw Release Publish 父執行及其完成的 Docker 驗證。正常路由在之後完成；明確請求的快速路徑可能首先啟用 GitHub。透過 current-main Docker Channel Promotion 為確切標籤修復別名，無需重建。
6. 恢復： 絕不重新發佈。為根選擇器（一個無後綴的最終補丁 33+）在 openclaw/releases dist-tag 工作流程中使用 promote_extended_stable，並為其他使用經過批准的、憑證隔離的工具，然後重複完整回讀。不要要求 ClawHub、原生/行動應用程式、網站、私有 dist-tags 或常規 latest。要求共享的發佈證據，但不要要求常規的原生或 ClawHub 資產。

共享即時冒煙測試

在軌道特定的發佈檢查通過後：

1. 已發佈套件冒煙測試：
   • 在 /tmp 中，使用隔離的 HOME：npm exec --yes --package openclaw@<VERSION> -- openclaw --version。
   • 執行至少一個無害的命令，該命令會觸及已發佈的 CLI 面，例如 plugins --help 或 gateway --help。
2. Dev Gateway 即時模型冒煙測試：
   • 使用暫存的 HOME/workspace，而不是使用者的正常狀態：HOME=/tmp/openclaw-release-smoke/home OPENCLAW_WORKSPACE=/tmp/openclaw-release-smoke/work pnpm openclaw --dev gateway run --auth none --force --verbose。
   • 從啟動輸出或日誌中解析已啟動 Gateway 的綁定端口。
   • 對於 --auth none，要求未經認證的 GET http://127.0.0.1:<PORT>/healthz 返回 HTTP 200 以及確切的 JSON 物件 {"ok":true,"status":"live"}。
   • 保留 gateway health --json 用於有意使用憑證或裝置配對的冒煙測試，傳遞該 Gateway 所需的明確憑證。
   • 使用繼承的 OPENAI_API_KEY、簡短提示、明確的會話金鑰、JSON 輸出以及已知可用的模型，執行一個 Gateway 支援的代理回合。
   • 如果配置的預設模型因不可用而失敗，記錄該注意事項，然後使用最新的已知良好 OpenAI 模型重試，而不是宣告版本發佈失敗。
   • 停止 gateway 並驗證該端口已不再監聽。

需要報告的注意事項

• Dist-tag 注意事項：stable latest 是發佈真相；如果可選的 beta 鏡像仍然指向一個 beta 版本，請將其報告為注意事項，而不是 stable 發佈的阻塞點，除非使用者要求驗證 beta 推廣。
• 軌道注意事項：命名軌道以及故意缺失的面。不要將缺失常規版本成品報告為 extended-stable 失敗。
• Checkout 分歧注意事項：當本機原始碼 SHA 與發佈標籤或 origin 不同時，說明哪個即時來源被用來替代。
• 冒煙注意事項：區分 Gateway 支援的代理成功與本機嵌入式回退。一個有效的無認證即時冒煙測試必須有確切的 /healthz 結果，加上一次成功的 Gateway 支援代理回合，以及該呼叫的 Gateway 日誌/執行 ID。