release-openclaw-mac

OpenClaw Mac リリース

安定版 macOS アセット、リリース運用の mac プリフライト、公証、appcast の昇格、または mac リリースの復旧が関係する場合は、$release-openclaw-maintainer、$release-openclaw-ci、$one-password、および存在する場合は $release-private と併用してください。

これは通常の安定版リリース用スキルです。extended-stable では呼び出さないでください。このトラックの GitHub リリースには共通の検証証跡が含まれますが、macOS アセットや appcast の昇格は継承されません。

リリースの承認

安定版または全リリースの明示的なリクエストには、オペレーターが対象範囲を限定していない限り、macOS の公開が含まれます。個別の macOS 承認を求めずに、検証、署名、公証、昇格、確認まで進めてください。正確なリリース識別情報とすべてのアーティファクトチェックを維持してください。macOS の公開は npm と並行して行われ、npm をブロックすることはありません。mac の失敗によって npm／ClawHub リリース、GitHub リリースの最終確定、またはメインのクローズアウトを保留しないでください。並行して修正してください。

現在のオーナー設定の環境ポリシーに従ってください。追加のレビュアー要件を作ったり、廃止された要件を復活させたりしないでください。GitHub が引き続き承認を強制している場合は、実際のルールを報告し、そのオーナーを通じて解決してください。ポリシーの変更には、組織オーナーからの明示的な指示と、有効な管理者メンバーシップの確認が必要です。レビュアーになりすましたり、承認を捏造したり、別の署名経路を使って強制されているルールを回避したりしないでください。

認証情報

• Peter が所有する ASC 項目の参照、キー ID、発行者 ID、サービス・トークンの出所は $release-private から解決してください。
• フィールド：private_key_p8、key_id、issuer_id。
• 古い／失効したキーの症状：xcrun notarytool submit が HTTP status code: 401. Unauthenticated で失敗します。
• GitHub シークレットを設定する前に、候補となる ASC 認証情報を xcrun notarytool history で検証してください。

1Password

• $one-password を使用してください。すべての op 作業は、1 つの永続的な tmux セッション内で行い、シークレットを出力しないでください。
• 利用可能な場合は、$release-private のサービストークンに関するガイダンスを使用してください。
• サービストークンが失敗した場合は、ステータスのみを確認してください。トークンの有無／長さと op whoami を確認し、トークンの値は決して出力しないでください。
• デスクトップアプリの認証が必要で Touch ID を利用できない場合は、手動の op account add --signin 経路で OP_BIOMETRIC_UNLOCK_ENABLED=false を設定してください。

GitHub シークレット

対象のリリース運用リポジトリ環境：openclaw/releases、環境 mac-release

ローカルで公証認証を検証した後にのみ設定してください。

• APP_STORE_CONNECT_API_KEY_P8
• APP_STORE_CONNECT_KEY_ID
• APP_STORE_CONNECT_ISSUER_ID

これらを複数の異なるソースから更新しないでください。ASC の 3 つのフィールドはすべて、同じ 1Password 項目から取得する必要があります。

ワークフローの構成

• openclaw/openclaw は公開製品リポジトリです。最終的に macOS アセットが添付されるのは、その GitHub Releases ページです。
• openclaw/openclaw の macos-release.yml は、公開引き継ぎ時の検証のみを行います。preflight_only に関係なく、macOS アセットへの署名、公証、アップロードは行いません。
• openclaw/releases はアクセス制限されたリリース運用リポジトリです。その macOS ワークフローは、openclaw/openclaw の GitHub リリースにアセットを署名、公証、検証し、昇格します。
• stable タグ／npm がすでに公開された後でも、公開リリースブランチには mac 専用のパッケージ修正を含められます。
• そのブランチの変更をビルドする場合、リリース運用の mac プリフライト／検証には source_ref=release/YYYY.M.PATCH を使用してください。
• tag=vYYYY.M.PATCH は元の安定版リリースコミットを指す状態にしてください。
• 実際の mac 公開では、以下を再利用する必要があります。
  • 同じタグ／ソース SHA に対して成功したリリース運用の mac プリフライト実行
  • 同じタグ／ソース SHA に対して成功したリリース運用の mac 検証実行
• リリース運用のプリフライトと実際の公開では、署名および昇格用シークレットと main のみのデプロイポリシーのために mac-release 環境を使用します。承認済みのリリースオペレーターは、その環境の現行ルールに従って作業を継続します。
• プリフライトのソース SHA がタグの SHA と異なる場合、検証でも同じ source_ref を使用する必要があります。昇格時に、証跡の不一致は拒否されます。

公証

• OpenClaw は scripts/notarize-mac-artifact.sh を使用します。
• xcrun notarytool submit では --no-s3-acceleration を指定してください。高速アップロードでは、notarytool history が成功していても、誤解を招く 401 が発生することがあります。
• 署名は成功したのに公証がすぐに 401 で失敗する場合は、まず ASC キーの有効性を確認してください。
• キーファイルを書き込んだ後、公証が数分間処理中のままでも問題ありません。Apple 側の待ち時間として正常な動作です。むやみに編集しないでください。

ディスパッチ

公開ハンドオフのワークフローでは、公開前にタグ、ソース、ビルド、パッケージのメタデータを検証します。アセットをアップロードしないため、GitHub リリースページは必要ありません。この検証は、実際の公開ワークフローより前に行ってください。中核となる公開処理が GitHub リリースの最終確定を担います。macOS のプロモーションでは、そのリリースが下書きか公開済みかを問わず、検証済みのアセットを添付するため、npm の切り替えを待つことはありません。

公開ハンドオフの検証：

gh workflow run macos-release.yml --repo openclaw/openclaw \
  --ref release/YYYY.M.PATCH \
  -f tag=vYYYY.M.PATCH \
  -f preflight_only=true \
  -f public_release_branch=release/YYYY.M.PATCH

• Actions の一覧に release/YYYY.M.PATCH と表示され、以前の安定版 macOS ハンドオフの実行と一致するよう、公開リリースブランチをワークフローの ref として使用してください。
• この公開ハンドオフの検証では --ref main または --ref vYYYY.M.PATCH を使用しないでください。ワークフローは内部で tag 入力からタグをチェックアウトします。

リリース運用の事前確認：

gh workflow run openclaw-macos-publish.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f source_ref=release/YYYY.M.PATCH \
  -f preflight_only=true \
  -f smoke_test_only=false \
  -f allow_late_calver_recovery=false \
  -f public_release_branch=release/YYYY.M.PATCH

設定済みの環境ポリシーに従い、署名と公証まで実行を追跡してください。事前確認に成功した実行 ID を記録してください。承認待ちで一時停止しているだけでは、事前確認の成功とはみなされません。

デフォルトでは再開します。失敗（公証の停止、DMG のパッケージ化、コレクター）後に同じ事前確認コマンドを再度ディスパッチすると、同じタグとソース SHA に対する失敗またはキャンセル済みの main ディスパッチで残された最新のチェックポイントから、すべてのバリアントを再開します。チェックポイントのないバリアントのみ再ビルドされます。実行ログには Resuming <variant> from run <id> attempt <n> または Building <variant> と表示されます。ignore_checkpoints=true を指定すると、常に新規ビルドが実行されます。resume_notarization_run_id、resume_notarization_run_attempt、resume_notarization_variant は、特定の実行を固定する場合、または再開インデックスの導入前に作成されたチェックポイント（macos-resume-<tag>-<variant>-<sha> アーティファクト）に対してのみ指定してください。失敗したジョブが現在の実行に残っている場合は、gh run rerun <run-id> --failed --repo openclaw/releases を使用してください。

ブランチ違いの事前確認に対するリリース運用の検証：

gh workflow run openclaw-macos-validate.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f source_ref=release/YYYY.M.PATCH

検証に成功した実行 ID を記録してください。

実際の公開：

gh workflow run openclaw-macos-publish.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f preflight_only=false \
  -f smoke_test_only=false \
  -f preflight_run_id=<successful-preflight-run> \
  -f validate_run_id=<successful-validation-run> \
  -f allow_late_calver_recovery=false \
  -f public_release_branch=release/YYYY.M.PATCH

同じリリース承認と現在の環境ポリシーの下で、アセットのアップロードとアプリキャストの公開までプロモーションを追跡してください。

• リリース運用の openclaw/releases 公開／検証ワークフローは、信頼された独自の main ワークフロー ref から実行されます。実際の公開には、他のワークフロー ref を拒否するガードがあります。表示される main ref は想定どおりです。公開する OpenClaw のソースは tag と任意の source_ref で選択します。

検証

• gh release view vYYYY.M.PATCH --repo openclaw/openclaw で zip、dmg、dSYM zip が表示されることを確認します。npm 公開処理で切り替えられた後は、下書きでもプレリリースでもないことも確認します。
• 公開されている main の appcast.xml が OpenClaw-YYYY.M.PATCH.zip を指していることを確認します。
• アプリキャストのエントリーに sparkle:version、sparkle:shortVersionString、長さ、sparkle:edSignature が含まれていることを確認します。