ファイルストレージ

メソッド	パス	説明
GET	`/v1/orgs/{orgSlug}/projects/{projectName}/storage`	オブジェクトストレージのステータス（`runlot storage usage`）
POST	`/v1/orgs/{orgSlug}/projects/{projectName}/storage`	ストレージを付与する（`runlot deploy` が `\\"storage\\": true` という宣言を読み取ったときに呼び出されます）
DELETE	`/v1/orgs/{orgSlug}/projects/{projectName}/storage`	ストレージ使用量のプロビジョニングを解除する（`runlot storage delete`）

GET `/v1/orgs/{orgSlug}/projects/{projectName}/storage`

有効かどうか、prefix、quota、usage（docs/storage.md §7、§8）。usedBytes はノードが報告した最後の観測値であるため、レポート間隔分の遅延があります — その間にクォータをわずかに超過する可能性があります。

オブジェクトの一覧表示と署名付き URL はこの API の対象外です。認証情報は node-agent（§4.1）にのみ存在し、バイトを CP に二重送信しないことは §5 での決定です。

viewer以上です。

operationId getStorage

これは冪等です — 2 回呼び出しても prefix は変わりません。もしリトライで prefix が変わってしまうと、その prefix の下にすでに保存されているすべてのオブジェクトが見えなくなり、その損失はすぐには表面化しません。

リクエストボディはありません。prefix は分離境界であり（docs/storage.md §4.4）、quota はプランによって設定されるため（§4.5）、どちらもユーザーが設定する値ではありません。

有効化すると、ノードは次の収束時に env.storage を worker に接続します。env.db と同様に、再デプロイは不要です。

member 以上。storage.grant として監査されます。

operationId grantStorage

オブジェクトは削除されません。 prefix 配下のすべてを削除するには op_id によって冪等な CP 操作である必要があり（docs/storage.md §7、データベース削除と同じレーン）、そのレーンはまだ存在しません — この事実は監査ログに記録されます。

無効化も冪等です。ストレージが有効化されていなかった場合でも 204 を返します。

admin 以上 — 課金は停止しますが、オブジェクトは孤立するため、デプロイメントのロールバックと同じレベルでは扱われません。storage.revoke として監査されます。

operationId revokeStorage