release-openclaw-ci

OpenClaw 發布 CI

當發布候選版本需要完整驗證、安裝/更新證明、即時提供者檢查或 CI 恢復時，請與 $release-openclaw-maintainer 和 $openclaw-testing 一起使用。

護欄

• 未經明確操作者批准，不得進行版本提升、標籤、npm 發布、GitHub 發布或發布推廣。
• 在壓縮、恢復或新的引導之後，根據最新的明確操作者指令重寫有效目標和當前階段。不要將舊的範圍合併回活躍的發布中。
• 一旦存在發布分支或程式碼 SHA，即鎖定發布範圍。驗證並發佈該確切版本；不要將移動中的 main 變成第二個工作隊列。
• 記錄 C (候選), Q (資格審查), P (准入/驗證者/發佈者)、重新執行群組、設定檔、有效等待時間以及內容/傳輸參考。新候選資格的預設值為 Q=C，包括完整工作流程、可重複使用的工作流程、本地動作、腳本、規劃器、合約和覆蓋範圍的閉合。程式碼 SHA 和發布 SHA 仍然是生命週期角色，而不是額外的工作流程身份。
• 候選輔助程式接受不存在的發布標籤，或解析為確切候選 SHA 的現有輕量或註釋標籤。衝突的標籤或遠端查找失敗會停止驗證；切勿移動標籤來恢復。
• 凍結 C/Q 並在 main 或受保護的發布標籤上獨立選擇受信任的 P。C/Q 不必是 P 的祖先。缺少候選合約需要有意的反向移植；切勿默默替換較新的 main 工具。
• 在程式碼 SHA 凍結後套用發布防火牆。僅允許已確認的產品缺陷、錯誤或無法驗證的套件位元組、安全缺陷或使發佈不可能進行的失敗。將其他發現排入發佈後信心或下一個測試版的隊列。依賴性建議絕非防火牆准入項目：將其記錄為發布證據，並在發佈後將版本提升排入 main 的隊列；只有已知的惡意軟體才能停止發佈。
• 凍結的 CI 子項使用 Q 的 Node 分片規劃器和測量成本，同時從候選結帳中發現並執行測試。託管的完整發布計劃將測量行拆分為超過 12 分鐘的區塊；保留檔案覆蓋範圍、工作者限制和完整的計時生成。不可分割的超預算擁有者必須被拆分，而不是增加發布預算。子項完成後，收尾作業會針對該確切執行執行 scripts/ci-shard-timings-refresh.mts 並提交生成的成本；請勿手動編輯測量值。
• 候選資格審查執行其自己的凍結 Q 閉合。僅限 main 的檢查和未來 main 的場景不是隱含的發布要求。修復凍結的資格審查工具意味著新的 C/Q，並帶有新綁定的證據。僅限 P 的准入/驗證者/發佈者修復可以保留 C/Q 及其原始證據。
• 受保護的輕量級 release-publish/<12sha>-<provenance-run> 標籤標識 P，而非 Q。後綴記錄標籤創建來源，而非當前父項。發佈輔助程式保留其 --workflow-sha <P> 參數；FRV 輔助程式的 --workflow-sha 改為選擇 Q，並且在候選路徑上必須等於 C。
• 僅在操作者要求的更改或阻礙此發布且無法從發布分支處理的最小的關鍵 main 擁有的阻塞器時，才觸及 main。Main 的 CI 健康狀況絕不閘控發布。如果發布工具落地被並非它引起的 main 失敗阻塞，請在乾淨的 main 結帳上證明該失敗已存在，將其記錄在 PR 主體中，然後合併；在活躍發布期間，允許管理員合併該確切情況。一條單獨的通道平行修復紅色的 main，不影響發布的關鍵路徑。
• 僅將工具修復落地到 main 上，並在推送前新增 release-fast-lane 標籤（請參閱發布工具快速通道）：然後 openclaw/ci-gate 僅執行 lint、類型、護欄、依賴項、文件和更改的 Node 行。透過原生的 scripts/pr 路徑及其完成的 ClawSweeper 審查落地；對於該標籤，發現結果是建議性的，因此請記錄發布所有者拒絕修復的任何 P1，並在 PR 中附上其後續行動，然後再落地。
• OPENCLAW_RELEASE_RUNNER_GROUP 可選地將驗證父項和工作者以及發布發佈父項及其發佈子項路由到保留容量，標籤保持不變；具有憑證的發佈和批准作業保留在預設的 GitHub 託管標籤上。首先設定符合條件的執行器和儲存庫存取；取消設定則保留普通路由。共享工作者繼承呼叫者群組；PR/main CI 和不相關的排程工作保持在其外部。
• 在分派新的 main 驗證之前，請檢查夜間父項的程式碼 SHA；它密封了每個子項的收據，當輸入匹配時，確切目標分派會採用這些收據。夜間執行此明確的受信任 main 輔助程式路由 (--sha <main-sha> --workflow-sha <main-sha> --trusted-workflow-ref main)，因此其父項在 release-ci/<sha12>-<id> 分支上執行，而不是在 main 上。
• 每個選定的驗證通道都必須通過；請參閱發佈要求。穩定標籤需要穩定/完整的證據、等待時間和阻塞性能。測試版設定檔證據不能限定穩定版本。沒有通道或等待時間豁免可以繞過這些要求。所有群組資格審查需要所有九個 Linux/Windows/macOS 閘道安裝/升級組合。保留首次失敗、身份和完整證據。
• 原生 macOS、Windows、Linux 和 Android 發佈獨立於 npm/ClawHub、GitHub 最終化和 main 收尾。每個平台保留其自己的簽署、資格審查、工件和更新程式要求；準確報告待處理平台，並平行修復僅限原生的失敗。
• 不要從未經驗證的 1Password 候選版本設定 GitHub 密碼。如果候選版本返回 401/403，請保留現有密碼並報告確切缺失的提供者。
• 對密碼讀取/寫入使用 $one-password：一個持續的 tmux 會話，僅限目標項目，無密碼輸出。
• 使用 pnpm frv watch --run <parent> 監看一個父項執行（請參閱監看）。避免廣泛的 gh run view 輪詢循環；REST 配額很容易耗盡。
• 僅獲取失敗或當前阻塞的工作的日誌。如果配額不足，請停止輪詢並等待重置。
• 將即時提供者問題與程式碼故障分開處理：在編輯程式碼之前，先證明金鑰有效性、提供者 HTTP 狀態、重試證據和確切失敗通道。
• 在診斷即時提供者故障時，模型列表回應證明的是身份驗證，而不是計費或推斷權利。在將憑證視為有效之前，請先使用真實的完成探針確認憑證。首先修復憑證；不要僅僅為了繞過失敗的發布憑證而新增替代身份驗證路徑。
• 完整發布驗證分離了確切子項分派、發布決策和診斷引流。使用 fail_fast=false，它會進行零個子項取消呼叫；診斷引流會跟隨每個選定的子項直到終端，除非收集器本身被取消或失去 GitHub API 存取權。使用 fail_fast=true，發布決策只能取消擁有阻塞失敗的確切仍活躍的子項。
• 相同父項的繼續要求原始根項已使用 fail_fast=false 分派。控制器在任何重新執行變異之前驗證該確切記錄的輸入。
• 產生了自己的密封候選工件的父項無法繼續：GitHub 重新執行使這些先前嘗試的工件不可用。保持候選和資格審查 SHA 凍結，取代該父項，並開始全新的所有群組完整發布驗證。
• 分派後，一個不可變的執行計劃工件記錄原始父項嘗試、確切子項元組和標題、選定的覆蓋範圍、閘道和重複使用身份。相同的位元組保存在確切執行 ID 的快取金鑰下。決策、引流、清單寫入、證據驗證和最終驗證會為其當前嘗試使用該工件。收集器重試會恢復快取的計劃、驗證它、重新上傳其工件並採用相同的子項；缺少計劃狀態是編排失敗，而不是重建計劃或重新分派的許可。
• 重複使用的證據不會僅僅因為計劃密封找到了它就受到信任。發布決策在返回 passed 之前會重複檢查密封的目標 SHA、證據 SHA、策略、更改的路徑、選定的執行、根執行、來源清單、受信任的工具身份和確切子項檢查。
• 父項重試會獨立選擇最新的決策和引流工件；即使它們的來源嘗試不同，兩者也必須綁定相同的不可變計劃。
• 子項重試僅在子項執行 ID、工作流程路徑、ref、Q SHA、分派標題、事件、目標、候選和驗證輸入保持完全相同時，才屬於相同的不可變計劃。較新的子項嘗試會取代匹配的工作；較新嘗試中缺少的工作會保留。重複的工作身份、缺少的嘗試、回歸的嘗試或更改的元組會失敗關閉。當 GitHub 在最新的重試嘗試中暫時返回重複的工作時，frv status 和 continue 允許最多 60 秒的唯讀協調。執行元組和嘗試保持鎖定；持續的重複項和較舊嘗試的衝突仍然是錯誤。
• 使用 pnpm frv status|watch|rerun --job|rerun --child|continue --failed|verify 進行嘗試感知的恢復。控制器是無狀態的：不可變的執行計劃、確切的 GitHub 執行嘗試、診斷引流和最終清單是唯一的權威。它絕不寫入標籤、套件、註冊表條目、發布候選或發佈。
• 合併後控制器證明必須在受保護的 main 上使用經過審查的落地 SHA，並通過非發布的 FRV Proof Broker 和 FRV Proof Fixture。使用合併的拉取請求編號和確切的落地提交來分派代理。代理必須要求該拉取請求的合併提交與落地提交匹配，證明落地提交與其受信任的工作流程 SHA 相同或是其祖先，並在重新執行 fixture 之前立即重複進行權威、合併和祖先檢查。要求確切的固定無操作 fixture 執行從其有意的第一次嘗試失敗推進到第二次嘗試通過。代理必須發出其收據，而不創建發布候選、發布工件、發佈、儲存庫引用、替代父項或其他工作流程變異。這是託管的 GitHub 目標工作重新執行證明；重點控制器測試擁有不可變計劃資格、綠色嘗試保留、相同父項收集和嚴格驗證者調用。切勿將真實的完整發布驗證執行用於此證明。請參閱完整發布驗證。
• 使用一個發布操作者、一個 frv watch，並且至多一個調查員來處理當前失敗的表面。不要在單個工作流程轉換周圍構建審計-審查-計劃樹。
• 對於常規的測試版/穩定版發布，程式碼 SHA 可能已經包含最終說明並作為發布 SHA。一次成功的全新完整父項可以同時限定這兩個角色及其確切的發布位元組。如果之後說明發生更改，後續的發布 SHA 僅在從程式碼 SHA 的完整差異更改了選定的 CHANGELOG/YYYY.M.PATCH.md 以及可選的 CHANGELOG.md 和 CHANGELOG/records/YYYY.M.PATCH.md，且沒有其他路徑、重新命名或刪除時，才能重複使用產品證據；其更改的位元組仍然需要資格審查。
• 延伸穩定版驗證一個確切的分支頂點；它不重複使用常規的程式碼 SHA/發布 SHA 證據模型。
• 在稀疏工作樹或 Testbox 來源同步中，首先確認 package.json、pnpm-lock.yaml 以及選定檢查讀取的每個來源路徑。如果缺少任何一個，該結帳無法驗證發布依賴項或 Docker 通道：停止並使用儲存庫遠端更改閘道或完整任務工作樹。當輸入存在且發布修復更改了 package.json 或 pnpm-lock.yaml 時，僅使用 CI=true pnpm install --frozen-lockfile 重建任務擁有的可丟棄盒子，然後在 Docker 或聚焦測試之前執行明確的 require.resolve() 探針。CI 標誌允許 pnpm 重新創建預熱的模組目錄，而無需互動式確認。不要削弱鎖定檔案或將稀疏結帳失敗標記為產品/Docker 失敗。
• 如果在熱身之後候選版本被重新設定基底或其基礎 SHA 發生更改，請在測試之前停止任務擁有的盒子並熱身一個新的盒子。Testbox 來源同步相對於熱身的來源樹；繼續操作可能會將舊的基礎檔案與新的候選差異混合，並產生錯誤的鎖定檔案或 Docker 失敗。
• 重複使用的 Testbox 會在其首次成功執行後根據其記錄的來源進行檢查。僅來源編輯可以重複使用租約；基礎、依賴項、包裝器或 Testbox 工作流程偏移需要新的租約。請勿為發布證據設定 OPENCLAW_TESTBOX_ALLOW_STALE=1。
• 對於已提交的、具有支援的膠囊感知包裝器的發布候選版本，從該候選版本的結帳執行 node scripts/crabbox-wrapper.mjs run --blacksmith-ref main -- <command>。膠囊保留候選來源和凍結的依賴項，而 main 提供當前的准入限制。如果候選版本缺少該包裝器合約，請使用以下帶有單獨驗證和工具 SHA 的確切目標發布驗證路由。請勿分派候選 Testbox 工作流程參考或借用另一個結帳的包裝器。

延遲的 CI 恢復

發布驗證不會暫停 CI 或支援工作流程。舊的 OPENCLAW_RELEASE_PRIORITY_RUN 變數被當前工作流程准入忽略，並且 pnpm frv prioritize --run 已退役。使用 pnpm frv prioritize --restore <record> 恢復被較舊工作流程版本延遲的執行。