bounded-backend

Bounded バックエンド

Bounded アプリのサーバー側です。文書化されたサポート対象の変更サーフェスを管理するポリシー、ランタイムで強制される不変条件、信頼されたコードを実行する関数、そして誰が操作しているかを判断するアクターモデルで構成されます。 bounded deploy は検証、コンパイル、プッシュを行います。ランタイムのルールチェックと不変条件チェックは、文書化されたサポート対象の変更サーフェスでの違反をコミット前に拒否します。具体的なポリシーテスト（bounded tests run）とデプロイで、ポリシーを確認してください。このカバレッジを、サポート対象外の領域、文書化されていないストレージパス、または継承されたコーパスに一般化しないでください。CLI／デプロイについては bounded-deploy スキルを、クライアント SDK と認証 UI については bounded-frontend を参照してください。ファミリー内の適切なスキルを選ぶには、ルートの bounded スキルを参照してください。

最初からアクターモデルを意識して記述してください。ルールを書く前に、@user が誰なのか、関数がどのプリンシパルとして動作するのか（runAs／actAs）、認可がどこから得られるのか（@origin）を把握してください。

リファレンスルーター

最も一般的な5つのアプリの形のいずれかを構築していますか？この表を順に読むのではなく、クイックパス（ビルドごとに対象ページは1つ）をご利用ください。それ以外の場合は、現在のタスクまたは用語に一致する行だけを読んでください。

タスクまたは用語	参照先
1画面で確認できる構文：フィールド型、階層、変数、演算子、ロジックの記述場所	ポリシーのチートシート
アプリの説明からポリシーを生成または修正する	ポリシーの生成
意図別のポリシーの完全な例（マーケットプレイス、エスクロー、Vault、ステーキング、トークンなど）	例のインデックス
複数コレクションにまたがるポリシーの実例（チーム向けSaaS、マーケットプレイス、リアルタイムゲーム）	例
ルールのレシピ：所有者のみ、管理者または所有者、メンバーシップ、時間枠、検証、不変フィールド、アトミックなバッチ	アクセスパターン
ルールでユーザーの検証済みXアカウントを必須にする、またはコピーする方法、get(/__connections__/@user.id).xHandle、X連携ルールのテスト、連携前に入力されたハンドル、オンチェーンアプリ	連携アカウント
ルール、フィールド、式、@user、@data、@newData、@time、get()、getAfter()、所有権フィールド	ポリシーリファレンス
上限、残高、供給量、テナントの分離、厳密な境界値；rollingSum、windowSum、flowBound、conserve、tenantTag、tenantEdge、bound	不変条件
トレンドフィード、リーダーボード、順位付けされたwindowSum読み取り	トレンドフィード
ブラウザーのCSP／アプリのページからアクセスできる対象を制限する	ブラウザー境界
定数、再利用可能なルール、@const、@def	定数と定義
ルール、不変条件、フック、関数の使い分け	関数を使うタイミング
関数；宣言、auth、entry、secrets、actAs、ctx.user、ctx.bounded、ctx.env、ctx.secrets、呼び出し、デプロイ	関数
パブリック関数：<slug>-api.bounded.pageにある、Boundedセッション不要のHTTPルート、public、methods、cors、パブリックJWKS、マシンクライアント、Webhookモードとブラウザーパブリックモード	パブリック関数
ctx.ai.run、ctx.ai.generateImage、ctx.ai.generateVideo、getJob、APIキー不要のAI	ctx.ai
ctx.services、管理対象のサードパーティAPI、bounded services	ctx.services
ctx.browser、関数からのヘッドレスブラウザー、サインインした状態で独自アプリを操作する方法、@const.AGENT、エージェントのID	ctx.browser
ctx.enqueue、バックグラウンドジョブ、キュー、リプレイ時のID	ctx.enqueue
ctx.build、管理対象のアプリビルドを開始する関数、画像と動画のビルド、mediaSlots	ctx.build
シンプルに始めて、段階的に関数へ移行する	関数への移行
ユーザー所有のプロバイダーAPIキー	シークレット
スケジュール、dueRows、フック、Webhook、verifyWebhook	スケジュール済みフックとWebhook
全件スキャンを行わない定期的なフリート処理	スケジュール済みスイープ
不正防止の証明制限	フックと不正防止
アトミックな書き込み、サブセット攻撃、requiresInBatch、incomplete_batch	データプレーン
クエリ、ページネーション、queryAggregate、count、フィルター、欠損とnullの違い、$exists、ソート、カーソル	クエリ
ファイル、setFile、ストレージ、全文検索	ファイルと検索
リアルタイムルーム；session.tick、settleTo、settleFrom、戦場の霧ビュー	リアルタイムとゲーム
ネイティブのライブモジュール；session.live、tick、views、@effect、live.intent	ライブランタイム
入力頻度、補間、予測	リアルタイムのネットコード
AI NPC／AIプレイヤー	AI NPC
長時間稼働するバックエンドランタイムまたはマネージドサービス	バックエンドランタイム
複数ステップのFlueエージェント	Flueエージェント
所有者、共同作業者、スコープ付き管理者	管理者と所有権
トップレベルのroles、members、read:"*"、読み取り／書き込みスコープ	ロール
access、カスタム／外部ロール、__owners__、__admins__、__developers__、__viewers__	アクセス制御 · IDとログ
サービスキー、支払いボット、バックエンドID、runAs、actAs、@origin、ctx.origin	サービスキー · プリンシパルとオリジン
許可／拒否の具体的なテスト；policy-tests/*.json、bounded tests run/push/list/pull	ポリシーテスト
認証済みアプリのエンドツーエンドテスト	認証済みアプリのテスト
完了時のレビュー	品質チェックリスト
エージェント向けまたはバックエンド専用のアプリ	エージェント向けの開発 · バックエンドの構築

エラールーター

エラー／ステータス	意味
403	書き込みまたは関数の呼び出しがルールによって失敗しました。認証、所有権、ロール、または関数の auth を確認してください。拒否された読み取りは 403 ではなく、データが空の 200 として隠されます。
500 rule_evaluation_failed	ルールに到達しましたが、評価できませんでした。ルールによって拒否されたわけではなく、読み取りも書き込みも行われていません。拒否でも、再試行可能な競合でもありません。原因については bounded decisions を参照してください。行には decision: error が記録されます。
409 ＋ 不変条件名	トランザクションが不変条件に違反する可能性があります。状態またはポリシーを修正してください。
403 incomplete_batch	コレクションの requiresInBatch 宣言で指定されている関連パスが、アトミックなバッチに含まれていません。完全な setMany を送信してください。
デプロイ検証エラー	変更が行われる前に、ポリシーのデプロイが拒否されました。メッセージで示されたポリシー構文、フィールド型、ティア／不変条件の組み合わせ、定数、または式の使用を修正してください。

基本方針

• 通常の所有権やメンバーシップの確認には @user.id を使用し、ウォレット／オンチェーンのセマンティクスに限り @user.address を使用してください。

• 拒否された読み取りは空の 200 レスポンスを返します。ポリシーテストの expect 内の get() は、読み取りルールをスキップしてサンドボックスの状態を読み取るため、読み取りの拒否を実証するには、もう一つの実セッションを使用してください。書き込みや削除の拒否は shouldFail のままにしてください。

• 固定合計には conserve、一定期間の上限には rollingSum、パーティションごとの累積流出量を流入量以下に制限するには flowBound を使用してください。正しさが複数の書き込みにまたがる場合は、アトミックな set-many を一つ使用してください。

• 関連する書き込みがないと無効になる書き込みについては、悪意のあるクライアントが個別には有効なサブセットだけを送信できないよう、requiresInBatch を宣言してください。

• プロバイダーの API キーはフロントエンドのコードではなく、Bounded のシークレットに保存してください。

• ルールを記述する前に、実行主体を把握してください。関数の runAs／actAs と @origin によって、@user が誰になるか、呼び出しが認可されるかが決まります。

• 認証が必要なアプリのアクションには、クライアント SDK の functions.invoke を使用し、関数の認証ルールを宣言して、ctx.user を使用してください。関数の引数として Bounded のセッショントークンを送信したり、公開 HTTP 関数内に JWT 検証機能を構築したりしないでください。今日のプロンプトなど、意図的に公開するデータは、ユーザー状態にアクセスしない別の公開関数に置いてください。

• 非所有者ユーザーとして、プライベート関数のフローを検証してください。アプリでゲストに対応している場合は、匿名セッションも含めてください。状態を保存し、再読み込みしてから再開してください。所有者の CLI 呼び出しでは、データ読み取り権限の失敗が見えなくなることがあります。読み取りが拒否されると、データが存在しないように見える場合があるため、状態を再作成したりルールを緩和したりする前に、認可を調査してください。