mcpField
R
release-openclaw-ci

release-openclaw-ci

github.com/openclawテスト・品質393.3k233 回インストール今日更新
リポジトリ

release-openclaw-ci について

OpenClaw のリリース担当者向けスキルで、候補版の適格性確認、CI 証跡の収集、障害復旧を調整しますが、公開自体は行いません。固定されたリリース範囲、不変の実行計画、承認に基づく変更を重視します。

主な機能

  1. 01候補版と適格性確認範囲の固定
  2. 02CI 検証と証跡要件
  3. 03試行単位の実行復旧
  4. 04リリースのガードレールと承認境界

活用シーン

  1. 01beta または stable 候補版の適格性確認
  2. 02失敗した検証ジョブの復旧
  3. 03公開前のリリース証跡確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/openclaw/openclaw --skill release-openclaw-ci

インストール後、Claude Code で/release-openclaw-ciを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
release-ci-notes.md
scripts/
verify-provider-secrets.mjs

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

OpenClaw リリース CI

リリース候補に対して、完全な検証、インストール／更新の証明、ライブプロバイダーチェック、または CI の復旧が必要な場合は、これを $release-openclaw-maintainer および $openclaw-testing と併用してください。

ガードレール

  • オペレーターの明示的な承認なしに、バージョンの更新、タグ付け、npm への公開、GitHub リリースの作成、リリースの昇格を行わないでください。
  • 圧縮後、再開後、または新たな指示を受けた後は、最新の明示的なオペレーター指示に基づいて、有効な目標と現在のフェーズを書き直してください。以前のスコープをアクティブなリリースに再び持ち込まないでください。
  • リリースブランチまたは Code SHA が存在した時点で、リリースのスコープを固定してください。そのリリースを検証して出荷し、変動する main を第 2 の作業キューにしないでください。
  • C（候補）、Q（適格性評価）、P（承認／検証者／公開者）、再実行グループ、プロファイル、有効なソーク、コンテキスト／トランスポートの参照を記録してください。新規候補の適格性評価では、完全なワークフロー、再利用可能なワークフロー、ローカルアクション、スクリプト、プランナー、コントラクト、カバレッジの完了を含め、既定で Q=C とします。Code SHA と Release SHA はライフサイクル上の役割であり、追加のワークフロー識別子ではありません。
  • 候補ヘルパーは、リリースタグが存在しない場合、または候補の SHA と正確に一致する軽量タグか注釈付きタグが存在する場合に受け付けます。タグが競合するか、リモートの参照に失敗した場合は検証を停止してください。復旧のためにタグを移動してはいけません。
  • C/Q を固定し、信頼できる P を main または保護された公開タグから独立して選択してください。C/Q が P の祖先である必要はありません。候補に必要なコントラクトがない場合は、意図的にバックポートしてください。新しい main のツールに黙って置き換えてはいけません。
  • Code 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> は Q ではなく P を識別します。サフィックスはタグ作成時の来歴を記録するものであり、現在の親を示すものではありません。公開ヘルパーには引き続き --workflow-sha <P> 引数を指定します。一方、FRV ヘルパーの --workflow-sha は Q を選択し、候補ルートでは C と一致する必要があります。
  • main に手を加えるのは、オペレーターが要求した変更、またはリリースブランチから対処できない、このリリースを妨げる最小限の重大な main 所有のブロッカーがある場合に限ります。main の CI の健全性はリリースのゲートではありません。main が引き起こしていない失敗によってリリースツールの取り込みがブロックされる場合は、クリーンな main チェックアウトでその失敗がすでに存在することを証明し、PR 本文に記録してマージしてください。リリースが進行中の場合、その正確なケースでは管理者によるマージが許可されます。赤字の main を修正する別レーンは、リリースのクリティカルパス外で並行して進めてください。
  • ツールのみの修正は、プッシュ前に release-fast-lane ラベルを追加して main に取り込んでください（リリースツールのファストレーンを参照）。openclaw/ci-gate はその場合、lint、型、ガード、依存関係、ドキュメント、変更された Node の行のみを実行します。完了した ClawSweeper レビューを伴う、ネイティブな scripts/pr 経路で取り込んでください。このラベルでは指摘は助言扱いとなるため、リリース責任者が修正しないと判断した P1 があれば、取り込み前にフォローアップとともに PR に記録してください。
  • OPENCLAW_RELEASE_RUNNER_GROUP を任意で設定すると、検証の親ジョブとワーカー、および Release Publish の親ジョブと公開子ジョブを、ラベルを変更せずに予約済みの容量へ振り分けられます。認証情報を使用する公開ジョブと承認ジョブは、既定の GitHub ホストラベルのままにしてください。先に対象ランナーとリポジトリへのアクセスを設定してください。未設定の場合は通常のルーティングが維持されます。共有ワーカーは呼び出し元のグループを引き継ぎます。PR／main の CI と無関係なスケジュール実行は対象外です。
  • 新しい main 検証をディスパッチする前に、Code SHA に対するナイトリー親ジョブを確認してください。ナイトリー親ジョブは子ジョブごとのレシートを封印し、入力が一致する場合、対象を正確に指定したディスパッチがそれらを採用します。ナイトリーはこの明示的な信頼済み main ヘルパールート（--sha <main-sha> --workflow-sha <main-sha> --trusted-workflow-ref main）を実行するため、その親ジョブは main ではなく release-ci/<sha12>-<id> ブランチで実行されます。
  • 選択された検証レーンはすべて合格する必要があります。公開要件を参照してください。安定版タグには、安定版／フルの証拠、ソーク、ブロッキング対象のパフォーマンスが必要です。ベータ版プロファイルの証拠では安定版の適格性を満たせません。レーンやソークの免除によってこれらの要件を回避することはできません。全グループの適格性評価では、Linux／Windows／macOS の Gateway インストール／アップグレードの 9 通りすべてが必要です。最初の失敗、識別情報、完全な証拠を保持してください。
  • ネイティブの macOS、Windows、Linux、Android の公開は、npm／ClawHub、GitHub の最終処理、main のクローズアウトから独立しています。各プラットフォームは、それぞれの署名、適格性評価、アーティファクト、アップデーター要件を維持します。保留中のプラットフォームを正確に報告し、ネイティブのみの失敗は並行して修正してください。
  • 検証されていない 1Password 候補から GitHub シークレットを設定しないでください。候補が 401／403 を返した場合、既存のシークレットには手を加えず、不足しているプロバイダーを正確に報告してください。
  • シークレットの読み取り／書き込みには $one-password を使用してください。永続的な tmux セッションを 1 つだけ使い、対象のアイテムのみを扱い、シークレットを出力しないでください。
  • pnpm frv watch --run <parent> で 1 つの親実行を監視してください（監視を参照）。広範な gh run view のポーリングループは避けてください。REST クォータはすぐに消費されます。
  • ログを取得するのは、失敗したジョブまたは現在ブロックしているジョブに限ってください。クォータが少ない場合はポーリングを停止し、リセットを待ってください。
  • ライブプロバイダーの断続的な失敗は、コードの失敗とは分けて扱ってください。コードを編集する前に、キーの有効性、プロバイダーの HTTP ステータス、リトライの証拠、失敗したレーンを正確に確認してください。
  • ライブプロバイダーの障害を診断する際、モデル一覧のレスポンスが証明するのは認証であり、課金や推論の利用資格ではありません。有効な認証情報として扱う前に、実際の補完リクエストで認証情報を確認してください。まず認証情報を修正し、リリース認証情報の失敗を回避するためだけに別の認証経路を追加しないでください。
  • Full Release Validation では、子ジョブの正確なディスパッチ、Release Decision、Diagnostic Drain が分離されています。fail_fast=false の場合、子ジョブのキャンセル呼び出しは 0 回です。コレクター自体がキャンセルされるか GitHub API へのアクセスを失わない限り、Diagnostic Drain は選択されたすべての子ジョブが終了状態になるまで追跡します。fail_fast=true の場合、Release Decision がキャンセルできるのは、ブロッキング障害を所有する、まだアクティブな正確な子ジョブに限られます。
  • 同じ親ジョブで続行するには、元のルートが fail_fast=false でディスパッチされている必要があります。コントローラーは、再実行による変更を行う前に、その正確なログ記録済みの入力を検証します。
  • 独自の候補アーティファクトを封印した親ジョブは続行できません。GitHub の再実行により、以前の試行のアーティファクトが利用できなくなるためです。候補と適格性評価の SHA を固定したまま、その親ジョブを置き換えて、新しい全グループの Full Release Validation を開始してください。
  • ディスパッチ後、1 つの不変な実行計画アーティファクトに、元の親ジョブの試行、正確な子ジョブのタプルとタイトル、選択されたカバレッジ、ゲート、再利用時の識別情報が記録されます。同じバイト列が、実行 ID を正確に指定したキャッシュキーにも保存されます。Decision、Drain、マニフェストの作成、証拠の検証、最終検証では、現在の試行に対応するアーティファクトを使用します。コレクターのリトライでは、キャッシュされた計画を復元して検証し、そのアーティファクトを再アップロードして同じ子ジョブを採用します。計画の状態が欠けている場合はオーケストレーションの失敗であり、計画の再構築や再ディスパッチを許可するものではありません。
  • 計画の封印時に見つかったという理由だけで、再利用された証拠を信頼してはいけません。Release Decision は passed を返す前に、封印済みの対象 SHA、証拠 SHA、ポリシー、変更パス、選択された実行、ルート実行、ソースマニフェスト、信頼済みツールの識別情報、正確な子ジョブのチェックを再実行します。
  • 親ジョブの再試行では、Decision と Drain のアーティファクトを個別に最新のものから選択します。両者の元の試行が異なる場合でも、どちらも同じ不変な計画に紐付いている必要があります。
  • 子ジョブのリトライが同じ不変な計画に含まれるのは、子ジョブの実行 ID、ワークフローのパス、参照、Q SHA、ディスパッチタイトル、イベント、対象、候補、検証入力が正確に一致する場合に限られます。新しい子ジョブの試行では一致するジョブを置き換え、より新しい試行にないジョブは引き継ぎます。ジョブの識別情報が重複している場合、試行が欠けている場合、試行番号が後退している場合、またはタプルが変更されている場合は、安全側に失敗させてください。GitHub が最新のリトライ試行で一時的にジョブを重複して返す場合、frv status と continue は読み取り専用の整合性確認を最大 60 秒間行います。実行タプルと試行は固定されたままです。重複が続く場合や古い試行との競合は、引き続きエラーになります。
  • 試行を考慮した復旧には pnpm frv status|watch|rerun --job|rerun --child|continue --failed|verify を使用してください。コントローラーはステートレスです。不変な実行計画、正確な GitHub 実行試行、Diagnostic Drain、最終マニフェストのみが正当な情報源です。タグ、パッケージ、レジストリエントリー、リリース候補、公開物を作成することはありません。
  • マージ後のコントローラーの証明には、非リリースの FRV Proof Broker と FRV Proof Fixture を介して、保護された main 上のレビュー済み取り込み済み SHA を使用してください。マージ済みプルリクエスト番号と正確な取り込み済みコミットを指定してブローカーをディスパッチします。ブローカーは、そのプルリクエストのマージコミットが取り込み済みコミットと一致すること、取り込み済みコミットが信頼済みワークフロー SHA と同一であるかその祖先であることを証明し、フィクスチャを再実行する直前に権限、マージ、祖先のチェックを再度行う必要があります。 固定された正確な no-op フィクスチャ実行が、意図的な試行 1 の失敗から試行 2 の合格へ進むことを確認してください。ブローカーは、リリース候補、リリースアーティファクト、公開物、リポジトリ参照、置き換え用の親ジョブ、その他のワークフロー変更を作成せずにレシートを出力する必要があります。これは GitHub 上で対象ジョブの再実行を検証するものです。不変な計画の適格性、合格済み試行の保持、同じ親ジョブでの収集、厳密な検証者の呼び出しは、対象を絞ったコントローラーテストで検証してください。この証明に実際の Full Release Validation 実行を使用してはいけません。Full Release Validationを参照してください。
  • リリースオペレーターは 1 人、frv watch は 1 つ、現在失敗している箇所を調査する担当者は最大 1 人としてください。単一のワークフロー遷移を巡って、監査レビュー計画のツリーを構築しないでください。
  • 通常のベータ版／安定版リリースでは、Code SHA に最終リリースノートがすでに含まれていて、それを Release SHA とする場合があります。成功した新しいフル親ジョブ 1 回で、両方の役割とその正確な公開バイトを適格と判定できます。その後でノートが変更された場合、Release SHA と Code SHA の完全な差分が、選択された CHANGELOG/YYYY.M.PATCH.md と任意の CHANGELOG.md および CHANGELOG/records/YYYY.M.PATCH.md の変更のみで、他のパス、名前変更、削除を含まない場合に限り、後の Release SHA で製品の証拠を再利用できます。変更されたバイトには、それでも適格性評価が必要です。
  • Extended-stable では、正確に指定したブランチの先端を検証します。通常の Code SHA／Release SHA の証拠モデルは再利用しません。
  • スパースなワークツリーまたは Testbox のソース同期では、まず package.json、pnpm-lock.yaml、選択されたチェックが読み取るすべてのソースパスが存在することを確認してください。いずれかが欠けている場合、そのチェックアウトではリリースの依存関係レーンや Docker レーンを検証できません。停止して、リポジトリのリモート変更ゲートまたは完全なタスクワークツリーを使用してください。入力が揃っていて、リリース修正によって package.json または pnpm-lock.yaml が変更される場合は、タスク専用の破棄可能なボックスのみで CI=true pnpm install --frozen-lockfile を実行し、Docker や対象を絞ったテストの前に明示的な require.resolve() プローブを実行してください。CI フラグを指定すると、事前にウォームアップされた modules ディレクトリを、対話的な確認なしに pnpm が再作成できます。ロックファイルを緩和したり、スパースチェックアウトの失敗を製品／Docker の失敗として扱ったりしないでください。
  • ウォームアップ後に候補がリベースされた場合、またはそのベース SHA が変わった場合は、タスク専用のボックスを停止し、テストの前に新しいボックスをウォームアップしてください。Testbox のソース同期は、ウォームアップ済みのソースツリーを基準に行われます。続行すると、古いベースファイルと新しい候補の差分が混在し、誤ったロックファイルや Docker の失敗につながる可能性があります。
  • 再利用された Testbox は、最初の正常終了後に、記録済みのソースと照合して確認します。ソースのみの編集であればリースを再利用できます。ベース、依存関係、ラッパー、Testbox ワークフローの変更がある場合は、新しいリースが必要です。リリースの証拠に OPENCLAW_TESTBOX_ALLOW_STALE=1 を設定しないでください。
  • サポート対象のカプセル対応ラッパーを備えたコミット済みリリース候補では、Testbox の使用時に、その候補のチェックアウトから node scripts/crabbox-wrapper.mjs run --blacksmith-ref main -- <command> を実行してください。カプセルは候補のソースと固定された依存関係を保持しつつ、main が現在の承認制限を提供します。候補にそのラッパーのコントラクトがない場合は、以下の正確な対象指定のリリース検証ルートを使用し、Validation SHA と Tooling SHA を分けてください。候補の Testbox ワークフロー参照をディスパッチしたり、別のチェックアウトのラッパーを借用したりしないでください。

CI の遅延実行の復旧

リリース検証によって、CI やサポートワークフローが一時停止することはありません。以前の OPENCLAW_RELEASE_PRIORITY_RUN 変数は現在のワークフローの実行判定では無視され、 pnpm frv prioritize --run は廃止されています。以前のワークフローリビジョンによって 遅延された実行を復旧し、その変数をクリアするには、pnpm frv prioritize --restore <record> を使用してください。 必須の公開証明と安定稼働ゲートはそのまま維持してください。

継続的なリリース準備状況

スケジュールされた main の検証（3 時間ごとの UTC :07）では、正確な main SHA に対する直下のマニフェストと子ごとのレシートを確定します。 同日中にリリースする場合は、次のスケジュール実行の前にリリーストレイン（バージョンと変更履歴）を main にマージし、 その実行の SHA から release/YYYY.M.PATCH を作成して、Code SHA が検証済み SHA と一致するようにします。 子ごとの採用では、正確なターゲット SHA、ロール、ディスパッチ入力（dispatch_id を除く）が一致する必要があります。 入力にコンテキストを必要とせず一致するため、productPerformance は採用されます。 --target-ref release/YYYY.M.PATCH を指定して安定版候補をディスパッチすると、 coveragePolicy=npm-stable-v1 と ci_release_scope=npm-stable が解決されます。一方、main ではスコープが full になります。 normalCi、プラグインのプレリリース、リリースチェックは、入力に target_context_ref が追加されるため再ディスパッチされます。プラグインのプレリリースとリリースチェックでは allow_frozen_target_scenario_omissions=true も追加され、スコープも異なります。 親全体を採用するには、validationPurpose、 publicationSelectionJson、targetContextRef、targetVersion、allowUnreleasedChangelog、coveragePolicy を含むマニフェストの validationInputs がバイト単位で完全に一致する必要があります。 main-qualification の夜間実行が、publish 目的の安定版候補に丸ごと採用されることはありません。 目的／コンテキストをまたぐ採用については、検証ツールのポリシーで今後対応します。

リリースツールの高速レーン

高速レーンを適用するプッシュの前に、プルリクエストに release-fast-lane ラベルを追加してください。PR CI はトリガーイベントのラベルを読み取り、ラベルイベントでは CI は開始されません。すでにプッシュ済みのブランチでは、gh pr ready --undo を実行してから gh pr ready を実行すると、現在のラベルで PR CI が再トリガーされます。このラベルにより openclaw/ci-gate の対象が絞られるのは、変更パスがすべてリリースツールに該当する正規のプルリクエストのみです。対象パスは .github/workflows/**、scripts/**、test/scripts/**、 .agents/skills/release-*/**、docs/reference/RELEASING.md、または個別にチェックされるドキュメントです。実行対象となった場合も、security-fast、check-shard（lint、prod/test の型、ガード、依存関係、npm ロック）、ドキュメントに変更があった場合の check-docs、および変更された Node の各行は引き続き実行されます。プランナーの編集に対する、コンパクトなパッキングポリシーの全プラン証明は、これらの行に緩和されます。コントラクト、ベースラインのラチェット、バンドルされたプロトコル、Bun ランチャー、追加チェック、ビルド成果物（変更された行で dist が必要な場合を除く）、Control UI、Windows、macOS、iOS、Android、i18n、スキルの各レーンはスキップされ、プリフライトのステップサマリーに「Release fast lane」として記載されます。ラベルが適用されない場合（対象外のパス、グローバル Node 入力、フォーク、プッシュ、ディスパッチ、ドキュメントのみ）には警告が記録され、通常の選択は変更されません。ゲート全体の要件は維持され、選択されたレーンはすべて成功する必要があり、マージ後の結果は毎時実行される main の全 CI で検証されます。このラベルで絞られるのは CI ゲートのみです。フォークのブランチは対象外となり、完了済みの ClawSweeper レビューを含むネイティブな scripts/pr のマージ手順に変更はありません。ラベル付き PR では ClawSweeper の指摘は助言として扱われます。リリース担当者が PR 内で修正しないと判断した P1 は、マージ前にフォローアップとともにその PR に記録します。

実行 ID と再試行予算

Full Release Validation の監視や復旧を行う前に、C、Q/ref、P/ref、ターゲットコンテキスト ref、親の実行 ID、 試行回数、フェーズを記録してください。 台帳では Code SHA と Release SHA をライフサイクル上のロールとして記録してください。同じコミットを指す場合もあります。イミュータブルな Release Publish の親レシートは、タグに記録されたソースとは別に記録してください。 この基盤で適用されるコアおよびプラグインの npm 変更については、各公開または dist-tag の変更を行う直前に、保護対象の軽量タグを正確に再読み込みし、親の実行タプルが正確に一致することを再検証してください。 タグがない場合、移動されている場合、注釈付きの場合、または SHA が誤っている場合は拒否してください。また、リポジトリ、ワークフロー、実行 ID、試行回数、ツールの識別情報、親状態の不一致、および同名のブランチも拒否してください。 いずれの識別情報も現在の main から更新しないでください。依存する適用変更が反映されるまでは、ほかの特権を持つ書き込みをブロック対象として扱ってください。

  • 概念上のフェーズは、現在の入力に次のように対応します：

    • beta-publish: release_profile=beta、run_release_soak=false
    • postpublish-confidence: 公開済みパッケージの入力で、 run_release_soak=true または明示的なフォーカスグループ
    • stable-publish: release_profile=stable または full、ソークおよびブロッキングパフォーマンス付き

  • 実際のベータパッケージに対して、対応する正規の リリースブランチまたはベータタグ上でソークなしの all 実行を行うと、coveragePolicy=npm-beta-v1 が記録されます。これは Linux/macOS/Windows の Node、Control UI、プラグイン、パッケージ、インストール/更新、 Linux/Windows/macOS のクロス OS、QA パリティ、ランタイムペア/再起動、およびツールのカバレッジを維持します。 選択されたすべてのテストが npm/ClawHub をゲートします。ネイティブアプリ CI、パフォーマンス、および公開済みパッケージの Telegram は confidence に延期されます。 ソークなしのベータ all は、main のベータプロファイルチェックを含む Package Acceptance Telegram も延期します。延期されたチェックは未実行として記録し、 決して合格として記録しないでください。Stable/full、ソーク、およびフォーカスグループはそれぞれのカバレッジを維持し、 選択された子は引き続き終端のエビデンスを必要とします。カバレッジポリシーが存在しない場合は、 従来の full の動作を維持します。

  • 同じ C + Q + rerun グループ + リリースプロファイル + 実効ソークカバレッジに対して、アクティブな親は最大 1 つに保ちます。Stable/full は常にソークを 含みます。異なるカバレッジプロファイルは独立して実行できます。同時実行によって、 古い完全一致の子が自動的にキャンセルされることはありません。

  • 親のキャンセルまたはタイムアウトは、採用された ID チェック済みの子を 実行したままにします。不要になった完全一致の子は、オペレーターが明示的に キャンセルする必要があります。ブランチ、タイトルのプレフィックス、または 最新実行の順序から子の ID を推測しないでください。

  • 失敗した 1 つのサーフェスは、1 回の診断、必要時の 1 回の修正、および 1 回の 限定的な再試行で復旧します。その後、リリース判断を再評価します。 rerun_group=all を自動的にディスパッチしないでください。

  • 失敗またはタイムアウトしたテストジョブは、リードが 実際のブロッカーかフレークかの判断を記録した後にのみ再実行します（メンテナー skill の共有リリース 境界を参照）。フレークは、同じリリース SHA 上で最大 2 回の記録された再実行に加え、 main 上の並行修正の issue または PR までです。再カット、ツール変更、 または新しい FRV は決して行いません。新しいディスパッチは known_flaky_jobs_json を拒否します。

  • サポートされている親に対して、pnpm frv rerun --run <parent-run-id> --job "<child-key>:<exact job name>" は、承認された Actions ジョブ ID を使用して、実行済みの終端ジョブを 1 つ再実行します。子キーと正確な名前は frv status --json から取得します。 GitHub は依存ジョブも再実行します。コントローラーはリクエストを送信する前にその子のみを待機し、 無関係な失敗を再試行しません。

  • pnpm frv rerun --run <parent-run-id> --child <child-key|run-id> [--max-attempts N] は、それらの限定された再実行の 1 つを記録します。子の 完了を待ち、rerun-failed-jobs リクエストを正確に 1 回送信し、 重複ジョブなしで新しい試行が存在すると戻ります。リクエストの前に、 失敗した各ジョブのランナーラベルと現在の OPENCLAW_CI_RUNNER_BACKEND を出力します。 その後、$TMPDIR/openclaw-frv/<repo>-<parent>-reruns.jsonl に監査行を 追記します。合格した子、アーティファクトプロデューサー（continue --failed を使用）、 および試行予算を超えた子を拒否します。デフォルトの 2 では 1 回の再実行が可能です。 確認されたフレークに対してのみ --max-attempts 3 を渡してください。失敗したコンシューマーが グリーンなプロデューサーの実行試行を束縛する場合（install-smoke 候補ペイロード、#161317）、 代わりにそのプロデューサージョブとその依存ジョブを再実行します。continue --failed で再シールします。

  • pnpm frv continue --failed --run <parent-run-id> は、親または兄弟が アクティブなままであっても、各失敗した子を終端になり次第再実行します。 アクティブな試行を採用し、グリーンな子を保持します。すべての必須の 子がグリーンになり、元の親が完了すると、同じ不変プランを復元し、 更新された all グループマニフェストをシールするために、親を 1 回再実行します。 早期の再試行は元の Decision/Drain のペアリングを無効にする可能性があります。最終的な 再シールと厳密な検証が完了を担います。

  • 各子または親の再実行の変更は、呼び出しごとに正確に 1 回送信されます。 あいまいな転送失敗は、限定された読み取り専用の調整をトリガーします。中断または タイムアウトしたコマンドを盲目的に繰り返さないでください。まず正確な 試行を検査してください。対象を絞った JSON 結果は、ジョブ ID、承認されたソース 試行、および観測された再試行を記録します。デフォルトの 12 時間の動作予算の間、 コマンドを長時間実行シェルに保持してください。

  • 変更せずに検査する：

    pnpm frv status --run <parent-run-id>
pnpm frv verify --run <successful-parent-run-id>

  • 試行を考慮した証拠が導入される前の不変プランを持つ親は、継続できません。全グループを対象とした新しい Full Release Validation を開始してください。古い状態を再構築したり、代替の親をディスパッチしたりしないでください。

  • コントローラーの再試行対象は ci、plugin-prerelease、install-smoke、cross-os、live-e2e、package、qa-parity、qa-live、npm-telegram、または performance です。削除された release-checks ハンドルは使わないでください。qa は直接の子を手動で集約する場合に限り使用でき、コントローラーの再試行 API ではありません。

  • フィルターが選択したグループに属さない場合、フィルター付きの再試行は安全側に倒して失敗します。全グループの実行では cross_os_suite_filter も指定できます。たとえば、-f cross_os_suite_filter=ubuntu,macos は Windows を除外します。明示的にフィルター指定した OS レーンが省略されても、Linux スイートがすべて選択され、その他のポリシー要件も満たされていれば、npm-stable-v1 と npm-beta-v1 は引き続き対象となります。 算出されたフィルターが空の場合、フィルターなしの広範な実行に切り替えないでください。

  • 新しい全グループの親を実行する根拠となるのは、共有オーケストレーションに変更があった場合、選択した組み合わせに対して以前の証拠が無効である場合、またはオペレーターが明示的に要求した場合のみです。無効化した出来事を記録してください。

  • 限定的な子またはグループの証拠だけでは、公開の承認にはなりません。リリースオーナーが現在の公開ゲートに照らして判断できるよう、証拠台帳に記録してください。

事前確認

全マトリックスのディスパッチ前に、承認された隔離環境で、凍結された信頼済みターゲットに対して pnpm ui:i18n:check と pnpm native:i18n:check の両方を実行してください。両方の結果をその正確な SHA に紐付けてください。生成済みロケールの差異は警告として報告し、ディスパッチを続行してください。ソースの変更や直列化されたロケール更新ワークフローにより、生成済み出力が一時的に古いままになることがあります。検証を開始する前に再生成を必須にしないでください。FRV の通常の CI 子は、厳格な control-ui-i18n ジョブと native-i18n ジョブを維持し、実際の結果を実行サマリーに報告します。選択されたロケールジョブが失敗した場合、npm／ClawHub への公開はブロックされます。PR 側のチェックとリリース準備ゲートに変更はありません。ターゲットの実行は信頼済みディスパッチヘルパーの外で行ってください。任意のターゲットのチェックアウトをヘルパーのコードとして実行しないでください。

コストの高い全検証の前に、同じ凍結済みの信頼済みターゲットとその凍結済み依存関係を使い、承認された隔離環境で、信頼済みディスパッチヘルパーの外において pnpm ui:build も実行してください。成功した本番ビルド、事前圧縮アセットの検証、起動時および最大アセットの予算結果を、ターゲット SHA とともに記録してください。いずれかが失敗した場合、ファンアウトはブロックされます。ターゲットを許容するために開発サーバーで代用したり、予算を引き上げたりしないでください。

ローカルで全 E2E の証明を行う場合は、初回ビルドに非公開の QA エントリーを含めて、凍結済みで依存関係の準備が整った証明用チェックアウトを用意してください。

OPENCLAW_BUILD_PRIVATE_QA=1 pnpm build

その後、通常の準備完了チェックを有効にしたまま、選択した E2E コマンドを実行してください。scripts/lib/vitest-build-prerequisites.mts は非公開の QA エントリーを要求し、存在しない場合は scripts/run-node.mts が別の全ビルドを実行します。この事前確認により、missing_private_qa_dist だけを理由とした再ビルドを回避できます。このフラグは、このタスク専用の証明用チェックアウトとコマンドに限定してください。公開用のパッケージとイメージのバイト列は、引き続きリリースワークフローとその封印済みアーティファクトが管理します。

全リリース検証の前に：

gh api rate_limit --jq '.resources.core'
git status --short --branch
git rev-parse HEAD
公開前

通常のベータ版／安定版の保護された公開を行う場合は、エビデンスの検証後に、使用するタグ、正確な Full Release Validation の実行と試行、npm dist-tag、プラグインのスコープ、保護された公開ツールの参照先を指定して pnpm release:publish-preflight を実行してください。pnpm release:candidate はダウンロード済みのマニフェストを使ってこのチェックを実行します。再ダウンロードしたり、選択済みの試行を置き換えたりしないでください。選択した公開ルートのレポートに記載された正確なディスパッチコマンドは、すべての FAIL と担当者の対応が必要な WARN を解決してからに限り使用してください。Extended-stable は別の担当者ワークフローを維持しており、このプレフライトでは承認されません。Alpha リリースは廃止されています。

失敗した公開を再試行する前にレポートを確認してください。すでに公開されたコアのバイト列について検証済みの openclaw_npm_resume_run_id を保持し、一致するドラフト／公開済みリリースの状態を調べ、キャンセル前に残存するプラグイン／ClawHub の子ジョブを特定してください。プレフライトは読み取り専用であり、公開を許可せず、子ジョブをキャンセルせず、ローカルの認証情報からリポジトリのシークレットが存在することを証明するものでもありません。ブートストラップ候補では、リポジトリで実際に使用する NPM_TOKEN による読み取り専用の npm whoami プローブが必要です。 bootstrap token probe のシークレットを分離する手順に従い、その実行 URL を保持してください。診断チェックの一環として認証情報をローテーションしないでください。

ディスパッチ

ソースの承認、プラグイン互換性の準備完了確認、エビデンス再利用の選択後、ソースのみの子ジョブを npm および Docker アーティファクト生成ジョブと並行してディスパッチします。候補の取得では、適格性確認が続く間に生の npm バイト列を消費します。候補の検証後、独立した検証や Docker を待たずに、候補の Plugin Prerelease と Release Checks を直ちに開始します。不変の実行計画と最終アーティファクトの適格性確認を保持してください。

選択された各検証子ジョブは、信頼されたワークフローツールから不変の full-release-child-evidence-<target-sha>-<role>-<run-id>-<attempt> レシートをアップロードします。このレシートは、候補記述子を含む正規化済みのディスパッチ入力を保持し、試行をまたいで先行ジョブを構成します。その workloadConclusion には実行中の公開ジョブが含まれません。収集に失敗しても再利用メタデータが失われるだけで、ワークロードの適格性は変わりません。reuse_evidence=true の場合、ディスパッチは直近の実行を最大 100 件スキャンし、対象レシートの一覧を最大 40 件調べ、ロールごとに一致するレシートを最大 5 件、2 分以内に完全検証します。対象やツールが異なる実行は、完全検証の予算を消費しません。GitHub は github.event.inputs から空文字列の入力を省略するため、空文字列の入力は入力なしと同等です。空でない既定値と候補記述子のバイト列は完全に一致する必要があります。失敗、キャンセル、または進行中の親からグリーンの子ジョブを採用できるのは、現在の親と同じ Tooling SHA であり、かつ main の系譜を維持している場合に限ります。親のツール情報がない場合や異なる場合はフェイルクローズとなり、例外となるパスはありません。ディスパッチログには再利用された子ジョブ、評価された各不採用理由、スキップされた実行と新規ディスパッチの概要が記録されます。現在の親による採用を示す証拠と不変の実行計画が、各選択を拘束します。収集処理と最終検証では、子ジョブの最新の試行と結論、同一のツール、main の系譜、入力、アーティファクトの ID／ダイジェスト／有効期限、信頼されたシールおよびアップロード手順の成功を再確認します。新しい試行があると再利用は無効になります。収集処理を修復するために、採用済みの子ジョブを再実行しないでください。現在の親によるソース／公開の承認と、成功した親からの変更履歴を再利用する別の経路に変更はありません。アーティファクト生成ジョブは、既存のシール済みレシートを維持します。候補の承認によって子ジョブ単位のこのレシート再利用契約が拡張されることはありません。Q が異なる場合は新規の子ジョブが実行されます。親全体の認証済みエビデンス再利用には、引き続き元の Q に関する別個の契約が適用されます。

早期に単独で実施する製品パフォーマンス実行は、ベータ版の信頼性を高めるための任意の手順です。有用であれば、リリース作業と並行して、固定された Code SHA を対象に開始してください。

# Optional beta confidence; stable/full qualification requires blocking performance.
fail_on_regression=false
gh workflow run openclaw-performance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f target_ref=<code-sha> \
  -f profile=release \
  -f repeat=3 \
  -f deep_profile=false \
  -f live_openai_candidate=false \
  -f fail_on_regression="$fail_on_regression"
  • このオプションのベータシグナルに対して、別途必須の prepublish 待機を追加しないでください。
  • 公開/クローズアウトの前に、利用可能な Kova、ゲートウェイ起動、CLI 起動のメトリクスを以前のリリース証跡または clawgrit レポートと比較してください。
  • リグレッションはリリース証跡に記録し、その製品への影響を調査してください。安定版/完全な認定にはブロッキングパフォーマンスが必要です。選択されたすべてのパフォーマンス子項目は成功しなければならず、失敗を免除することはできません。
  • npm-beta-v1 はパフォーマンス子項目を延期します。選択されたすべての子項目には依然として最終的な証跡が必要であり、アーティファクトのみの公開を証明しなければなりません。

レビュー済み候補の認定には、正規のヘルパーを使用してください。これだけが、まず P で openclaw-release-prepare.yml に対して軽量な admit-qualification 操作を実行し、次に Q=C で FRV をディスパッチします。P はオペレーターのアテステーション、完全な正規化入力、およびデータのみの凍結された Q カバレッジを記録します。不変ディスクリプタは既存の trusted_workflow_json エンベロープ内を移動します。P の admission ステップで候補コードを実行したり、エンベロープを手動で組み立てたりしないでください。

PUBLISHER_SHA="<recorded-full-trusted-main-ancestor-sha>"
PUBLICATION_SELECTION='{"route":"normal","npmDistTag":"latest","publishOpenclawNpm":true,"pluginPublishScope":"all-publishable","plugins":[]}'
pnpm ci:full-release \
  --sha <code-sha> \
  --target-ref release/YYYY.M.PATCH \
  --trusted-workflow-ref candidate \
  --admission-workflow-sha "$PUBLISHER_SHA" \
  --admission-workflow-ref main \
  --request-file <private-request-file> \
  -f validation_purpose=publish \
  -f publication_selection_json="$PUBLICATION_SELECTION"

Q はデフォルトで C になります。明示的な --workflow-sha は C と等しくなければなりません。P は代わりに、既存の保護された release-publish/* タグをその正確な SHA とともに使用できます。ディスパッチの前に候補とカバレッジをレビューしてください。admission が記録するのはそのオペレーターのアテステーションであり、ボットの例外ではありません。スケジュールされた main 認定は明示的に --trusted-workflow-ref main を使用し、その trusted-main セマンティクスを維持します。

既存の --request-file は、そのルート、Q/P の識別情報、または入力を変更せずに、元のリクエストを整合します。--reconcile-request <file> は読み取り専用です。admission の後、かつ Q ref の変更や FRV POST の前に候補リクエストを継続できるのは、--resume-request <file> だけです。安定版/チェックリストの拒否は、Q ref が依然として意図されている v2 準備済みリクエストに対して、その正確な次のコマンドを出力します。それを明示的に実行し、その後ラッパーを再実行してください。整合だけでは、admission 済みリクエストが認定へ進むことはありません。不確実な書き込みは決して再試行しません。証跡を再利用する際は、元のプロデューサーと現在のコンシューマーの識別情報を維持してください。

ベータ公開には npmDistTag=beta を選択し、route=prepared は意図された prepared-button コンシューマーに対してのみ選択してください。source-admission の結果はレジストリの状態を認定したり、公開を承認したりするものではありません。非公開の調査では、公開の選択を伴わずに明示的な validation_purpose=diagnostic を使用してください。定期的な main 認定では main-qualification を使用し、正確な公開済みパッケージの信頼性には postpublish-confidence を使用します。カバレッジ/プロファイルの選択は独立したままにしてください。

通常の release/* 検証では、target_context_ref なしでワークフローを生でディスパッチしないでください（ヘルパーの --target-ref がそれを記録します）。正規の release/* および extended-stable/* ワークフロー ref は引き続きサポートされるルートですが、その Telegram 子項目は OIDC とアテステーションを通じて正確な親ワークフロー ref と SHA を維持しなければなりません。trusted-workflow のリリースブランチ CI は target_ref + release_candidate_ref を渡します。そこでは release_gate を決して使用しないでください — それには workflow head == target が必要です。（以下の PR-head ci.yml フォールバックは別のディスパッチであり、release_gate=true を使用します。） Code SHA の固定後に、リリースブランチが進む場合があります。ヘルパーは、固定された SHA が正規のリリースブランチの祖先であり、そのパッケージバージョンがブランチの最終バージョン、またはそれに一致するベータ版プレリリースである間に限り、その SHA を受け付けます。Extended-stable ブランチとすべてのタグでは、パッケージバージョンが完全に一致する必要があります。 新しい候補の適格性確認では、Q=C を維持し、P は別途渡してください。固定されたコントラクトがない場合はフェイルクローズとし、main へのフォールバックではなく、意図的な候補へのバックポートが必要です。明示的な履歴／リビジョン横断ルートは、引き続き --trusted-workflow-ref main --workflow-sha <recorded-main-tooling-sha> （または保護されたツール用タグ）です。このルートでの新しいリクエストは、診断、main の適格性確認、または公開後の信頼度確認に限られ、公開適格性確認には使用できません。既存の履歴公開リクエストは、この新しいディスパッチ制限より前に再開され、元の trusted-main 祖先コントラクトを維持します。これらは候補が所有するエビデンスではありません。どちらのルートでも、移動する main から記録済みの識別情報を更新しないでください。オペレーターが意図的に -f reuse_evidence=false を選択しない限り、エビデンスの再利用は有効のままです。

新しい完全な適格性確認の前に最終ノートがすでにコミットされていた場合は、その Code SHA を Release SHA として維持し、同じ成功済みの親／試行と、その正確な準備済みバイト列を候補および公開チェックに使用してください。必須ゲートと、最終的なチャネル固有の SDK レビューは引き続き適用されます。パブリッシャーは封印済みの確認応答を使用し、候補ヘルパーは必要に応じて明示的な引数を保持します。

適格性確認後にノートが変更された場合に限り、選択したリリースエントリーと、一致するレコード／インデックスの更新をコミットしてから、必要に応じて再利用を指定して、新しい Release SHA に対してヘルパーを実行します。その親は policy=split-changelog-release-v1、evidenceSha=<code-sha>、および完全な changedPaths を報告する必要があります。選択した CHANGELOG/YYYY.M.PATCH.md は必須で、併せて許可されるのは CHANGELOG.md と CHANGELOG/records/YYYY.M.PATCH.md のみです。エントリー／レコードの追加または変更は許可されますが、インデックスの変更は修正に限られます。名前変更、削除、他のリリース、ドキュメントのソース編集には、新しい製品適格性確認が必要です。履歴のルートのみのレシートでは、changelog-only-release-v1 が引き続き使用されます。split パスでは、子レーンをディスパッチする代わりに製品マトリックスを再利用してください。Npm の事前チェックとパッケージ／インストールの受け入れ確認は、正確な Release SHA と、その新しい tarball のバイト列に対して引き続き実行されます。

現在の全グループ FRV では、コアおよび選択されたプラグインの Npm ソース／ビルド／適格性確認と、Docker の準備も読み取り専用で実施します。その成功した実行を preflight_run_id として使用してください。候補ヘルパーはその実行をデフォルトで使用します。履歴の別個のエビデンスを復旧する場合を除き、Npm の事前チェックを二重にディスパッチしないでください。通常の最終適格性確認では、beta と latest の両方について SDK レポートを記録します。実際の公開チャネルに対する確認応答をレビューしてください。準備済みディスクリプターは、正確な最終マニフェスト内の publicationArtifacts に格納されます。Release Prepare はマニフェストのプラグイン Npm ディスクリプターを採用し、ClawHub のみを準備します。FRV 後にプラグイン Npm を再パッケージ化することはありません。製品エビデンスの再利用によって、Code SHA のパッケージまたはイメージのバイト列を最終 Release SHA のものとして代用することはできません。独立した Npm 適格性確認に失敗した場合は、pnpm frv continue --failed を使用してください。 失敗した Npm ジョブは元の実行で再試行され、成功した準備ジョブと診断用の子ジョブは引き継がれ、親が結果のレシートを検証します。失敗したというだけで継続が拒否されることはありません。固定済みワークフローは元のレシートロジックを実行します。ローカルコントローラーをアップグレードしても、そのロジックが後付けされることはありません。また、復旧結果の最終検証は引き続き親が担います。 SHA で固定されたヘルパーは、一致するベータリリース候補に対して beta を、安定版/修正版に対して stable を推論し、その後 C/Q/P 実行アイデンティティを渡します。ソークなしの正規ベータ all は npm-beta-v1 を使用します。main および非ベータのターゲットは、そのポリシーの対象にはなりません。遅延ネイティブ、パフォーマンス、Telegram、広範なライブ QA、および E2E を、公開済みの正確なパッケージと run_release_soak=true または明示的なグループを用いたポストパブリッシュの信頼性確認として実行してください。安定版およびフルプロファイルはリリースソークを強制します。ネイティブ成果物の公開には、依然として独自のビルド、署名、公証、およびプロモーションのゲートが必要です。集中的な修正の後には狭い rerun_group を使用してください。自動的に範囲を広げないでください。 シール時点で、親は適格な npm レシートから SDK エビデンスダイジェストを記録し、レジストリに対してパッケージごとの npm プランを解決します。マニフェストの publishInputs は publisher/preflight のデフォルトを提供します。SDK API の変更には依然としてオペレーターの承認が必要です。シールされたエビデンスは権限を付与しません。 ミューテーションの担当者は、ライブ公開権限、セレクター、および不変バイトを再確認します。

公開要件

シールされたプロファイルを消費するには、release_profile=from-validation を指定して公開してください。安定版の公開には、安定版/フルのエビデンス、ソーク、およびブロッキングパフォーマンスが必要です。失敗したすべてのテストについて、ブロッカーかフレークかを判断してください。フレークは同じリリース SHA で最大 2 回まで再実行し、main に対して並行修正の issue/PR を起票してください。選択されたジョブが依然としてレッドの場合は、公開をブロックします。フレークを解消するためだけに、再カット、ツールの変更、または新しい FRV の開始を決して行わないでください。スキップ、キャンセル、欠落、および不明なカバレッジもブロックします。レーンまたはソークの免除は適用されません。

子の公開

公開の順序付けおよび prepared/direct リカバリには、メンテナ向けの公開リカバリガイドを使用してください。

  • pnpm release:stable <version>（オーケストレーションされた安定版リリース）は、 親を一度だけディスパッチし、親の npm-release ゲートを承認し、 npm-publish を持たない古いツール向けにのみ子の承認コマンドを出力し、 必要に応じて古い子のスイープコマンドを出力します（子の実行を変更することは一切ありません）。 いずれかの拒否が発生した場合、正確な復旧コマンドを含む Next: を出力します。

  • 親の npm-release 承認は、証明済みの openclaw-release-approval-v1-<parent run>-<attempt> レシートを発行します。ボットがディスパッチした 子は、ゲートの前にそれを検証します（scripts/release-approval-receipt.mjs verify）。ClawHub OIDC の子は、検証済みレシートがある場合、 自身の clawhub-plugin-release ゲートをスキップし、代わりに公開前に親の openclaw-clawhub-parent-authorization-v2-* レシートを待ちます。npm の子（Plugin NPM Release、openclaw-npm-release.yml）は、検証済みレシートのルートでは 自身の npm-release 承認ジョブをスキップし、npm-publish で公開します。トラステッドパブリッシャーはその環境にバインドされています。 公開の直前に、子は親の試行のレシートを待ち、その試行が in_progress のままであることを要求します。これにより、リリースごとに 1 回の人間による承認となります。 npm-publish にはレビュアーがなく、保護された release-publish/<sha12>-<n> タグのみを受け入れます。実際の手動/npm 復旧ディスパッチは そのようなツールタグを使用する必要があり、依然として独自の npm-release 承認ジョブが必要です。 読み取り専用の OIDC プリフライトも npm-publish を使用し、そのタグを必要とします。 アーティファクトのみのプリフライトは既存の ref を維持し、環境を持ちません。

  • plugin-clawhub-release.yml の子を手動で承認しないでください。これは ボットルートでレシート検証され、承認を必要としません。 openclaw-clawhub-recovery-approval-<run>-1 に対する Artifact not found 行は、致命的ではないプローブです。遅れて人間が承認すると、親が終了した後は parent state completed/failure is not allowed by authorization route で Revalidate trusted tooling identity に失敗します（2026.9.6: 実行 35930335388/35930341394）。コア npm がすでに公開している場合は、明示的な ClawHub 復旧 （公開の復旧）を通じて ClawHub を復旧してください。 そうでなければ、子をキャンセルし、親を再ディスパッチします。ブートストラップの子 （plugin-clawhub-new.yml）は常に clawhub-plugin-bootstrap を待ちます。シークレットレスな pack ジョブが完了した後に それらを承認してください （最初のパッケージ）。

  • v2 ClawHub の子は、1 つの失敗が待機中の親を失敗させてステージ済みの兄弟のファイナライズを 妨げる前に、ほとんどのパッケージをステージできます。 再公開または親の再開の前に、元の子の *-publish-json アーティファクトを照合してください。 pnpm release:clawhub-recovery -- --version <version> --reason '<parent failure>' --clawhub-source <isolated pinned ClawHub checkout> <package-publish.json>... を使用して、正確な試行復旧コマンドを出力します。固定ソース CLI と承認された実行については、 公開の復旧ガイドを参照してください。公開バージョンの 404 は ステージ済みと欠落を区別せず、試行ステータスにはパブリッシャー認証が必要です。親のレシートとライブ権限の再検証は 引き続き必要です。復旧は失敗した親を成功した証拠に変えるものではありません。

  • 最初の子のディスパッチの前に、親は同じリリースの失敗した以前の親の waiting/queued の子について、選択されたすべてのパブリッシャーをスイープします（ClawHub とコアは parent=<run>/<attempt> 実行タイトルで、プラグイン npm はリリース SHA で、ただし他に公開中の親が 稼働していない場合のみ）：これは ゲートの拒否とキャンセルを試み、その後ワークフローごとに最大 5 分間待機します。 403 で拒否が拒否された場合はレビュアーが必要です。ログとステップサマリーには 拒否/キャンセルのコマンドが含まれます。確認されていないキャンセルは警告を出します。コア npm は 独立した公開スロットを持ち、稼働中の親を再確認するため、ブロックしません。 プラグイン npm と ClawHub はターゲットごとに直列化されたスロットを保持し、キャンセルが確認されないままの場合は 新しいディスパッチの前に拒否します。識別されていないレガシーの ClawHub の子または稼働中のパブリッシャーもディスパッチガードを保持します。親の失敗は 自身の待機中の npm の子をキャンセルします。レビュアーとしてクリーンアップするには、このリリースのために作成された github-actions[bot] による workflow_dispatch 実行を一覧表示し、そのゲートを拒否し、キャンセルします：

    for s in waiting queued; do gh api "repos/openclaw/openclaw/actions/runs?status=$s&per_page=100" \
  --jq '.workflow_runs[] | select(.event=="workflow_dispatch" and .actor.login=="github-actions[bot]") | select(.name | test("plugin-clawhub|Plugin NPM Release|openclaw-npm-release")) | [.id,.name,.created_at] | @tsv'; done
env_id=$(gh api repos/openclaw/openclaw/actions/runs/<child>/pending_deployments --jq '.[0].environment.id')
gh api -X POST repos/openclaw/openclaw/actions/runs/<child>/pending_deployments \
  -f state=rejected -f comment="Reject stale release gate" -F "environment_ids[]=$env_id"
gh run cancel <child> --repo openclaw/openclaw

  • プラグイン npm 子プロセスでの gh run rerun --failed は、試行に紐づく 事前チェックのアーティファクト読み戻しに失敗します。親プロセスは元の子プロセスが 完了するのを待ち、その失敗を引き継ぎ、代替プロセスはディスパッチしません。 公開を明示的に復旧する前に、失敗した担当箇所を診断して修正してください。 成功した不変パッケージと証跡は保持してください。

拡張安定版の検証

.33+ の拡張安定版の検証にも、同じ候補所有のヘルパーを使用します。 C は正確に固定されたブランチ先端であり、Q=C は完全な適格性確認の一式を所有し、 独立して信頼された P がそれを受け入れて検証します。 正規の extended-stable/YYYY.M.33 ブランチはコンテキストを提供するものであり、 ワークフローの権限を持つものではありません。C を固定する前に、不足している 契約を意図的にバックポートしてください。

VALIDATION_SHA="<exact-candidate-sha>"
PUBLISHER_SHA="<recorded-full-trusted-main-ancestor-sha>"
CONTEXT_REF="extended-stable/YYYY.M.33"
pnpm ci:full-release \
  --sha "$VALIDATION_SHA" \
  --target-ref "$CONTEXT_REF" \
  --admission-workflow-sha "$PUBLISHER_SHA" \
  --admission-workflow-ref main \
  -f validation_purpose=publish \
  -f publication_selection_json='{"route":"extended-stable","npmDistTag":"extended-stable","publishOpenclawNpm":true,"pluginPublishScope":"all-publishable","plugins":[]}' \
  -f release_profile=stable \
  -f run_release_soak=true \
  -f fail_fast=false \
  -f rerun_group=all \
  -f reuse_evidence=false \
  -f dispatch_release_evidence=false

受け入れ後に不変の release-ci/<Q-prefix>-<timestamp> トランスポートを作成するのは、ヘルパーだけです。 raw-dispatch を実行したり、その参照を手動で作成したり、Q 用の保護された公開タグを 発行したりしないでください。既存の履歴上のリビジョン間公開リクエストは、元の 識別情報のまま調整してください。候補所有のものとして付け替えてはいけません。 新たに明示する main／保護ルートは、診断、main の適格性確認、または公開後の信頼度確認 専用であり、受け入れ済みの Q=C 公開証明の代わりにはなりません。

サポート対象の正確なターゲットを示すマニフェストを持つ、完全な rerun_group=all 実行のみを受け入れてください。そのワークフロー SHA は候補 SHA と 別に紐付け、マニフェストのターゲット、パッケージバージョン、保存された run_attempt、最終タグが同じ候補を特定していることを必須とします。 範囲の狭い実行、信頼されていないツール、ターゲットの不一致、以前の試行の証跡は 拒否してください。

all グループの親プロセスは、コアと選択されたプラグインの npm tarball をそれ自体で 準備し、不変の記述子を publicationArtifacts に記録します。公開では、これらの 正確なアーティファクトと試行を使用する必要があります。単独の npm または プラグイン npm の事前チェックは診断専用であり、マニフェストに紐づく証跡の代わりには なりません。

製品の不具合には、承認済みのバックポートが必要です。固定ターゲットのツール不具合には、 動作を保つ最小限の修正が必要です。プロバイダー、承認、ランナー、ログの競合が原因の 場合は、候補を変更しません。修正と置き換えられた実行を記録してください。 ブランチに変更があれば、新しい完全な親プロセスが必要です。明示的にサポート対象外の 固定ターゲットのシナリオのみ省略でき、必須の動作やパッケージは省略できません。

固定ターゲットのテスト省略

plugin_prerelease_node_exclude_patterns_json は、Plugin Prerelease Node レーン内の 正確な src/plugins/ テストパスにのみ使用してください。 Plugin Prerelease の拡張機能シャード内の正確な extensions/ テストパスには、 extension_test_exclude_patterns_json を使用してください。この網羅的テストは通常の CI の担当ではありません。どちらもデフォルトは [] です。暗黙の Codex 省略は ありません。初回ディスパッチ時に JSON 配列を渡し、省略の理由と担当する修正を保持し、 省略した網羅範囲は未実行として報告してください。

事前チェックでは、選択した固定ターゲットのレーン内で、要求されたすべてのパスを 検出する必要があります。存在しないパス、レーン外のパス、重複パス、ベース名、glob 入力は、 明確なエラーにしてください。信頼されたツールは、候補のランタイム準備を維持しながら インラインの Vitest リーフに正確な除外を適用し、シャードコマンドの実行後に元の 設定バイト列を復元します。CLI の --exclude や新しいターゲット側環境変数で代用 しないでください。固定されたインラインプロジェクトでは、それらが無視される場合が あります。入力は不変のリクエスト、網羅性／再利用の識別情報、最終マニフェストに 保持してください。これらを変更するには新しいリクエストが必要であり、処理を継続しては いけません。

監視

attempt-aware コントローラーで子ワークフローを監視します。

pnpm frv watch --run <full-release-run-id>

親のディスパッチジョブのログ行 （Dispatched <workflow>: <url> (attempt N)）から子の実行 ID を解決し、表示タイトルからは解決しません。また、各親と子の試行の状態遷移、および各失敗ジョブを、ランナーのラベルとともに一度だけ報告します。一時的な GitHub 5xx や HTML のエラーボディは次のポーリングで再試行され、ジョブの結果として報告されることはありません。状態は $TMPDIR/openclaw-frv/<repo>-<parent>-watch.json に保存されます（--state で上書きできます）。そのため、ハーネスまたは Monitor のタイムアウト後に再起動しても、同じ内容は再報告されません。--once はスナップショットを 1 回取得し、--interval <seconds> はポーリング間隔を設定します（デフォルトは 60）。--json は NDJSON を出力します。親とディスパッチ済みのすべての子が終端状態になると終了します。後から再実行した場合は、ウォッチャーを再起動してください。bash や gh で独自のウォッチャーを作成しないでください。

親の Release Decision には、遷移のみを表示するサマリーウォッチャーを使用します。

node scripts/release-ci-summary.mjs <full-release-run-id> --watch

SHA 固定のヘルパーがまだフォアグラウンドの所有者である場合、このウォッチャーを起動しないでください。ヘルパー自身が Release Decision のアーティファクトを直接読み取ります。blocked_diagnostics_running では、すぐにゼロ以外の終了コードで終了し、一時的なワークフローの ref を保持して、Diagnostic Drain が残りの終端証拠を収集できるようにします。別途ディスパッチされた親に対してもウォッチャーは同じように動作し、Release Decision のブロッカーを一度だけ報告して、ドレインが続く間に終了します。

スナップショットを 1 回取得する場合：

node scripts/release-ci-summary.mjs <full-release-run-id>

release-ci-summary が受け付けるのは Full Release Validation の親実行のみです。分岐したリリースブランチのログでは、--first-parent と上限付きの件数を指定します。ターンを終了する前、または戦略を切り替える前に、ウォッチャーを停止してください。

PR と子のゲートでは、コミットのチェック実行一覧ではなく、該当するワークフローの実行を正確に読み取ってください。commits/<sha>/check-runs には、同じ head に対する置き換え済みまたはキャンセル済みの実行のエントリーが残るため、古い cancelled や failure が新しい成功を隠すことがあります。head に対する最新の CI 実行（actions/runs?head_sha=<sha>）を特定し、再試行または報告する前に、その実行のジョブから openclaw/ci-gate を読み取ってください。

状態は正確に解釈してください。

  • qualifying：決定的なブロッカーはまだありません。選択された子は引き続き実行中です。
  • blocked_diagnostics_running：公開はブロックされています。Diagnostic Drain は独立した失敗の収集を続けています。今すぐ診断し、失敗した子が終端状態になったら frv rerun または continue --failed を使用してください。親の最終シール処理は、引き続きすべての証拠が揃うまで待機します。
  • passed：必須のポリシーと、対象の子に関するすべての証拠が合格しています。
  • blocked_complete：公開はブロックされており、選択されたすべての診断が終端状態です。
  • orchestration_error：GitHub API またはコレクターの失敗により、判定できませんでした。これは、誤ったソースが使われたことを意味するものではありません。同じ対象の子を使ってコレクターを復旧してください。収集を修復するためにテストを再ディスパッチしないでください。
  • cancelled_with_children：対象の子がまだ実行中の状態で、コレクターがキャンセルされました。

選択された各レーンの実際の結論をすべて確認してください。passed には、選択されたすべての検証レーンの成功が必要です。省略されたカバレッジは実行されていないのであり、合格したわけではありません。

full-release-diagnostics-<run-id>-<attempt> アーティファクトは、終端時の失敗と所要時間のマニフェストです。早期のブロッカー発生後は、実行中の子の調査結果を知るためだけに all を再起動するのではなく、このアーティファクトを使用してください。安定した full-release-execution-plan-<run-id> アーティファクトは、各コレクター試行における ID の情報源です。再試行時には、まず不変の実行 ID キャッシュからそのバイト列を復元します。

失敗のトリアージ

  1. 親 SHA と子の実行 ID を確認します。
  2. pnpm frv watch --run <parent> --once で失敗したジョブを一覧表示します。各失敗ジョブについて、試行回数、ランナーラベル、URL が表示されます。
  3. 失敗したジョブのログを 1 つ取得します。レート制限された場合は、リセット時刻を記録し、それ以上 REST 呼び出しを行わないでください。
  4. シークレットが原因と思われる失敗については、コードを編集する前に、同じシークレットソースから実際の完了を確認します。モデル一覧の取得に成功しただけでは不十分です。 Claude CLI のサブスクリプション認証情報は、独立したネイティブ認証経路です。クリーンなホームディレクトリで CLI を検証し、必須の Anthropic API キーレーンの代わりとして決して使わないでください。
  5. ライブキャッシュの失敗については、キーの欠落／無効、テキストが空、プロバイダーによる拒否、タイムアウト、ベースラインの不一致のどれに該当するかを確認します。プロバイダーの明確な証拠なしにリリースゲートを緩和しないでください。
  6. 編集する前に、失敗した各テストがブロッカーか不安定なテストかを判断します。不安定なテストの修正は main 上で追跡します。公開前に、選択したすべてのジョブが引き続き成功する必要があります。ブロッカーはさらに次のように分類します。
    • 製品／コードの失敗が確認された場合：リリースブランチを修正し、新しい Code SHA を固定して、製品エビデンスを無効にします
    • 適格性確認ハーネス／コントラクトの不具合：候補の依存関係を修復し、新しい C/Q を固定します。置き換えられたエビデンスと無効化の理由は保持します
    • P のみのアドミッション／検証／パブリッシャーの不具合：C/Q と元の成果物を保持し、独立した信頼済み P を修復して、影響を受けた対象範囲を復旧します
    • インフラ／認証情報の失敗：C/Q/P を保持し、外部の前提条件を修復して、失敗した対象範囲のみを再試行します
    • ラッパー／モニターの失敗：子と候補の ID を保持し、ラッパーの結果を子の結果と別に記録します
    • 変更履歴／リリースノートの失敗：split-changelog-release-v1 の下で、選択したリリースエントリと許可された記録／インデックスパスのみを変更します。Code SHA のエビデンスを保持し、Release SHA の証明を再実施します
    • 公開子／レジストリーセレクターの失敗：Release SHA を保持し、失敗した子を再開します。すでに公開済みの不変バージョンを再ビルドしないでください
    • コア npm の公開後に親が失敗した場合（たとえば、古い beta dist-tag が完了検証に失敗した場合）：成功した元の npm 実行と適格性確認済みのバイト列を保持し、セレクターを修復してから、選択した公開経路を再開する前に、失敗した親の子を正確に照合します。 直接ファイナライズは通常、npm と Docker の検証を待ちます。準備済みボタンでは ClawHub のダウンロードも検証されます。これらのゲートを回避するために、リリースのドラフトを手動で解除しないでください。直接再開または新しい準備済みボタンの実行については、公開の復旧に従ってください。
    • 子が waiting のまま止まっている場合、ClawHub が Artifact not found を返す場合、または親が ClawHub dispatch blocked by waiting run で失敗する場合：公開子を参照してください。 製品または適格性確認ハーネスの不具合のみが C/Q を変更します。1 回の診断／修正／範囲を絞った再試行の後、別の全グループサイクルを始めるのではなく、状況を再評価してください。
  7. ランナーのルーティング：FRV がディスパッチする CI と Plugin Prerelease の子は、常にホステッド ubuntu-24.04（またはリリースランナーグループ）で実行されます。その他のリリースレーンは OPENCLAW_CI_RUNNER_BACKEND に従うため、Blacksmith の障害中に github に切り替えると、QA Lab のランタイムペアレーンを除き、ホステッドランナーに移ります。QA Lab のランタイムペアレーンはホステッドランナーでは失敗し、Blacksmith に固定されたまま障害中はキューに入ります。切り替えが有効な間、Release Checks は Release runner routing 通知を表示します。Codex 拡張機能のテストは、ホステッドの Codex バッチに 36～60 分かかったため、ファイル単位に範囲を限定した Plugin Prerelease ジョブとして実行されます。
  8. 必須の PR CI 実行でジョブがキューに入ったまま容量不足で停止し、アクティブなジョブがない場合は、無関係な作業をキャンセルしたり、汎用の手動ディスパッチを受け入れたりしないでください。 まず、PR の head に現在のフォールバックスキーマが含まれていることを確認します。 gh api 'repos/openclaw/openclaw/contents/.github/workflows/ci.yml?ref=<pr-head-branch>' --jq .content | base64 --decode | rg -q 'pull_request_number:' 含まれていない場合は、main から PR の head を更新し、新しい head SHA を使用します。別のフォールバックを検討する前に、通常の CI を実行させてください。 PR の head ブランチから、明示的な完全一致 SHA のフォールバックをディスパッチします。 gh workflow run ci.yml --repo openclaw/openclaw --ref <pr-head-branch> -f target_ref=<full-pr-sha> -f pull_request_number=<pr-number> -f include_android=true -f release_gate=true GitHub ホステッドランナーで実行され、実行タイトルが CI release gate <full-pr-sha> の場合にのみ受け入れられます。停止した Blacksmith の実行とフォールバックの実行を、リリースエビデンスに記録します。 必須ゲートとして Blacksmith Build Artifacts Testbox だけが残っていて、ランナーが割り当てられずキューに残っている場合は、CI の build-artifacts ジョブがすでに成果物をビルド、パッケージ化し、スモークテストも実施しているため、完了したこの完全一致フォールバックで代替できます。成果物ワークフローが開始している場合、または成功以外の結果で完了した場合は、この代替を使用しないでください。

証拠

記録事項：

  • リリースライフサイクル台帳：通常リリースのコード SHA とリリース SHA、extended-stable の正規ブランチ、正確な SHA、変更不可能なタグ、どちらのトラックでも C/Q/P、元の登録記述子、保持されたリクエスト
  • 証拠の再利用ポリシー、カバレッジポリシー、変更されたパスの完全な一覧
  • アクティブな親の全体実行 URL、試行回数、ワークフロー SHA、および置き換えられた親があれば、正確な置き換え理由
  • 選択した子実行 ID と結論：CI、Release Checks、Plugin Prerelease、NPM Telegram、Product Performance。保留中の信頼度は「未実行」と記録
  • 終端マニフェストに記載された、コアおよびプラグインの npm 公開アーティファクトの正確な記述子
  • Linux／Windows／macOS のクロス OS を含む、選択したすべてのレーンの結論
  • 入手可能な場合は、以前のリリースとのパフォーマンス比較結果
  • 対象を絞ったローカル検証コマンド
  • 凍結対象との互換性修正、または適用外シナリオの省略。そのソース PR と不変条件も含める
  • ホスト環境での検証と、そのデプロイ前提条件をローカルのコントラクトテストと分けて記録すること。モックでは Actions の登録、OIDC、環境へのアクセス、公開を証明できません
  • 既知のギャップまたは無関係な失敗

教訓と復旧パターンについては、references/release-ci-notes.md を参照してください。

コメント

Markdown 対応