workflow-ship-change

ワークフロー：変更をリリースする

変更は、以下のすべてを満たし、レポートに各項目が示されている場合にのみ完了です。

1. 実際に描画されたゲームのスクリーンショット：開始状態、重要な場面、結果。レポート内にインラインで表示します。
2. 独自の変更履歴バージョンと、ゲーム内の変更履歴ページに掲載された画像。
3. 検証済み：
   • 自分で実施したテスト；
   • マージしたコミットのテスト；
   • アセットチェック；
   • プッシュ済みのコミットで実行した全テストスイート。
4. コミット済み：まとまりのあるコミットを1つ作成し、自分のファイルだけをステージします。
5. プッシュ済み：main にファストフォワードでプッシュし、GitHub で確認済みです。
6. 公開済み：その main のビルドを公開し、実際のドメインで動作を確認済みです。
7. 計測済み：コミット、プッシュ、アップロード、公開の各サイズをすべて計測し、推定値は使いません。

プロジェクト独自のリポジトリと公開サイトへのプッシュおよび公開は、あらかじめ許可されています。そのため、以下のガードレールに中止の指示がある場合を除き、事前に確認を求めないでください。作業を始める前に、プロジェクトの AGENTS.md と、このスキルの references/<project>.md があればそれを読んでください。プロジェクトのルールは頻繁に変わるため、このスキルと異なる場合はプロジェクトのルールが優先されます。

ガードレール：中止してユーザーに確認する

• 50 MB を超えるアップロード。git push、Netlify へのデプロイ、メディアリリース、外部サービスへのファイル送信が該当します。
  • まずサイズを計測し（upload-size.sh、または push-main.sh が出力するパックサイズ）、確認を求める際にサイズを伝えます。
  • 操作全体を合算し、上限以下に収めるために分割してはいけません。
  • Supabase のメディアを全量リリースする場合（約 861 MiB）は、必ず確認を求めてください。
• 強制プッシュ、リモートの履歴の書き換え、リポジトリの公開設定の変更、または別のリポジトリへのプッシュ。
• 新しいサイトまたはプロジェクト、あるいはサイトのアクセス権、ドメイン、DNS の変更。ただし、タスクそのものがこれに該当し、ユーザーが依頼した場合を除きます。
• 権限チェックによってデプロイ、ロールバック、アップロードがブロックされた場合：中止してください。別の方法や別のスレッドで再試行してはいけません。ユーザーに正確なクリック手順またはコマンドを伝えてください。
• 公開後にサイトが壊れている場合：計測した証拠とロールバックのクリック手順を添えて、レポートの最初に報告してください。埋もれさせてはいけません。

ガードレール：絶対にしないこと

• クリーンな origin/main 以外は絶対に公開しないでください。マージされていないブランチや、未コミットのファイルを公開してはいけません。
• Netlify への大容量メディアのデプロイを代替手段として使ってはいけません。メディアは Supabase Storage に保存します。
• プロジェクトが廃止したホストには絶対に公開しないでください。古いスクリプトがそのホストを参照していても同様です。
• 広範囲にわたる画像オプティマイザー（pnpm images:optimize または optimize-images.py --apply）は絶対に実行しないでください。他のセッションで保留中の画像を書き換えてしまいます。runtime-assets.py --only '<your glob>' を使い、その後 --verify を実行してください。
• 認証情報、.env*、node_modules、キャッシュ、ビルド出力を絶対にステージしないでください。共有チェックアウトでは git add -A も使ってはいけません。
• リモートまたはドメインで確認するまでは、ローカルコミットをプッシュ済み、デプロイを公開済みと呼んではいけません。
• 自分が開始していないプロセスを絶対に終了しないでください。まず作業フォルダーを確認してください：lsof -a -p <pid> -d cwd

手順

0. 作業を始める前に

• git fetch を実行し、続けて git log origin/main --oneline -30 を実行して、自分の担当範囲を検索します。隣接するワークツリー（git -C <wt> diff --stat）も確認し、同じ編集をすでに進めている人がいないか調べます。
• origin/main から分岐したブランチを作り、自分のワークツリーで作業します。他のセッションは共有チェックアウトをリアルタイムで編集しています。

1. スクリーンショット

• プロジェクトのレビューフィクスチャ（?review=<name>）を使い、1600×900 で実際のゲームをキャプチャします。開始状態、重要な場面、結果を撮影します。
• プロジェクトでキャプチャツールが指定されている場合は、それを使います。指定されていない場合は、CDP 経由でヘッドレスキャプチャを行い（workflow-progress-screenshots スキルを参照）、使用したツールを報告します。
• 画像を使用する前に、すべて確認してください。余計なトースト、古い数値、誤ったシーンが含まれていたら、再キャプチャします。
• 内容を正確に示すラベルを付けます：ヘッドレスブラウザーでのキャプチャであり、スマートフォンサイズのビューポートは実機テストではありません。
• キャプチャスクリプトは、ワークツリーで Git 管理対象外の qa/captures/ に保存します。セッションのスクラッチパッドは再起動時に消去されます。

2. 変更履歴のバージョン

• プロジェクトの変更履歴のルールに従い、形式、バージョンの付け方、画像の追加方法を厳守します。
• プレイヤー向けに、今できることや画面で確認できることを記載し、ファイル名やハッシュは含めません。
• テスト、ツール、ドキュメント、ルールの変更にはバージョンを付けません。
• 別のセッションで自分のバージョン番号が使われていた場合は、マージ時に自分の番号を付け直し、相手の項目は残します。

3. 検証

• 変更に関係するテストスイートを、作業を進めながら実行します。
• main をマージした後は、取り込んだコミットが変更したテストファイルもすべて実行します：git diff --name-only <old-base> <new-base> -- tests。
• 画像を追加した場合は、画像の検証も実行します。
• 全テストスイートは、マシンが混み合っていると10～40分かかります。run_in_background を使って実行し、ログを確認します。タイムアウトに見える失敗は、実際の失敗と判断する前に単独で再実行します。
• どの実行が全件で、どれが対象を絞ったものかを、成功数と失敗数を添えて正直に報告します。

4. コミット

• 作業を始める前に、git diff --cached が空であることを確認します。
• ステージするのは明示したパスだけにします。
• ステージした変更に対して commit-size.sh を実行し、その数値を報告に記載します。
• まとまりのある変更ごとに1つのコミットを作成します。作業を続けている間は、小さなコミットを積み重ねず、単一の作業中コミットを amend します。
• リポジトリの慣例に沿ったメッセージを作成し、システムから指定された帰属表示の行で締めくくります。

5. マージとプッシュ

1. git fetch を実行し、その後 git rebase origin/main を実行します（共有ブランチでは merge）。

2. 競合は全員の変更を維持する形で解決します。生成された JSON（画像監査、マニフェスト）については、上流のファイルを採用し、自分の記録を再追加して、プロジェクトのツールで合計を再計算します。

3. src と tests のすべてのファイルに対して node --check を実行します。その後、自分のテストと、取り込んだコミットのテストを実行します。

4. push-main.sh：

   • fast-forward 以外の更新を拒否します。
   • パックサイズを測定し、50 MB を超えると停止します。
   • --progress を付けてプッシュし、Git の「Writing objects」行（送信バイト数）を出力します。
   • origin/main が HEAD と一致することを確認します。

   main が更新されていた場合は、手順1に戻ります。

5. プッシュしたコミットで全テストスイートを実行し、失敗した場合は修正して再度プッシュします。

6. 本番公開

• HEAD が正確に origin/main と一致し、追跡対象ファイルに変更がないチェックアウトでビルドします。
• ビルドによって追跡対象ファイルが変更された場合は、まずそのファイルをコミットしてプッシュし、その後に再度ビルドします。
• アップロード対象（upload-size.sh dist と、該当するメディアリリース）を測定します。50 MB を超える場合は停止して確認を求めます。
• まずドラフトまたはプレビュー URL にデプロイします。 verify-live.sh <draft-url> を実行し、ページ、そのスクリプトとアート、ゲートのルートを検証します。検証に合格した場合のみ本番に昇格します。この手順が設けられたのは、以前、本番デプロイでエッジ関数が含まれず、ページは表示されるもののすべての画像が404となり、誰もプレイできなかったためです。
• 昇格後、実際のドメインで verify-live.sh を実行します。デプロイ ID、公開時刻、公開中のゲームバージョン、送信バイト数を記録します。
• 別のセッションが先に公開していても、そのセッションが main も公開していれば問題ありません。

レポート

次の順に、簡潔に記載します。

1. プッシュされ、確認済みのコミットハッシュ。コミットサイズ：ファイル数、合計サイズ、最大のファイル。プッシュサイズ：送信バイト数。
2. 公開情報：URL、デプロイ ID、時刻、公開中のバージョン、verify-live.sh の結果。アップロードサイズ：送信バイト数、ビルド済みサイトのサイズ、メディアリリースがあればその内容。公開していない場合は理由を記載します（例：「保留：50 MB を超えるメディアリリースが必要なため、確認中」）。
3. プレイヤー向けの変更内容と、変更履歴のバージョンおよびタイトル。
4. テスト：全件実行と対象を絞った実行の区別、成功数と失敗数。
5. スクリーンショットとキャプション。「ヘッドレスキャプチャ」と明記します。
6. 先送りした事項や手順から外れた点があれば、その内容と理由。