OpenClaw 版本維護者 是做什麼的？
用於版本發布操作，而非一般開發或顧問變更。
閱讀 docs/reference/RELEASING.md 以了解當前政策。在解決私有憑證定位器或主機拓撲之前，載入 $release-private（若可用）；憑證操作使用 $one-password。
選擇操作
僅閱讀所選階段所需的參考資料：
- 常規測試版/穩定版準備或發布：常規發布，其中包含準備和階段性驗證的路由。如果請求未指定穩定版/完整版，則預設為測試版；測試版授權不會授權後續的穩定版升級。
- 回溯發現：候選清單。對於擴展穩定版，另請閱讀回溯準備；SDK/配置變更需要明確的維護風險警告和維護者決定。
- 擴展穩定版
.33+Gateway 發布：擴展穩定版發布。使用帶有擴展穩定版輸入的共享發布器；其非最新 GitHub 版本包含憑證，但不會透過原生應用或 ClawHub 發布。 - 驗證選擇或失敗驗證：驗證與信心，搭配
$release-openclaw-ci用於工作流程執行和不可變清單。 - 中斷的發布或註冊表升級：發布恢復。
- 原生資產：平台發布，搭配
$release-openclaw-mac用於 macOS 操作。 - 穩定版發布後同步和確切 SHA 部署移交：主要結案。
- 版本說明：
$openclaw-changelog-update，包含其單獨批准的發布後文件鏡像路由。初始版本生成保留其現有格式；文件發布不會在發布期間自動執行。請求的公告：Discord 使用$release-openclaw-announcement，X 使用$release-tweets。公告永遠不會阻礙發布，且需要明確的發布授權。 - 已發布工件驗證：
$verify-release。GHSA 操作：$openclaw-ghsa-maintainer，僅在明確的安全工作流程授權下使用。
共享發布邊界
每個選定的驗證通道都必須成功：Windows 和 macOS Node 及其他正常 CI 作業、安裝冒煙測試、存活通道、update-first-hop-compat*、pack/npm 資格認證、套件完整性，以及 Linux/Windows/macOS Gateway 檢查，包括 Release Checks 中的 Windows 封裝安裝/升級檢查。已取消的執行仍會阻止進度。保留首次失敗記錄，並在恢復之前將每一個分類如下。穩定發布需要穩定/完整版的證據、浸泡測試和阻塞性能。測試版配置文件證據無法授權穩定發布。沒有任何通道或浸泡測試豁免可以繞過這些要求。所有九種 Gateway 安裝/升級組合（跨 Linux、Windows 和 macOS）都是全組資格認證所必需的。保留身份、來源、完整證據和現有的發布批准。
每個失敗的測試都需要明確的負責人決定，是真實發布阻礙還是偶發失敗，並在交接中記錄其證據：同一個 SHA 在其他地方或重新執行時通過、與發布差異無關、執行器或基礎設施特徵、相同案例過去有偶發失敗的歷史、或不是回歸的既有產品錯誤（例如 2026.9.6 的「指派給…」錯誤）。真正的阻礙是已發布位元組或行為的回歸，或更新/安裝/發布缺陷；在發布分支上修復它。對同一個發布 SHA 的偶發失敗預設最多重新執行兩次並記錄，並在 main 上提交一個平行修復的問題或 PR，附上證據。永遠不要因偶發失敗而重新切割、更改工具或開始新的 FRV。持續紅色的偶發失敗會阻止發布。僅限 main 的失敗和基礎設施失敗（執行器停機、GitHub 幽靈作業、託管執行器卸載）視為發布的偶發失敗。
依賴項公告永遠不會延遲發布。新發布的公告絕不是重新切割、更改工具或重新執行驗證的理由。將其記錄在發布證據和交接中，然後在發布後作為常規後續任務在 main 上提交或排隊依賴項更新。只有已知的惡意軟體發現會停止發布。發布依賴項證據和發布分派的 CI 強制執行此規定。
main 的 CI 健康狀況永遠不會阻礙發布。驗證和發布從發布分支加上固定工具執行，因此紅色的 main 不是等待、重新切割或暫停的理由。當發布需要在 main 上進行發布工具修復（工具 SHA 必須是受信任的 main 提交）時，修復未導致的 main 失敗不應阻止該修復的合併：在乾淨的 main 簽出上證明該失敗已存在，記錄在 PR 主體中，然後合併。在活躍發布期間，在這種確切情況下，允許管理員合併發布工具 PR。紅色的 main 仍會修復，由單獨的通道平行進行，永遠不會處於發布的關鍵路徑上。
操作目標大約是在一小時內花費 20 分鐘來完成驗證和發布，但這不是保證的測量值。僅原始碼的子任務與工件生產者同時啟動；候選消費者一旦候選準備就緒即可啟動。獨立驗證為綠色的子任務，即使其父任務失敗、被取消或仍處於活躍狀態，也可用於相同的確切目標和輸入；驗證其原始認可的資格身份（或歷史受信任的 main 工作流程 SHA）和當前嘗試。已驗證的清單提供 SDK 證據摘要和 npm 發布決策；它永遠不會承認 SDK API 變更，因此每當 SDK 報告包含變更時，請提供 plugin_sdk_api_acknowledgement。發布器無法接受已豁免的驗證證據。明確的發布器輸入選擇發布範圍；候選輔助工具在必要時仍會驗證其明確的 SDK 確認。
版本變更和不可逆的發布需要明確批准。請求切割、發布或完成一個指定版本會貫穿其經過驗證的發布和驗證；除非身份、通道、範圍或重大風險發生變化，否則不要再次詢問。普通程式碼的發佈權限並非發布權限。
操作員明確批准為準備指定版本而採取一切必要措施，即為必要的準備決策和修復提供常設權限。將其貫穿候選和工具修復、升級/遷移設計、經審查的測試或安全庫存調整、隔離驗證、提交、推送和驗證恢復。記錄決策、其證據和選定的支援合約；不要僅僅因為已批准的工作類別到達實現或驗證步驟就再次詢問。在解決阻礙的同時繼續獨立工作。此權限不允許隱藏缺陷、降低閘門以製造成功、對操作員狀態進行破壞性更改、不相關的工作或發布。僅準備請求在發布工件或橋接版本之前仍需要單獨的發布指令。
使用交接模板保持一個緊湊的狀態記錄：有效目標、版本/標籤/分支、切割/程式碼/發布 SHA、C/Q/P 身份、活躍的父執行和嘗試、成功的子任務工件、已批准的變更、階段和下一個操作。最新的操作員指示取代已取代的範圍。完整的證據保持完整，直到指定的變更使其無效。
對於常規版本，在可能的情況下，在凍結程式碼 SHA 之前準備完整的說明。如果這些說明是最終版本，則程式碼 SHA 和發布 SHA 是同一個提交：一次成功的全新完整資格認證可以提供兩個角色及其確切的發布位元組。不要僅僅為了區分標籤而創建另一個提交或執行。如果說明在資格認證後發生變更，其完整差異包含 CHANGELOG/<version>.md（確切的測試版版本或穩定基礎）且僅包含該條目、其匹配記錄和根索引的後代，可以使用 split-changelog-release-v1 在資格認證新發布位元組的同時重用產品證明。任何其他來源差異、重新命名或刪除都會返回到程式碼 SHA 循環。僅歷史根目錄收據保留 changelog-only-release-v1。新的資格認證凍結 Q=C：整個資格認證工作流程閉環屬於候選。保持獨立受信任的 P（准入、驗證器和發布器）分離。Q 工具修復需要新的 C/Q 和新綁定的證據；僅 P 或基礎設施的修復可以保留候選。缺失的資格認證合約需要刻意的回溯移植，絕不能使用未來主版本回退。
一旦候選被切割，其基礎是操作員的決定。永遠不要重新切割（將候選重新基於更新的 main），除非 Peter 在該版本中明確要求。在未經要求的情況下，僅將已合併的 main 提交揀選到發布分支上以修復已確認的發布阻礙：在凍結的候選上確定性失敗的必要通道，或更新/安裝/發布位元組缺陷。在交接記錄中命名每個揀選。不允許：機會主義的回溯移植、功能還原、或為了「獲取」一個可以透過小衝突解決方案乾淨揀選的修復而採用新的基礎。
在發布期間進行的發布流程改進會落地到兩個分支上。工作流程、發布腳本、發布測試、RELEASING.md 和發布技能變更首先合併到 main，然後揀選（-x）到 release/YYYY.M.PATCH 分支，用於下一個候選或補丁。此發布所需的資格認證修復必須在凍結新的 C/Q 之前落地；永遠不要為已資格認證的候選靜默切換工具。當 main 專屬的 CI 基礎設施在分支上缺失時，保留分支的表達形式，僅移植邏輯。發布分支上的產品程式碼保持僅阻礙者修復，依據上述規則。
只要為發布開啟的任何事項仍處於開啟狀態，發布就未完成。在最終報告之前，列出在發布期間創建的每個 PR（gh pr list --author @me --state open 加上任何綁定到工作階段的 PR），並落地或明確關閉每一個，附上原因；確認其修復在 main 上，並且當它是發布工具時，也在發布分支上。同時清理發布的臨時工作樹、已放棄的本地切割分支和過時的 scripts/pr 工作樹。
已發布的版本和最終標籤是不可變的。重用成功的確切來源工件；不要以隱式重試的方式重建或重新發布。活躍發布是工作佇列：沒有機會主義的 moving-main 修復或回溯移植。對失敗進行分類，修復其擁有者，重試受影響的表面，然後重新評估，而不是重複整個發布。
所需的發布證明和強制環境批准仍然需要。通過的兄弟任務無法取代缺失的必要證據。npm + ClawHub 是優先路徑。macOS、Windows、Linux 和 Android 原生發布並行執行，永遠不會阻礙 npm/ClawHub、GitHub 版本最終化或主要結案。選定的 Windows Node、Linux/Windows/macOS Gateway 和原生應用 CI 失敗會阻止發布驗證。平台發布器保留其自己的工件和更新程式合約；準確報告待定平台和證據差距。