bounded-deploy

Bounded のデプロイ

このスキルを使用して、Bounded アプリを初期化、公開、設定、共有します。 ポリシーの作成は bounded-backend で行い、クライアントコードとアプリユーザーの認証は bounded-frontend で行います。

デフォルトのワークフロー

新規プロジェクトや通常のリリースでは、 docs/quickstart.md を読んでください。想定される手順は次のとおりです。

bounded init
bounded deploy --create --name my-app

bounded init は保存済みのウェブセッションを再利用するか、ホストされたブラウザーログインを開きます。 公開用の bounded.json（"sourcePush": true を含むため、デプロイ時にプロジェクトのソースが同期されます）と policy.json を書き込みます。認証情報をいずれかのファイルに保存してはいけません。

タスク別の参照先

現在のタスクに必要なリファレンスだけを読んでください。

タスク	参照先
初回セットアップ、通常のデプロイ、サイトの公開、1 つのプロジェクトから複数のアプリ ID を使用する	docs/quickstart.md
通常のウェブアカウントへのログイン、セッションの更新、ヘッドレス OTP、アカウントの切り替え	docs/accounts.md
ホスト型ウェブフロントエンド、プレビュー、プライベート／パブリックアクセス	frontend-hosting.md
マルチ環境ポリシー：環境ごとのアプリ ID、定数、スケジュール間隔、関数のスコープ設定	docs/environments.md
プロンプトからのアプリ構築、edit による反復、実行の監視／キャンセル／承認	docs/cli-reference.md（プロンプト駆動のビルド）
ソースの同期、--with-source、クローン、プル	docs/source-sync.md
既存のアプリ（Supabase、Firebase、Express、Next、キーを保持するバックエンド）を Bounded に移行し、ルール、関数、スケジュール、ケイパビリティのどれにするか判断する	docs/porting-an-existing-app.md
サードパーティ API の検索、利用準備状況、リクエスト：bounded services search/describe/request/status	docs/cli-reference.md（ケイパビリティ）
oApp の公開に必要なチェックのドライラン：bounded oapp preflight	docs/cli-reference.md（Open Apps）
カスタムドメインとバニティスラッグ	docs/domains.md
共有、アクセス、所有者の不一致、401／403	docs/access-playbook.md
アプリの完全削除（ブラウザーでの確認が必要。所有者のみ）	docs/cli-reference.md（apps delete）
あまり使わないコマンドや正確なフラグの確認	docs/cli-reference.md
ローカル署名キー、プロファイル、CI キー認証、旧式のキー所有アプリ	docs/key-and-account-safety.md

通常のオンボーディングでは、ローカルキーのリファレンスを読み込まないでください。 ローカル署名、CI キー認証、アカウントプロファイル、または既存のキー所有アプリの復旧を明示的に希望するユーザー向けの高度な代替手段です。

インシデントの振り分け

• deploy_in_progress、operationId、または recoveryCommand がある場合は、所有者に表示されたリカバリーコマンドを入力を変更せずにそのまま使用し、その後 CLI にポーリングさせてください。 デプロイのリカバリーを参照してください。
• code／state があるエラーで recoveryCommand がない場合、その操作は終端状態です。410 policy_operation_unrecoverable、および abandoned、superseded、target-mismatch、manual-intervention の状態が該当します。リカバリーを再実行しても、確定させることはできません。新しい bounded deploy を実行するか、メッセージにオペレーターによる確認が必要と記載されている場合はエスカレーションしてください。これらに対するリカバリーコマンドを決して作り出さないでください。
• onchain_creation_pending、onchain_creation_unreadable、または onchain_creation_superseded（すべて 409）の場合、アプリのメインネット上での作成は完了していません。オンチェーン上の所有者はまだ finalized であると証明されていないため、そこには何もデプロイできず、署名も支払いも行われていません。 そのアプリ ID に対して、同じ bounded deploy を再実行してください。アカウントが finalized になると、プラットフォームは元の作成処理を再開し、すぐに制限を解除します。 --create を再実行したり、代わりのアプリを作成したりしないでください。最初のアプリのオンチェーンアカウントの費用はすでに支払い済みであり、2 つ目を作成すると、その費用が無駄になります。
• onchain_creation_owner_conflict（409）の場合、アプリのオンチェーンアカウントは、作成時に指定されていないウォレットのもとで finalized になっています。これは整合性の障害であり、再試行すべき状態ではありません。オペレーターによる確認のためエスカレーションしてください。
• どれが該当するか、または新しいデプロイが安全かどうか判断できない場合は、まず読み取り専用の bounded deploy status --json を実行してください。デプロイ枠を占有しているものと freshDeploySafe の判定が表示され、何も変更されません。
• デプロイの前に、デプロイが成功するか（枠が空いているかどうかだけでなく）確認するには、読み取り専用の bounded deploy preflight --json を実行してください。デプロイにはアプリのクレジット残高が使用されます。各処理の実際の Cloudflare インフラコスト（1 セント未満。ティアごとのデプロイ上限なし、最低額なし）が請求されるため、クレジット不足のアプリは拒否されます。Preflight はクレジット残高と would_likely_admit/refuse/unknown の判定を表示するため、デプロイに時間を費やす前に、ユーザーに「これは成功します」または「先にチャージしてください」と伝えられます。何も変更されません。
• site deploy で 402 deploy_credit_insufficient が発生した場合、原因は請求であり、ID ではありません。デプロイするアカウントに、デプロイのインフラコストを賄える利用可能なクレジットがありません。bounded billing status を実行し、bounded billing topup --credits <n> でクレジットを追加してから、同じ ID で再試行してください。アカウントを切り替えても解決しません。
• DNS を設定してもカスタムドメインが保留中の場合は、bounded domains list --app-id <id> --env <environment> --json を再実行して、ステータスを更新し、アクティベーションの状態を同期してください。 DNS を確認し、ドメインに記載されている、制限付きの再試行／エスカレーション手順に従ってください。 一覧表示では通常、プロバイダーによる検証は再開されません。プロバイダーのダッシュボード上の手順を、公開 CLI ワークフローの代わりに使用しないでください。
• site_control_denied（403）、所有者の不一致、または想定外の 401／403 が発生した場合は、ID を変更する前に bounded whoami と bounded access --app-id <id> を実行してください。 アクセス対応手順を参照してください。
• project_daily_limit_exceeded（429）の場合、Free アカウントでは、ローリング 24 時間あたり 20 個のアプリを作成できますが、このアカウントは上限に達しています。limit と resetsAtMs（および Retry-After）を確認し、次に作成可能となる時刻をユーザーに伝えてください。それまで待つか、ユーザーが承認した既存のアプリを再利用してください。アップグレードすると上限はなくなりますが、アプリを削除しても上限は戻りません。アプリを自動的に削除したり、別の用途に転用したりしないでください。請求を参照してください。
• boundary_violation の場合、アカウントを変更してもアプリの境界は回避できません。アクセス対応手順の境界ロックのセクションを使用してください。

リリースルール

• 既存のアプリでは、まず bounded.json を読みます。
• bounded.json が指定する policy.json がデプロイ対象です。 生成スクリプトを実行する前に、その出力をコミット済みのファイルと比較してください。意図していない変更や削除が含まれている場合、ジェネレーターは古くなっています。更新するか削除し、その出力をデプロイしないでください。
• bounded deploy はポリシーを検証してコンパイルし、変更を加える前に無効なポリシーを拒否します。別途、証明の手順を行う必要はありません。
• リリースに不可欠なデプロイの後、動作を測定する前に bounded apps inspect --app-id <id> --json を使って、アクティブなポリシーと ランタイムへの公開を確認します。
• 正確なサイトのレシート、または bounded domains list --app-id <id> --env <environment> --json からホスト URL を特定します。ホスト名を推測してはいけません。
• 次のコマンドでコントロールプレーンへのアクセスを共有します。 bounded share <email-or-wallet> --role admin|developer|viewer|billing
• 認証情報、ウェブセッション、リフレッシュトークン、プロバイダーのシークレットをコミットしないでください。