Ship Cloudflare Sites v1.1
リポジトリの証拠とユーザーが要求したスコープに基づいて操作します。デプロイのリクエストは、指定された環境に対する通常のデプロイワークフローを許可するものとします。破壊的、不可逆的、または実質的に広範な変更が必要になる場合にのみ質問してください。環境が指定されていない場合、本番ターゲットを推測しないでください。
プロジェクトを発見する
- リポジトリの指示を読み、編集前に現在のワークツリーを検査します。
scripts/audit-cloudflare-project.sh <project-root>を実行し、報告されたすべてのブロッカーを検査します。- フレームワーク、パッケージマネージャー、アダプター、Workerエントリ、Wrangler設定、環境、バインディング、マイグレーション、ドメイン、CIパス、シークレット名をファイルから解決します。メモリからは解決しないでください。
- リポジトリで固定されたCLIを使用します。リモート変更を行う前に、変更可能なCloudflare/OpenNextの動作をローカルの
--helpと現在の公式ドキュメントで確認します。 - 関連する参照のみを読みます：
- リリース、ロールバック、またはバージョン反復については references/release-workflow.md を読みます。
- D1、R2、シークレット、ドメイン、キャッシュ、環境、または可観測性のプロビジョニングまたは変更については references/cloudflare-resources.md を読みます。
操作モードを選択する
- 監査/計画: 読み取り専用のままにします。証拠、ブロッカー、リスク、正確な次のアクションを返します。
- 開発/設定: ローカルで編集し検証します。ユーザーがプロビジョニングを要求した場合、またはデプロイに必要な場合にのみ、リモートリソースを作成します。
- プロビジョニング: アカウント、ゾーン、環境、名前、意図された所有権を確認します。不足しているリソースのみを作成し、返されたIDを選択した設定に永続化します。
- リリース: 一度ビルドし、その検証済みアーティファクトをデプロイします。低リスクのリリースには直接デプロイを使用し、リスクが高い、または明示的に段階的なリリースにはバージョンアップロードと制御されたプロモーションを使用します。
- 復旧: 正常に動作していたWorkerバージョンを選択し、D1とR2の状態は別々に処理します。Workerバージョンにはストレージの状態は含まれません。
不変の安全策を適用する
- ローカル、プレビュー/ステージング、本番リソースを区別します。すべてのリモートコマンドのターゲットを明示します。
- シークレット値をソース、出力、スクリーンショット、シェル引数から除外します。名前と存在のみを報告します。
- リリース前にダーティワークツリーを確認します。無関係なユーザーの変更を破棄、コミット、または出荷しないでください。
- D1の変更は順序付きマイグレーションとしてモデル化し、リリース全体でexpand/backfill/contractを優先します。
- 長期キャッシュアセットにはイミュータブルまたはバージョン管理されたR2キーを使用します。上書き、削除、CORS変更、キャッシュパージは1つの調整された変更として扱います。
- WorkerカスタムドメインとR2カスタムドメインは別々のリソースとして扱います。APEX、
www、正規リダイレクト、証明書、アセットホスト名を個別に検証します。 - アップロードを成功したリリースと呼んではいけません。公開ホスト名、重要なルート、D1バックアップの動作、代表的なR2オブジェクト、デプロイ後ログを検証します。
リリースレコードを作成する
以下を返します：
- リリースID、Gitコミット、環境、Workerおよびストレージリソース名；
- 出荷されたソース/設定変更と除外されたワークツリー変更；
- ローカルゲートとその結果；
- D1マイグレーションと復旧ブックマーク/エクスポートおよび互換性順序；
- R2/ドメイン/キャッシュ/シークレットの変更（シークレット値なし）；
- Workerバージョン/デプロイIDとトラフィック割合（利用可能な場合）；
- スモークテストURLと結果；
- ロールバックターゲット、ストレージに関する注意事項、残りの手動アクション。
ゲートに失敗した場合、安全でない境界の前で停止し、証拠を保持し、残っている内容を述べてください。ゲートを黙って弱めてはいけません。