release-openclaw-nightly

Nightly Release

Tideclaw/OpenClaw のアルファ／ナイトリーリリースの自動化、アルファの手動トリガー、ベータの準備、リリースブランチの修復、リリース後のフォワードポートに使用します。Tideclaw のホストパス、cron ID、Discord のルーティング ID を使用する前に、$release-private が存在する場合は読み込んでください。

Policy

• アルファ／ナイトリーは12時間ごと、または手動トリガーで実行します。
• ベータは、実績のあるアルファ／リリースブランチから、Discord を通じて人がトリガーします。
• stable／latest には、必ず人による明示的な確認が必要です。
• 汚れたチェックアウトや main から直接公開してはいけません。
• main は処理中または壊れている場合があります。一時的な main の障害が利用可能なナイトリーを妨げないよう、アルファ作業は分離する必要があります。
• リリースブランチの検証に合格した後にのみ公開します。
• アルファの成功後、リリースブランチのコミットを main にフォワードポートし、main の CI が正常であることを検証します。
• フォワードポート PR には、ナイトリー／リリースのチェックを通すために必要な、再利用可能な修正のみを含めます。アルファのバージョン更新、リリースノート、変更履歴のリリース項目、タグ、生成アーティファクト、状態ファイルの更新を含めてはいけません。
• 直近3日間のアルファ／ナイトリーブランチと、実行中のジョブ、オープン PR、またはリリースタグがあるブランチのみを残します。
• 広範な環境変数／トークンダンプを実行してはいけません。Tideclaw ホストで GitHub に書き込みを行う場合は、以下の Tideclaw の gh 書き込みラッパーを使用します。
• アルファ、ベータ、または修復ブランチで、固定されたベースを超えるバックポートの検出や再利用が必要な場合は、候補を変更する前に、以下の自己完結型監査を完了してください。現在固定されている origin/main から直接アルファを開始しても、それだけではバックポート監査は発生しません。

Audit Nightly Backports

バックポートを検出する場合は、正確なリリースのベースラインとソース main の SHA を固定します。最後に承認された監査カーソルから開始し、カーソルがない場合は両者のマージベースから開始します。パッチ同等ではないソースコミットをすべて列挙し、承認済みの公開・非公開アドバイザリと照合して、既存のアルファ状態ファイルに範囲、件数、フィルター、適用可能性の結果、判断、除外項目、依存関係、ブロック項目を記録します。

タイトルは判断材料であり、適用条件ではありません。全インベントリを分類し、セキュリティまたは信頼性を示唆する本番環境向け差分をすべて調査してください。また、実行、認証、サンドボックス化、ネットワーキング、永続化、配信、ゲートウェイ、設定、プラグイン、主要チャネルの各パスにある標準的な fix、perf、doctor コミットも個別に確認してください。そのような差分はそれぞれ、切り離されたベースラインのワークツリーに対して機械的に適用を試み、適用可能、競合、空／適用済み、失敗のいずれかを記録します。パッチを適用できることはトリアージの証拠であり、自動的にバックポートする根拠ではありません。

固定されたソース SHA にある maturity:stable ラベル付きの OpenClaw イシューもスナップショットし、監査の範囲と併せてラベルクエリ時刻を記録します。オープンかクローズかを問わず、ラベル付きイシューのうち、修正 PR またはコミットがスキャン範囲内で実際にマージされているものはすべて、コミット台帳の判断と照合します。また、ラベル付きのオープンな P0／P1 イシューすべてに、fixed、not-affected、maintainer-deferred、blocked のいずれかの明示的なリリース処置を割り当てます。ラベルは網羅性と優先度を示すシグナルとしてのみ扱ってください。レビュー理由を検証し、機能、新しい設定またはポリシー、ドキュメント／サポート、成熟度の低い一致を label-drift として記録します。ラベルだけから修正済みであること、バックポートの承認、リリースブロッカーを推測してはいけません。

提案する各項目について、変更全体、ベースラインの挙動、呼び出し元、呼び出し先、関連箇所、テスト、依存関係の契約、セキュリティへの影響、公開範囲を調査します。重複または依存するコミットを統合し、最小限の最終修正にします。メンテナーが明示的に承認しない限り、機能、移行、新しい設定または実行時要件、広範な再設計は除外します。候補を変更する前に、分類済みの項目一式を提示して承認を得てください。その後、同じ状態ファイルに来歴を保持し、対象を絞った検証とリリース検証を実行します。npm の事前チェックは、正規のブランチ／タグに正確な最終バージョンと SHA が設定された後にのみ実行してください。

ID

リリースブランチとフォワードポート用ブランチでは、Tideclaw は自身のマシン ID でコミットする必要があります。

git config user.name "Tideclaw"
git config user.email "[email protected]"

コミットが明確にマシンによるもので、CI によるゲートが設けられていれば、監査性の面で有効です。保護された main への直接プッシュは避け、リポジトリのポリシーでグリーンチェック後のボットによるプッシュが明示的に許可されていない限り、PR／自動マージを使ってフォワードポートしてください。人間がパッチまたは明示的なコミット文を提供した場合に限り、人間の Co-authored-by を含めてください。

ブランチの形式

• ブランチのプレフィックス：tideclaw/alpha/
• ブランチ名：tideclaw/alpha/YYYY-MM-DD-HHMMZ
• ベース：トリガー時点の origin/main の SHA。
• 状態ファイル：Tideclaw ホスト上の $release-private から解決します。
• リリースタグ：vYYYY.M.PATCH-alpha.N
• npm の dist-tag：alpha

PATCH は月ごとに連番で割り当てるリリーストレイン番号であり、カレンダー上の日付ではありません。安定版とベータ版のリリースからアルファのトレインを決定し、アルファのみのパッチ番号は次のトレインを選ぶ際に無視してください。その月の安定版／ベータ版で最も大きいパッチ番号に 1 を加えた値を使い、同じトレインで夜間リリースを繰り返す場合は alpha.N だけを増やしてください。次のパッチ番号でベータ版が存在する場合、アルファは次のトレインに移してください。過去の、パッチ番号が不自然に大きいアルファのみのタグによって、ベータ版／安定版の番号を進めてはいけません。

新しい実行では、過去のアルファブランチを再利用しないでください。同じベース SHA を再実行する場合は、新しいタイムスタンプ付きブランチを作成し、その理由を記録してください。

開始

1. $release-private にある Tideclaw ホストのチェックアウトで作業します。
2. まずフェッチします。

git fetch origin main --tags --prune
git switch main
git merge --ff-only origin/main
BASE_SHA="$(git rev-parse origin/main)"
BRANCH="tideclaw/alpha/$(date -u +%Y-%m-%d-%H%MZ)"
git switch -c "$BRANCH" "$BASE_SHA"

3. 変更を加える前に、リポジトリのリリース関連ドキュメントとスクリプトを確認します。
   • AGENTS.md
   • docs/ 内のリリース関連ドキュメント
   • scripts/ 内のリリーススクリプト
   • .github/workflows/*release*
4. $BASE_SHA を、最後に成功したアルファの状態、および現在の git／npm／GitHub のアルファタグと比較します。すでにリリース済みの場合は、スキップすることを報告し、公開しないでください。

手動トリガー：

CRON_ID="<from release-private>"
OPENCLAW_ALLOW_ROOT=1 openclaw cron run "$CRON_ID" --expect-final --timeout 21600000

Discord のアルファトリガー

メンテナーが #releases または #maintainers で Tideclaw にメンションした場合、Tideclaw は Discord から直ちにアルファを実行できます。

受け付ける形式：

@Tideclaw run alpha now
@Tideclaw alpha release from main now
@Tideclaw trigger alpha

ルール：

1. これはアルファの cron ジョブと同等の手動アルファトリガーとして扱ってください。
2. 現在の origin/main から開始し、新しい tideclaw/alpha/YYYY-MM-DD-HHMMZ ブランチを作成してください。
3. 通常のアルファワークフローに従ってください。以前の修正を再利用し、ローカルチェックを実行し、アルファブランチで修正を行い、リリース CI を実行し、すべてのゲートが通過した後にアルファを公開し、その後、再利用可能な修正のみを含む PR でフォワードポートしてください。
4. 別のアルファ／ベータ／安定版リリースの実行がすでに進行中の場合は、進行中のブランチ／実行を報告して停止してください。
5. #maintainers からのトリガーには、Tideclaw への明示的なメンションが必要です。そのチャンネルでメンションなしのリリースに関する会話には反応しないでください。
6. Discord のロール／ユーザー ID と、ホストで現在有効なホットフィックスのメモは、$release-private から取得してください。

Discord ベータトリガー

Tideclaw は、メンテナーが明示的なベータトリガーを送信した場合に限り、#releases またはメンションされた #maintainers コマンドからベータリリースを実行できます。これはベータに対する人間の承認として扱い、stable/latest に対する承認とは見なしません。

受け付ける形式：

@Tideclaw beta release from vYYYY.M.PATCH-alpha.N
@Tideclaw beta release from tideclaw/alpha/YYYY-MM-DD-HHMMZ
@Tideclaw beta release from latest proven alpha

ルール：

1. beta release という語句と、ソースとなる alpha タグ／ブランチ、または latest proven alpha を必須とします。
2. ソースが曖昧な場合は、#releases で確認の質問を1つ行い、そこで止めます。
3. まずソースとなる alpha を検証します。GitHub リリース、npm の alpha パッケージ、リリース CI、記録された状態ファイル、ブランチ／タグの SHA を確認します。
4. 検証済みの alpha ソースから、新しいベータブランチ tideclaw/beta/YYYY-MM-DD-HHMMZ を作成します。移動する main から直接作成してはいけません。
5. alpha で検証済みの安定化修正のみを再利用／スカッシュします。ベータリリースのドキュメントで必要とされていない alpha 固有のリリース手順は取り込みません。
6. npm の --tag beta に合わせて、ベータを vYYYY.M.PATCH-beta.N として計算します。ベータトレインの選定では、alpha のみのパッチ番号を無視します。
7. ベータリリースの検証／事前チェック／完全なリリース CI を実行し、失敗があればベータブランチで修正します。
8. ベータのゲートがすべて成功した後に限り、ベータを公開します。GitHub Actions／OIDC を使用し、ホストから npm publish を直接実行してはいけません。
9. Discord の最終報告には、ソース alpha、ベータタグ／バージョン、ブランチ、修正コミット、ワークフロー実行 ID、npm／GitHub の証拠、スキップまたはブロックされた理由を記載します。
10. ベータ公開後、以下の修正のみの PR ルールに従って、再利用可能な修正を main にフォワードポートします。

以前の修正を再利用する

チェックを実行する前に、過去のリリース試行中にすでに行われた修正を求めて、最近の Tideclaw alpha ブランチを調べます。

1. $release-private から Tideclaw の状態ファイルを読み、最後に成功した alpha ブランチと修正コミット SHA を確認します。
2. 最近のリモートブランチを一覧表示します。

git for-each-ref refs/remotes/origin/tideclaw/alpha --format='%(refname:short) %(committerdate:iso-strict)'

3. 過去3日間の Tideclaw alpha ブランチと、最後に成功した alpha ブランチのみを対象とします。
4. 各候補ブランチについて、現在の origin/main に含まれていないコミットを調べます。

git log --no-merges --reverse --format='%H%x09%s' origin/main..origin/tideclaw/alpha/YYYY-MM-DD-HHMMZ

5. 新しい alpha ブランチにも適用できる、実際の安定化修正のみをチェリーピックします。すでに承認済みの状態ファイルの修正を再利用するのではなく、新たに修正を見つけた場合は、選定前に nightly バックポート監査を適用します。チェリーピックが競合なく適用できることや、タイトルが無害であることは承認を意味しません。状態ファイルの fixCommitShas に記録されたコミットを優先します。
6. バージョンの更新、変更履歴のリリース項目、タグの成果物、生成されたリリースノート、状態ファイルのみのコミット、一時的なデバッグ計測はスキップします。
7. チェリーピックで競合が発生した場合、現在の main に同等の修正がすでに含まれているかを調べます。含まれていない場合は、最小限の解決にとどめ、コミットメッセージを明確にします。
8. 再利用したコミット SHA と新たに作成した修正の SHA は、alpha の状態と Discord の最終報告にそれぞれ分けて記録します。

main にすでに存在する修正の重複を避けるため、git cherry、git range-diff、対象を絞ったテストの再実行を使用します。

修復ループ

ブランチをリリース候補の修復用ブランチとして使用します。

1. まず範囲を絞ったローカルチェックを実行します。変更したテスト、リリースの事前チェック、リリースドキュメントで必須とされる型／lint／ビルドのゲートが対象です。
2. ローカルチェックに失敗した場合は、alpha ブランチで最小限のコミットを作成して修正します。
3. まとまりのある修正ごとに、Tideclaw としてコミットします。
4. 修正のたびに、失敗したローカルチェックを再実行します。
5. リリースドキュメントで明示的に必要とされ、その差分が妥当である場合を除き、ベースライン、想定される失敗の一覧、ignore ファイル、リリースインベントリを編集して失敗を隠してはいけません。
6. 失敗が不安定な場合は1回再実行します。それでも失敗する場合は、実際の問題として扱います。
7. 修正が main に明らかに有用な場合は、小さく保ち、フォワードポートしやすくします。alpha の安定化中に広範なリファクタリングは避けます。

コミット例：

git add <files>
git commit -m "fix: stabilize alpha release preflight"
git push -u origin "$BRANCH"

リリース CI

ローカルで検証した後：

1. 既存の git タグ、npm バージョン、GitHub リリースから、次の vYYYY.M.PATCH-alpha.N を算出します。PATCH は日付や alpha のみの最大パッチではなく、安定版／ベータ版の系列から選択します。同じ alpha 系列を使い、該当するパッチにベータ版ができるまで alpha.N を増やします。ベータ版ができた後は、新しい alpha ビルドには次のパッチを使います。
2. alpha ブランチのパッケージバージョンとリリースメタデータをそのタグに合わせ、コミットしてブランチをプッシュします。
3. ブラウザー／fetch ツールではなく、GitHub CLI を使って alpha ブランチからリリース検証を実行します。Tideclaw ホストでは、単独の gh は読み取り専用の Codex サンドボックスラッパーです。workflow run、run cancel、公開のディスパッチなど、書き込み可能なコマンドには /usr/local/bin/gh-tideclaw-write を使います。

GH="/usr/local/bin/gh-tideclaw-write"
SHA="$(git rev-parse HEAD)"
TAG="v$(node -p "require('./package.json').version")"
BRANCH="$(git branch --show-current)"
PUBLICATION_SELECTION='{"route":"alpha","npmDistTag":"alpha","publishOpenclawNpm":true,"pluginPublishScope":"all-publishable","plugins":[]}'
FRV_ENVELOPE="$(jq -cn --arg ref "$BRANCH" --arg sha "$SHA" \
  --argjson selection "$PUBLICATION_SELECTION" \
  '{trustedWorkflow:{ref:$ref,fullRef:("refs/heads/"+$ref),sha:$sha},validationPurpose:"publish",publicationSelection:$selection}')"

"$GH" workflow run full-release-validation.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f ref="$BRANCH" \
  -f expected_sha="$SHA" \
  -f trusted_workflow_json="$FRV_ENVELOPE" \
  -f release_profile=beta \
  -f rerun_group=all

"$GH" workflow run openclaw-npm-release.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f tag="$SHA" \
  -f preflight_only=true \
  -f npm_dist_tag=alpha

4. gh run list、gh run view、gh api を使って、対象のワークフロー実行 ID と head SHA を監視します。ポーリングには読み取り専用の gh を使って構いません。GitHub を変更するコマンドに限り $GH を使います。GitHub API のポーリングに Codex ブラウザー／fetch は使わないでください。以前の Tideclaw 実行では、事前チェックに成功した後に失敗しています。
5. 選択したすべての検証レーンは、失敗した場合 alpha の公開をブロックします。対象には、クロス OS、ライブチャネル、QA Lab、パッケージ受け入れ、Docker E2E、Telegram パッケージ E2E が含まれます。選択したレーンの実際の結果を報告し、公開前に失敗したレーンを解決してください。
   • 同じ head と公開対象を指定した Focused Full Release Validation グループを使って、個々のレーンを診断または再実行できます。成功した focused install-smoke の実行は、失敗した rerun_group=all の公開証拠の代わりにはなりません。公開前に、必要な all-group 検証を完了し、確定してください。
6. 選択したゲートが失敗した場合は、alpha ブランチで修正し、プッシュして、失敗したリリース CI または必要なリリース CI を再実行します。コミットが変更された場合は、古い事前チェック／完全検証の実行 ID を破棄し、新しい head で再実行します。
7. 同じブランチ head で完全検証と npm の事前チェックが成功した後、 npm の事前チェックにある Plugin SDK API diff の概要を確認します。変更が報告された場合は、 plugin-sdk-api-release-diff-<npm-preflight-run-id>-<run-attempt> アーティファクトをダウンロードして、 変更された宣言を確認し、その digest の先頭 8 文字を PLUGIN_SDK_API_ACKNOWLEDGEMENT に設定します。 変更が報告されなかった場合は、空文字列に設定します。その後、同じコミットから リリースタグを作成してプッシュします。

NPM_PREFLIGHT_RUN_ATTEMPT="$(gh api \
  "repos/openclaw/openclaw/actions/runs/${NPM_PREFLIGHT_RUN_ID}" \
  --jq .run_attempt)"
plugin_sdk_diff_dir="$(mktemp -d)"
gh run download "$NPM_PREFLIGHT_RUN_ID" --repo openclaw/openclaw \
  --name "plugin-sdk-api-release-diff-${NPM_PREFLIGHT_RUN_ID}-${NPM_PREFLIGHT_RUN_ATTEMPT}" \
  --dir "$plugin_sdk_diff_dir"
jq '{digest, entrypointsAdded, entrypointsRemoved, exports}' \
  "$plugin_sdk_diff_dir/plugin-sdk-api-release-diff.json"

PLUGIN_SDK_API_ACKNOWLEDGEMENT=""
# After reviewing a nonempty diff, use its printed digest:
# PLUGIN_SDK_API_ACKNOWLEDGEMENT="$(jq -r '.digest[0:8]' \
#   "$plugin_sdk_diff_dir/plugin-sdk-api-release-diff.json")"

git tag -a "$TAG" "$SHA" -m "openclaw ${TAG#v}"
git push origin "$TAG"
rm -rf "$plugin_sdk_diff_dir"

8. 公開は現在ブロックされています。npm の子ワークフローには保護された release-publish/* ツールタグが必要ですが、alpha ブランチの SHA は main にないため、 ensureReleasePublishToolingTag はそれらのタグを作成できません。また、親ワークフローの承認レシート create は tideclaw/alpha/* の参照を拒否します。候補と検証の証拠を保持し、このツールの問題を報告してください。環境ポリシーの適用範囲を広げてはいけません。以下の過去のディスパッチには復旧用の alpha 入力が記録されていますが、経路が修復されるまでは実行しないでください。

FULL_RELEASE_VALIDATION_RUN_ATTEMPT="$(gh api \
  "repos/openclaw/openclaw/actions/runs/${FULL_RELEASE_VALIDATION_RUN_ID}" \
  --jq .run_attempt)"
"$GH" workflow run openclaw-release-publish.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f tag="$TAG" \
  -f preflight_run_id="$NPM_PREFLIGHT_RUN_ID" \
  -f full_release_validation_run_id="$FULL_RELEASE_VALIDATION_RUN_ID" \
  -f full_release_validation_run_attempt="$FULL_RELEASE_VALIDATION_RUN_ATTEMPT" \
  -f plugin_sdk_api_acknowledgement="$PLUGIN_SDK_API_ACKNOWLEDGEMENT" \
  -f npm_dist_tag=alpha \
  -f plugin_publish_scope=all-publishable \
  -f publish_openclaw_npm=true \
  -f release_profile=beta \
  -f wait_for_clawhub=false

9. 公開経路の修復後は、公開ラッパーと子ワークフローの実行を監視し、その結果を確認します。公開がブロックされている間は、リリース完了としてはいけません。
10. ホストから npm に直接公開してはいけません。GitHub Actions／OIDC を使ってください。

重要：openclaw-npm-release.yml の preflight_only=true はアーティファクトを準備するだけです。公開は行いません。alpha の公開を完了するには、その後に openclaw-release-publish.yml ラッパーを実行し、git タグをプッシュし、npm の alpha dist-tag の証拠を確認し、GitHub プレリリースを作成する必要があります。

公開済みアルファ版の確認

次のすべてを満たすまで、リリースは完了していません。

• GitHub タグが存在する。
• GitHub Release が存在し、プレリリースとしてマークされている。
• リリース本文に npm のバージョンページ、レジストリーの tarball、整合性情報、CI／証明へのリンクが記載されている。
• npm view openclaw@<version> に、該当するバージョン、dist-tag alpha、tarball、整合性情報、公開時刻が表示される。
• インストール済みパッケージのスモークテストが、リポジトリーのリリースドキュメントに従っている。
• $release-private の Tideclaw 状態ファイルに、バージョン、タグ、ベース SHA、ブランチ、修正コミット SHA、ワークフロー実行 ID、npm の整合性情報、タイムスタンプが記録されている。

#releases に投稿する Discord の最終まとめ：

• タグ／バージョン
• ベース SHA
• ブランチ
• 修正コミット
• ワークフロー実行 ID
• npm／GitHub の証拠
• リリースしなかった場合は、スキップ／ブロックの理由

Discord で安全な、ターゲットを山括弧で囲んだ Markdown リンクを使用してください。シークレットは決して表示しないでください。

フォワードポート

アルファ版の公開が成功したら、修正のみの PR を main に戻します。

1. 現在の origin/main からフォワードポート用ブランチを作成または更新します。

git fetch origin main --prune
git switch -c "tideclaw/forward-port/$(date -u +%Y-%m-%d-%H%MZ)" origin/main

2. nightly／リリースチェックを通すために必要な、実際の修正を含むリリースブランチのコミットのみを cherry-pick します。
3. アルファ版のバージョン更新、変更履歴のリリース項目、リリースノート、タグのアーティファクト、生成されたリリースアセット、状態ファイルのみのコミット、アルファ版の公開だけを目的とするコミットは除外します。
4. 実際の修正とリリース／バージョン変更が混在するコミットは分割します。フォワードポート用ブランチに、修正の差分のみを新しいコミットとして適用します。
5. 競合は、main との互換性を保つ最小限の修正を優先して解決します。
6. 変更箇所に関連するローカルゲートを実行します。
7. プッシュして PR を作成するか、リポジトリーで許可されているボットのマージ手順を使用します。
8. 必須の main CI が成功するまで待ちます。CI が失敗した場合は、フォワードポート用ブランチで修正して再実行します。
9. PR／マージ SHA と、意図的にフォワードポートしなかったコミットを報告します。

フォワードポートを行う前から origin/main が独立して失敗している場合は、関連のない失敗チェックを記録し、可能であれば、その先頭の状態に対してフォワードポート PR が成功するようにしてください。

ブランチの保持

各実行の前後に、古いアルファ版ブランチを整理します。

1. origin/tideclaw/alpha/* を一覧表示します。
2. タイムスタンプが直近 3 日以内（UTC）のブランチを保持します。
3. 実行中のワークフロー、オープン PR、リリースタグ、または状態ファイルから参照されているブランチを保持します。
4. Tideclaw が所有するアルファ版ブランチのみを削除します。

git push origin --delete tideclaw/alpha/YYYY-MM-DD-HHMMZ

人間が作成したブランチ、ベータ版ブランチ、安定版ブランチ、または不明なプレフィックスのブランチは、決して削除しないでください。

停止条件

次の場合は停止し、状況を明確に報告してください。

• リリースドキュメントとスクリプトで、バージョン管理または公開手順に食い違いがある
• 必須のシークレット／認証情報を利用できない
• GitHub Actions を実行または監視できない
• 実際に修正を試みても、必須のリリースゲートが失敗したままである
• 公開後に npm／GitHub の状態が一致しない
• より大きなプロダクト上の判断なしでは、フォワードポートを成功させられない