ダッシュボード API

招待を消費せずに検査します。サインアップや検証状態は報告しません。ただし、サインインリセットは replaces_unverified_account を報告します。organization_admin または organization_member の招待は、組織名を報告し、プロジェクトは報告しません。

招待ダイジェストとモードに紐づく5分間の登録セレモニーを開始します。リンク create_login は検証済みの __Host-screenrig-signup クッキーを必要とし、その名前を使用します。

メール create_login は提供された表示名を紐づけ、リセットは対象のユーザーを紐づけます。ただし、未検証のアドレスのリセットでは、それが作成する新しいユーザーのパスキーを登録し、そのユーザーの名前は提供された表示名、省略した場合はアドレスから付けられます。

そのリセットには replace_unverified_account を true にする必要があります（検査で replaces_unverified_account が報告されます）。指定しない場合は 409 unverified_account_replacement を返します。

ブラウザバウンドリンクのサインアップを開始し、この招待の以前のサインアップを取り消します。検証チャレンジはこのサインアップに紐づきます。開発認証はメールなしで即座にサインアップを検証します。

このブラウザーに属するライブサインアップを返します。サインアップCookieが欠落、取り消し、使用済み、または期限切れの場合はinvitation_invalidを返します。

招待をトランザクション的に承諾し、新しいユーザーセッションを発行し、既存のセッションがあれば削除します。

リンク create_login には、この招待に対して検証済みの __Host-screenrig-signup クッキーが必要です。signed_in にはダッシュボードセッションと最近のサインインまたは新しい証明が必要です。メール配信には、一致する検証済みメール、またはサインイン中のユーザーの未検証アドレスが必要で、承諾するとそのアドレスが検証されます。

有効なユーザーがすでに保持しているアドレスは、検証済みかどうかにかかわらず、create_login に対して resource_conflict を返します。リセットは、検証済みアドレスを保持するユーザーをサインインさせます。

未検証のアドレスのリセットには replace_unverified_account を true にする必要があります（検査で replaces_unverified_account が報告されます）。指定しない場合は 409 unverified_account_replacement を返し、何も消費しません。指定した場合、リセットは、登録された認証情報を持つ新しい検証済みユーザーを作成し（名前は display_name、省略した場合はアドレスから付けます）、新しい組織とプロジェクトを用意して、そのユーザーをサインインさせます。未検証のユーザーは削除され（そのセッション、パスキー、エージェントは終了します）、そのユーザーが作成したプロジェクトと組織は、そのユーザーを除いた状態で残ります。これらのプロジェクトの連絡先アドレスはそのアドレスと一致しなくなるため、以降のリセットで登録の招待が再送されることはありません。

レスポンスには新しいプロジェクトが示されます。メールアドレスの検証が必要なセッション（GET /api/session の email_verification_required）は、自身のアドレス宛てにメールで送られた招待のみを受け付け、それ以外には 403 email_verification_required を受け取ります。

organization_admin の招待は、ユーザーを組織の管理者に追加し、プロジェクトは開きません。組織にすでに 20 人の管理者がいる場合は organization_admin_limit を返して未処理のままとなり、組織が削除されている場合は resource_conflict を返します。

organization_member 招待は、以前のホーム組織があってもそれに代えて、ユーザーのホーム組織を招待した組織に設定し、プロジェクトメンバーシップは付与しません。別の組織がユーザーを管理している場合は managed_elsewhere（409）を、組織が削除されている場合は resource_conflict を返します。

organization_admin 招待は、ホーム組織を持たないユーザーに対してのみホーム組織を設定します。project_member 招待は組織のゲストポリシーを再チェックし、ポリシーが拒否する外部ゲストとなるユーザーには guest_not_allowed（403）を返します。プロジェクト招待が誰かのホーム組織を変更することはありません。拒否された招待は未処理のままです。

セルフサービスのサインアップ用に、5分間の登録セレモニーを開始します。セレモニーは正規化されたメールアドレスと表示名に紐づきます。何も作成せず、メールも送信しません。

有効なユーザーが保持しているアドレスは、検証済みかどうかにかかわらず 409 account_exists を返します。組織が ID プロバイダー経由でサインインするドメインのアドレスは 403 sso_required を返します。無効なアドレスまたは名前は、フィールドエラー付きの 400 invalid_request を返します。ダッシュボード開発認証を実行しているサーバーは passkeys_disabled を返します。

クライアントアドレスごとに制限されます。

セルフサービスのアカウントを作成し、このブラウザーでサインインします。

1つのトランザクションで、未検証のメールアドレスと72時間後の検証期限を持つユーザーを作成し、POST /api/signups/passkey-options が開始したセレモニーのパスキーを登録し、エージェント登録が作成するのと同じ方法でユーザーの組織とプロジェクトを作成し、ユーザーをプロジェクトのオーナーにし、マーケティングメールの選択を保存し、検証メールをキューに入れます（purpose は account_email）。

ページを開いたウェブサイト訪問者がアカウントに関連付けられ、サインアップは signed_up として計上されます。レスポンスはダッシュボードのセッションクッキーを設定します。拒否の条件は POST /api/signups/passkey-options と同じです。使用済み、期限切れ、または一致しないセレモニーは 400 invalid_request を返します。クライアントアドレスごと、およびメールアドレスごとに制限されます。

ユーザーのプロジェクトの1つに切り替え、最終使用時間を更新します。スタッフはシャドウしているプロジェクトに切り替えることもできます。そのセッションはshadow true、読み取り専用で最終使用時間を更新しません。他のプロジェクトはnot_foundを返します。

現在のプロジェクトのメンバーをプライベートメールアドレスなしで一覧表示

メンバー管理（削除、承認者、スコープ、所有権）を除き、すべてのメンバーは同等の権限を持ちます。メンバー管理は、オーナーと、メンバーでもあるプロジェクトの組織の管理者に属します。owner はプロジェクトオーナーを、external はゲスト（メンバーのホーム組織がプロジェクトの組織ではない）を示し、viewer_user_id と viewer_is_owner はサインインしているユーザーを示します。

現在のプロジェクトからメンバーを削除します。プロジェクトオーナーは他のメンバーを削除でき、メンバーでもあるプロジェクトの組織の管理者も同様です。メンバーは自分自身を削除して退出できます。オーナーは削除も退出もしません（owner_cannot_leave。まず所有権を移譲してください）。他のメンバーを削除しようとする人は owner_required で拒否されます。

メンバーでないユーザー（すでに削除された人を含む）は not_found です。1つのトランザクションでメンバーシップが終了し、そのユーザーのプロジェクトへの未処理のメール招待が取り消され、プロジェクトイベント member.removed が追加されます（詳細は user_id、removed_by_user_id、left）。

ユーザーのセッションは次のリクエストでプロジェクトの解決を停止し、プロジェクト削除後と同様にフォールバックします。エージェントのメンバーシップは別であり、残ります。対象は人のみで、ベアラールートはありません。

現在のプロジェクトにおける1人の活動、最新順：サインイン（拒否されたサインインはアドレスまたはパスキー名付き）、サインアウト、プロジェクト切替、資格変更、再認証証明、ダッシュボード経由のすべての変更（拒否・失敗含む）。閲覧は記録されません。

AgentおよびCLIリクエストはそれぞれのエージェント上で処理されます（listDashboardAgentEvents）。スタッフのプロジェクトシャドウは記録を残さず、承認されたスタッフ書き込みリース下での変更はスタッフの行として記録されます。

その人自身、プロジェクトのオーナー、プロジェクト組織の管理者、プロジェクトを監視するスタッフメンバーのみが閲覧できます。その他はnot_foundで応答され、メンバーでない人やここに行がない人も同様で、誰が所属しているかは回答されません。元メンバーの行は読み取り可能なままです。

プロジェクトはセッションのものであり、リクエストのものではありません。常にそのプロジェクトの行のみが返されます。

すべての値はサーバー由来です：サーバーが一致させたルートのアクション（またはsession.sign_inやpasskey.addなどの名前付きアカウントアクション）、サーバー発行識別子の場合はルートの最初のパス値からのリソース、問題レジストリからのstatus、problem_code、error、User-Agentとプラットフォームヒントから解析されたクライアント（生のUser-Agentは保持しません）。

リクエストボディ、パスワード、トークン、クッキーは保存されません。client_ip と email は記録されたまま表示されます。

ページングキーは(at, id)降順です。続行するにはnext_cursorをafterとして渡します。終わりではnullです。書き込み中の行は最初のページの前にのみ入り、保持は最古の行を削除するため、カーソルは生存行を繰り返したりスキップしたりしません。不正なカーソルやフィルターはinvalid_requestで拒否されます。limitは1〜100のデフォルトです。

行は書き込まれた時点のプロジェクトのイベント保持期間で期限切れになります。recorded_since はプロジェクトの最古の生存行の時刻、またはそれ以前はこのサーバーの記録開始時刻です；それ以前は再構築されません。

サインインした人のプロフィールと資格カウントを返します。

サインインしているユーザーをトゥームストーンします。証明保護済み：本文には新しいサインイン証明が含まれ、これはPOST /api/me/reauthenticationsで開始されるaccount_delete種別とサインインユーザーIDと等しいsubject_idにバインドされた再認証で検証されます。現在の再認証がない場合はreauthentication_requiredを返します。

成功するとレスポンスは204で、ダッシュボードのセッションクッキーがクリアされ、サインアウト時と同様にブラウザのダッシュボードオリジンのHTTPキャッシュもクリアされます。

セッション、種類、対象に紐づくパスキー昇格を開始します。パスキーを持たない人物は resource_conflict を受け取り、パスワード証明を使用します。

新しい証明後にパスワードを設定または置換します。最初のパスワードはパスキー証明が必要で、置換は現在のパスワードまたはパスキーを受け入れます。他のセッションを取り消し、サインイン変更通知をキューに入れます。

メールアドレスが未検証のユーザー（検証前のセルフサービスサインアップなど）はパスワードを設定できず、403 email_verification_required を受け取ります。

ユーザーのパスキーを一覧表示します。ブラウザーのパスワードマネージャーをそれらと同期した状態に保つためにクライアントが必要とする情報も含まれます（WebAuthn Signal API）。一覧には、パスキーの登録先であるリライングパーティ ID とユーザーハンドルが含まれ、各パスキーには、その認証情報 ID と、認証器が報告したプロバイダーが含まれます。

新しい証明を検証し、セッションとユーザーに紐づく登録を開始します。開発認証下ではパスキーは無効です。

新しいパスキーを保存し、ユーザーの他のセッションを取り消し、サインイン変更通知をキューに入れます。名前なしで送信されたパスキーには、そのプロバイダー名が付けられます。認証器が既知のプロバイダーを報告しなかった場合は Passkey になります。

サインイン中のユーザーが所有するパスキーの名前を変更します。

新しい証明後にパスキーを削除し、サインイン変更通知を送信します。最後のサインイン方法を削除するとlast_credentialが返されます。アカウントにパスキーが必要なユーザー（すべてのスタッフ）は最後のパスキーを削除できません。409 resource_conflictが返されます。

ユーザーの検証済みと保留中のメールの状態を返します。自分でサインアップしたユーザーは、メールで送られたリンクを開くまで未検証のアドレスを保持します。email_verified は false で、verify_by が期限です。期限を過ぎると、セッションはアドレスを検証または変更するルートのみ使用できます（GET /api/session の email_verification_required）。

新しい証明を使ってメールアドレスの変更を要求します。検証中は検証済みのアドレスが有効です。他の有効なユーザーが保持するアドレスは、検証済みかどうかにかかわらず user_email_conflict を返します。古いアドレスには警告が送信され、元に戻すリンクはありません。

アドレスが未検証のユーザーも同じ方法で変更します。新しいアドレスを検証すると、それがそのユーザーの検証済みアドレスになり、verify_by が解除されます。

新しい検証リンクをキューに入れます。メール変更が検証待ち（GET /api/me/email の pending_email）の間は、その変更のリンクとして保留中のアドレスに送信されます。それ以外の場合は、ユーザーの現在の未検証アドレス宛ての account_email リンクです。同じ種類の直前のリンクから10分以内は何もキューに入れず、それでも 202 を返します。

アドレスが検証済みで、保留中の変更がないユーザーには 409 resource_conflict が返されます。

サインアップ後にユーザーが答えた内容を、ここまでのすべての回答を含む本文で置き換えます。省略されたメンバーまたは null のメンバーは未回答です。各メンバーの値は閉じた集合で、その外の値はフィールドエラー付きの 400 invalid_request を返します。

プロフィールはユーザーとともに保存され、ユーザーがサインアップした組織とともに screenRIG スタッフに表示されます。

セッションのプロジェクトのアプリケーション（ウェブアプリ）が配置されている場所。プロジェクトのプレイリストを 1 回走査し、それらを保持するスクリーンを 1 回読み取って計算されます。placements は、保存されているアプリケーションオーナーがこのアプリケーションであるアプリケーションプリミティブで、プレイリスト（プレイリスト一覧の順序）、ページ、プリミティブの順に並びます。このアプリケーションを 2 回配置しているプレイリストには、配置が 2 つあります。release は、固定された各リリースがアプリケーションの latest_ready_release に対してどの状態にあるかを示します。latest、older、またはアプリケーションに latest_ready_release がない間は unknown です。screens は、配置のプレイリストのいずれかを、既定にしている、スケジュールしている、テイクオーバーに使っている、または現在表示している pairing_pending と active のスクリーンで、新しい順です。アーカイブ済みのスクリーンは数えません。Player がウェブアプリを表示できないスクリーンには applications_unsupported が付きます。

スクリーン（screen_scope）に限定されたメンバーまたはエージェントには、そのスクリーンだけが表示され、screen_count もそれらのスクリーンだけを数えます。これは削除を妨げる要因ではありません。削除を妨げるのはランタイム権限（スクリーンのマニフェストがリリースを保持していること）です。プロジェクトに存在しない ID は、getApplication と同様に not_found です。応答は private かつ no-store です。

セッションのプロジェクトの準備完了メディア項目が使用されている場所。プロジェクトのプレイリストを 1 回走査し、それらを保持するスクリーンを 1 回読み取って計算されます。playlists は、まずファイルを名前で指定しているもの（画像または動画プリミティブの静的 ID と、id または ids によるセレクター、ストリームのフォールバック、カードの params 内の media:<id> 文字列、スティンガーのロゴ、サウンドトラックのトラック）、次にタグ、フォルダー、all セレクターがそのファイルに該当するものの順で、各グループ内はプレイリスト一覧の順序です。プレイリストは 1 つのエントリーで、その uses に各方法が一覧され、ファイルを直接指定する種類が先に並びます。

セレクターは、ランタイムが解決するとおりに判定されます。タグフィルターはファイルの tag と tags に一致し、フォルダーセレクターはフォルダー直下のファイル、all セレクターはその種類のすべてのファイルに一致します。保留中のファイルは、最後に承認されたタグとフォルダーで判定されます（一度も承認されていないファイルは、どのセレクターにも該当しません）。

ローテーション（batch_size、one_at_a_time）、利用可能時間帯、アスペクト調整、ページの可視性は判定されません。screens は、それらのプレイリストのいずれかを、既定にしている、スケジュールしている、テイクオーバーに使っている、または現在表示している pairing_pending と active のスクリーンで、新しい順です。アーカイブ済みのスクリーンは数えません。

スクリーン（screen_scope）に限定されたメンバーまたはエージェントには、そのスクリーンだけが表示され、screen_count もそれらのスクリーンだけを数えます。プロジェクトに存在しない ID や、準備完了になっていないメディア項目は、getMedia と同様に not_found です。応答は private かつ no-store です。

セッションのプロジェクトが所有する準備済み画像の小さなロスのあるWebPを返します。ダッシュボードのグリッドは元画像をデコードしません。サイズは1つで、縦横比を保持し512×512内に収まり、拡大されません。アニメーション画像は最初のフレームを表示します。

最初のリクエストで生成し元の横に保存します。後のリクエストは保存されたコピーをストリームし、メディア削除で元と共に削除されます。別プロジェクトの識別子、ビデオ、オーディオ、準備できていないメディアはnot_foundを返します。Rangeは受け付けません。

ETag は強力で、オリジナルとサムネイル生成元を示すため、すべてのリクエストとホストで同じです。レスポンスはプライベートで no-cache、If-None-Match が一致し、メディアがセッションのプロジェクトで解決された後にチェックされ、サムネイルを読み込まずに 304 を返します。完了したバイト数は dashboard_media の送信として記録されます。

getDashboardMediaThumbnail と同じ所有権、条件、生成ルールを適用し、本文なしでヘッダーを返します。エグレスは記録されません。

スキャナー安全な検証ピーク。アドレスを検証せず、ユーザーを変更せず、訪問者をサインインさせません。リンクの目的と状態を報告します。保留中の account_email リンクは、ユーザーのダッシュボードセッションを伴うリクエストでのみ検証されるため、ページは確認を求める前にサインインを求めます。

明示的な人間の確認は、目的限定の検証チャレンジを1つ消費します。リンクサインアップのチャレンジには対応する __Host-screenrig-signup クッキーが必要です。メール変更のチャレンジはトークンに紐づくため、リンクはどのブラウザーでも動作します。

account_email チャレンジ（セルフサービスサインアップ時と POST /api/me/email/verification でメール送信され、30日間有効）は、どのブラウザーでも開けますが、リンクの宛先のユーザーの有効なダッシュボードセッションを伴うリクエストでのみ検証されます。email_verification_required によってこのルートのみに制限されたセッションも含まれます。

セッションがない場合、または別のユーザーのセッションの場合は、200 sign_in_required を返し、何も検証せず、リンクは使用可能なまま残ります。検証された account_email リンクは、ユーザーのアドレスを検証済みにして検証期限を終了します。別のユーザーが先に同じアドレスを検証していた場合は superseded を返します。検証によって訪問者がサインインすることはありません。

ユーザー名なしの WebAuthn 認証セレモニーを1回開始し、navigator.credentials.get 用のリクエストオプションをそのまま返します。クッキーは不要で、allowCredentials リストは公開されないため、ルートは存在するユーザーや認証情報について何も明かしません。セレモニーは DashboardCeremonyTTL の5分で期限切れになります。

サーバーがダッシュボード開発認証を実行している場合、このルートはpasskeys_disabledを返します。

ユーザー名なしのアサーションを1つ検証し、検出可能な認証情報が識別するユーザーのダッシュボードセッションCookieを発行します。リクエストの認証にCookieは不要です。未知、期限切れ、既使用の儀式はpasskey_invalidを返し、検証できないアサーションや逆行する署名カウンターも同様です。

有効なセレモニーで、その認証情報の識別子が誰にも登録されていない場合（どのユーザーにも、その識別子を持つ保存済みの認証情報がない場合）は、代わりに 401 passkey_unknown を返します。この応答はこの 1 つの場合にのみ返されるため、クライアントはこの応答に限り、ブラウザーにその認証情報を忘れさせることができます（PublicKeyCredential.signalUnknownCredential）。他の応答では行わないでください。

認証情報の識別子だけでは認可になりません。認可になるのは署名付きアサーションです。検証済みアドレスが、組織がシングルサインオンを必須としているドメインのものであるユーザーは、その組織のブレークグラス管理者でない限り、403 sso_required で拒否されます。そのブレークグラス管理者のサインインは監査されます。

サーバーがダッシュボード開発認証を実行している場合、このルートはpasskeys_disabledを返します。

検証済みのメールアドレスとパスワードで特定されたユーザーをサインインさせます。不明なメールアドレス、パスワードなし、誤ったパスワードは、いずれも同じ unauthorized 応答を返します。最後に使用したプロジェクトにメンバーシップが残っていればそれを開き、なければ最新のメンバーシップのプロジェクトを開きます。メンバーシップがない場合はプロジェクトなしです。

組織がシングルサインオンを必須としているドメインのアドレスは、アカウントを検索する前に 403 sso_required で拒否されるため、応答はそのアドレスを保持するユーザーがいるかどうかに依存しません。POST /api/sso/starts は、そのユーザーを ID プロバイダー経由でサインインさせます。

パスワードでのサインインには検証済みのメールが必要です。そのため、自分でサインアップしたユーザー（POST /api/signups）はパスキーでサインインし、未検証のアドレスにパスワードを設定したユーザーも unauthorized の応答を受け取ります。開発認証も同じパスワードフローを使用します。

現在のダッシュボードセッションを返します。セッションCookieとサーバー側セッションが権限を確立し、user_idは説明的です。401レスポンスはサインインが必要なことを意味します。

dev_auth フィールドはローカル開発用に予約されており、ホストサービスでは false です。organization はユーザーのホーム組織で、ホーム組織がない間は含まれません。project.organization_admin は、ユーザーが現在のプロジェクトの組織を管理していることを示します。

サーバー側のセッション行を削除し、セッションCookieを期限切れにします。ユーザーや認証情報は削除されません。これは本質的に冪等であり、Idempotency-Keyは不要です。

成功したサインアウトはブラウザのダッシュボードオリジンのHTTPキャッシュもクリアし、セッションが閲覧したプライベートでノーキャッシュのメディア、スクリーンショット、広告レビューのバイトを削除します。期限切れのみのセッションはブラウザが削除するまで保持します。

1 つのブラウザーによるダッシュボードのエントリーフロー（サインアップ、サインイン、リセット、招待、パスキーの追加）の実行について、1 つのステップを報告します。スタッフ向けのオンボーディング読み取りに使われます。公開エンドポイントで、ダッシュボードのセッションの有無にかかわらず動作します。

ジャーニーはブラウザー自身のランダムな ID です。リクエストがエッジの訪問者クッキーを持つ場合はそのクッキー、セッションを持つ場合はそのユーザーと組織も、サーバーが保持します。ジャーニーはスタッフ専用で、ユーザーが入力した実際の値（アドレス、名前、回答）を保持しますが、パスワード、コード、トークンは決して受け取りません。

mode、source、utm_source、utm_medium、utm_campaign、click_kind、site_trail、site_cta は最初の値が保持されます。各ステップは最初の時刻を保持し、ステップの value、detail、およびジャーニーの email（email_submitted から取得）は最新の値になります。source は entry_viewed でのみ受け付けられます。question は question_* ステップでは必須で、それ以外のステップでは拒否されます。detail は、*_failed ステップでは問題コード、signed_in ではサインイン方法、signup_finished では connected または skipped です。email_verified、email_gate_reached、site_visited、site_cta_clicked、およびアカウントのマイルストーンは、サーバーが書き込むか導出するもので、ここでは拒否されます。

長さのみが制限されます。クライアントアドレスごとに制限されます。

セッションプロジェクトのすべての保留中、有効、無効、キャンセル済み、期限切れエージェントを安全なインストールメタデータ、最終使用、認証リクエスト数、直接帰属可能な計測クレジット付きで一覧表示。ベアラー、受信者キー、エンベロープ、プロジェクト識別子は返さない。

このエージェントの履歴は最新が先頭で、トリガーごとに1件の記録です。エージェントが要求した内容と結果として変わった内容の両方を含みます。何かを変更したリクエストは、その原因となったコマンドでスタンプされたドメインイベントです。何も変更しなかったリクエスト（拒否、失敗、イベントなしの成功）は1つの agent.command イベントです。

別のコマンドエンドポイントはありません。同じトリガーを2つのパネルに表示するのがこの欠陥の置き換えです。このエージェントのライフサイクルイベントは含まれます。ワーカー、プレーヤー、ダッシュボード専用のアクティビティはエージェントアクティビティとは推測されません。2つのリクエストは2つのトリガーです。拒否後の再試行は2つ目のレコードであり、最初の書き換えではありません。

読み取りは記録されません。何も変更せず、ポーリングエージェントはすべての実際の操作を埋もれさせるためです。匿名登録は除外されます。コマンドスタンプのすべての部分はこのサーバーが一致したルートまたは問題レジストリから派生します。

引数ベクターもリクエストボディもヘッダーもレコード内に自由テキストもなく、編集不要で、呼び出し元がオペレーターが見える画面に任意のテキストを書き込むことはできません。リソース識別子は認可ではなくイベントで既に公開されています。ページングキーはシーケンスの降順です。

続行するには返されたnext_cursorをafterとして渡してください。ページが短い場合、next_cursorは空で履歴の終わりを示します：同時追加はより高いシーケンスを取り、保持は最も低いシーケンスを先に削除するため、カーソルは生存レコードを重複またはスキップしません。オフセットページングはサポートされていません。

すべての検索パラメータはサーバー生成トークンに対する完全一致または範囲述語です。不正なカーソルやフィルター値はinvalid_requestで拒否されます。1-200の範囲外の制限は拒否されずデフォルトに調整されます。レコードはプロジェクト独自のイベント保持期間で期限切れになります。

新しい証明後に、選択したプロジェクトからエージェントを切断します。プロジェクトは、その人のメンバーシップのいずれかである必要があります。保留中の接続と資格情報の発行はキャンセルされ、代わりのトークンは発行されません。スクリーンに限定されたメンバーは、エージェントの接続、資格情報の発行、プロジェクトのユーザー管理を行えません：outside_screen_scope（プロジェクトオーナーに依頼してください）。

このエージェントがセッションプロジェクトで書いたノート、最新順、未解決と解決済み。stateはall（デフォルト）、open、resolved。next_cursorをafterとして返します；最後のページでは空です。ノート本文はエージェントが書いたプレーンテキストで、テキストとしてレンダーし、HTMLやMarkdownではありません。

サインインした人物としてエージェントのオープンノートの1つを理由付きで解決します。resolution.byに人物名を記録します。note.resolvedに人物をアクターとして追加します。解決済みノートはnote_not_openです。

サインインしているユーザーとして、エージェントのメモ（未解決または解決済み）を1つ削除します。note.deletedにユーザーをアクターとして追加します。

セッションプロジェクト宛ての保留中接続要求。メンバーがレビューし承認できます：プロジェクト名の要求と、すでにメンバーであるエージェントIDによるデバイスサインインまたは接続。

新しいインストールのサインインはリストされません（プロジェクトヒントはクライアント提供です）。ユーザーコードでアクセスできます（POST /api/agent-connections/lookup）。

保留中のデバイスサインインのユーザーコード（`screenrig login`）を、接続ページで入力または自動入力されたまま解決し、その接続の承認ビューを表示します。何も承認しません。区切り文字、空白、大文字小文字は無視されます。不明、使用済み、無効なコードはagent_connection_invalid、期限切れはagent_connection_expiredです。

ダッシュボードセッションごとに10分あたり5回、クライアントアドレスごとに1時間あたり20回、フリート全体で1時間あたり1200回の照会に制限されます（rate_limited）。スクリーンに限定されたメンバーは、エージェントの接続、資格情報の発行、プロジェクトのユーザー管理を行えません：outside_screen_scope（プロジェクトオーナーに依頼してください）。

安全な接続のレビューのメタデータを返します。レビューはプロジェクトを選択せず、承認はその人のメンバーシップのいずれかを選択します。

新しい証明後に、選択したプロジェクトへの接続を承認し、保留中のエージェントを作成します。プロジェクトは、その人のメンバーシップのいずれかである必要があります。安全なメタデータを返し、ベアラーは返しません。スクリーンに限定されたメンバーは、エージェントの接続、資格情報の発行、プロジェクトのユーザー管理を行えません：outside_screen_scope（プロジェクトオーナーに依頼してください）。

新しい証明後に、エージェントを作成せずに、選択したプロジェクトへの接続を拒否します。プロジェクトは、その人のメンバーシップのいずれかである必要があります。スクリーンに限定されたメンバーは、エージェントの接続、資格情報の発行、プロジェクトのユーザー管理を行えません：outside_screen_scope（プロジェクトオーナーに依頼してください）。

ダッシュボードシェル用の 1 回のリクエスト。

各メンバーは、対応するルートがこの同じセッションに対して返すボディです（GET /api/me/email、/api/support/status、/api/projects、/api/organizations、/api/project、/api/project/capabilities、/api/advertising/network、/api/alerts?state=open&limit=1、/api/reviews?state=all&limit=1）。そのルート自身のハンドラーが、そのルート自身の認可、プラン、スコープのチェックの下で生成します。

メンバーは、そのルートがこのセッションに対して 2xx で応答しない場合（拒否、読み取れないロールまたはプラン、現在のプロジェクトがない場合、障害）は含まれず、その場合はダッシュボードがそのルートを自分で読み取ります。advertising_network は、プロジェクトにネットワークがないためそのルートが 404 not_found で応答する場合は null です。

現在のプロジェクトがないセッションには、プロジェクトを必要としないメンバーが返されます。

セッションのプロジェクトにおけるプロジェクトのネットワークステータスカウンター。スクリーンのオンライン数はライブのペアリングされたランタイムイベントストリームから算出され、Screen.onlineが公開するものと同じです。これは保存されたブール値やプレーヤーハートビートではありません。メディアバイトは準備済みメディアの耐久バイトのみです。

正確な支払い能力状態。rails_availableがfalseでunavailable_reasonがfinancial_rails_unavailableの場合、カード、税金、現金引き出しのレールは利用不可。生の銀行認証情報は返されません。

呼び出し元が所有する1つの確定済み領収書／税務書類。未発送の資金回収中は領収書が存在しないため、これはnot_foundであり、偽造書類ではありません。

セッションプロジェクトの公開全クレジット残高を返します。このクッキー認証読み取りは決してデビットしないため、ゼロでも利用可能です。クッキーのみのダッシュボードはプロジェクトベアラーをGET /api/projectに提示しません。

セッションのプロジェクトが所有するアプリケーションの最新の準備完了リリースに対し、そのリリースの正確なプレビューホストで使い捨て30秒起動チケットを1つ発行します。リリースホストの Players フレームではなく、1つのブラウザで Player とダッシュボードが同じホストのキャッシュドキュメントやクッキーを共有しません。

チケットはそのホスト上でのみ release-grant クッキーに変換されるため、プレビューは構造上クロスオリジンであり、ウェブアプリコードはダッシュボードクッキーを読み取れません。レスポンスの release_id は、後から別の公開が完了しても、この起動で選択された正確なリリースを示します。launch_url は iframe.src に割り当て、他には割り当てないでください。

ここでの権限はオーナー権限です：セッションのプロジェクトがアプリケーションを所有します。これはscreenrig.webapp-package/v1の正確な現在のマニフェスト権限と並ぶ意図的な二次権限ソースで、この操作に限定されています。メディアや保護されたランタイムコンテンツには一般化しないでください。

親Playerはなく、ブラウザSDKとキー・バリューブリッジは閉じて失敗し、プレビューはプレゼンテーションのみです。準備済みのリリースがないアプリケーションは resource_conflict になります。

GET /api/organizations の項目として呼び出し元に表示されるとおりの組織1件で、admin、home、reseller を含みます。サインイン済みのユーザーは、その組織を管理している場合、委任先のリセラーを管理している場合、スタッフである場合、またはその一覧に表示される場合（有効なプロジェクトのメンバーである場合、またはホーム組織である場合）に読み取れます。

それ以外の人、および存在しない組織には 404 not_found が返ります。プロジェクトメンバーシップは付与しません。対象は Cookie セッションのみで、エージェント認証情報は拒否されます。

組織管理者が読み取れるのは、プロジェクト名、オーナー、ステータス、スクリーン数のみです。これによりプロジェクトアクセスは付与されません。管理者がプロジェクトのコンテンツを読み取れるのは、プロジェクトに参加した後（POST .../projects/{project_id}/access）のみで、そのユーザーの管理は以下のオーナーとメンバーのルートで行います。

サインイン済みのユーザーが組織を管理している有効なリセラーを、名前順に返します（admin_user_ids）。それ以外のユーザーには空になります。対象は Cookie セッションのみです。リセラーとは、スタッフがリセラーに設定した組織、またはその管理者が登録した組織です（POST /api/resellers）。その管理者が顧客の組織を運用します（docs/resellers.md）。

組織の管理者は、その組織を即座にリセラーにできます。呼び出し元は、メールアドレスが確認済みのサインイン済みユーザーで、organization_id で指定された組織の管理者である必要があります（Cookie セッションのみ。エージェントとサービスクライアントがリセラーの権限を持つことはありません）。それ以外の人には 404 not_found が返ります。

リセラーは定価の 2000 ベーシスポイント（20%）で今すぐ有効になり、審査待ちの状態から始まります。screenRIG が審査するまでは、現在の顧客を最大 10 社（customer_limit）まで登録できます。組織は有効で、すでにリセラーでなく、リセラーの顧客でもなく、スタッフまたはプロモのプランでもない必要があります（409 reseller_conflict、detail に理由が示されます）。

組織の監査に reseller.enrolled を追加します。

呼び出し元が管理するリセラー1件で、そのマージンを含みます。それ以外の人には 404 not_found が返ります。

リセラーの現在の顧客（委任されている組織）を名前順に、プラン、件数、保存バイト数とともに返します。対象はリセラー管理者のみで、それ以外の人には 404 not_found が返ります。

作成時点からリセラーに委任された顧客組織を Standard プランで作成し、呼び出し元のリセラー管理者を唯一の管理者とします。呼び出し元のホーム組織は変わりません。組織自身の管理者は、後から委任を終了できます（DELETE /api/organizations/{org_id}/reseller）。

組織の監査に organization.created と reseller.customer_started を追加します。審査待ち（review_state pending）のリセラーは、現在の顧客を customer_limit 社まで登録できます。それを超えると 409 reseller_conflict が返ります。

リセラーの現在の顧客1件。対象はリセラー管理者のみです。現在の顧客でない組織には 404 not_found が返ります。

現在の顧客のプランを設定します。プランの料金はリセラーが支払います。standard はプランを削除し、plus と premium は常に指定でき、education は Education プランの対象となる組織にのみ指定できます。Enterprise、staff、promo はスタッフが割り当てます。

アップグレードは直ちに、ダウングレードまたは削除は次の UTC 月の境界で適用されます。組織のプラン変更と同じです（docs/billing-rollup.md）。組織の監査に reseller.customer_plan を追加します。

現在の顧客の有効なプロジェクトを、名前、ステータス、スクリーン数、呼び出し元がすでにメンバーかどうかとともに返します。一覧の取得ではプロジェクトへのアクセスは付与されません。POST .../access でプロジェクトに参加します。

呼び出し元のリセラー管理者を、現在の顧客のプロジェクトのフルメンバーにします（can_approve、スコープなし、source は reseller_admin）。組織管理者の参加と同じ扱いで、PUT /api/session/project でプロジェクトを開けるようになります。すでにメンバーの場合は、プロジェクトをそのまま返します。

プロジェクトに member.added_by_reseller を、組織の監査に reseller.project_joined を追加し、プロジェクトオーナーにメールを送信します。メンバーシップは削除されるまで維持され、委任を終了しても削除されません。

リセラーが 1 つの UTC 月に支払う金額です。その月に一度でも委任されていた顧客ごとに 1 行で、月内の委任期間に発生した使用料のうち顧客自身のクレジットでまかなわれなかった分（定価とリセラー価格の両方）と、そのプランの年額が示されます。

リセラーの価格は、定価からマージンを差し引いた額です。マージンは、その月の開始とリセラーの（再）作成のうち遅い方の時点で有効なものが適用されます。対象はリセラー管理者のみです。

組織の管理者は、リセラーへの委任を直ちに終了します。以後、組織は自分で支払います。プラン、プロジェクト、メンバーはそのまま維持され、リセラー管理者が持つメンバーシップも含まれます。委任中に組織のウォレットで発生した超過分（リセラーに請求される分）は、同じ変更で帳消しになります。

組織の監査に reseller.customer_ended を追加します。リセラーのない組織には 404 not_found が返ります。

所有者が正確に検証済みドメインのメールを持つ他の場所のプロジェクト。連絡先アドレスやサブドメインは一致せず、管理者はプロジェクトを引き込めません。

1つのドメインに対して7日間のDNS TXTチャレンジを開き、そのドメインの保留中チャレンジを置き換えます。組織の他のドメインは変更されません。返されたDNS名に正確な値を設定し維持してください。組織は最大20ドメインを保持できます（検証済みと保留を合わせて）（resource_conflict）。他の組織が保持するドメインは resource_conflict です。

組織がすでに保持するドメインは再度証明でき、日次DNSチェックの新しい値が記録されます。

未期限切れのチャレンジを1つDNSに対して検証し、既に保持しているドメインの隣に組織にそのドメインを追加します。各正確なドメインは1つの組織に属します。ルックアップ中に回転した証明は拒否されます。TXTレコードはそのままにしてください。7日間レコードが見つからないドメインは毎日チェックで削除されます。

クレームが確定すると、この応答の後バックグラウンドで、所有者が正確にそのドメインで検証済みの人物であり、その所有者の個人組織に単独で存在する各プロジェクトがこの組織に移動されます（名前が衝突すると「<name> (<owner>)」にリネームされます）。

他の組織のプロジェクト、独自に顧客支払いプランを持つプロジェクト、および所有者やスタッフがドメイン組織から移動したプロジェクトはそのまま残ります。組織の制限で拒否されたプロジェクトは1日後に再試行されます。配置はアクセス権を付与しません。

指定された管理者は組織の管理者、管理者候補（ライブプロジェクトの検証済みアクティブ所有者でまだ管理者でない人）、組織リビジョンを読み取ります。他は他の組織管理者ルートと同様に拒否されます。対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

指定された管理者は組織の管理者を置き換えます。If-Match は組織リビジョンを保持し、古い場合は revision_conflict と current_revision を返します。セットは1～20人を指定し、各人は現在の管理者か候補でなければなりません。そうでなければ invalid_request。管理者は他に管理者がいる場合のみ自分を削除できます。

変更はリビジョンをインクリメントし、組織の監査に記録され、プロジェクトメンバーシップは付与されず、GET と同じ形状を返します。対象は人のみで、エージェントやベアラー資格情報には管理者ルートがありません。

指定された管理者が組織のユーザーを読み取ります。読み取り専用です。projects は組織のライブプロジェクトを名前順に最大500件リストします。people は、組織のホームメンバー（member が true）、それらのプロジェクトのアクティブなメンバーシップ（停止中のメンバーシップは除く）、および指定された管理者の合計です。

管理者、ホームメンバー、外部ユーザー（ホームメンバーではないユーザー）の順で並び、各グループ内は表示名、次にメールアドレスの順です。

各ユーザーには、各プロジェクトでの役割（owner または member）、そのプロジェクトでレビューを承認できるかどうか（can_approve）、スクリーンまたはアップロードに限定されているかどうか（limited）、管理者かどうか、ホームメンバーかどうか（member）、組織に管理されているかどうか（managed）、そして外部ユーザーについては現在のゲストポリシーが受け入れないかどうか（outside_guest_policy）が含まれます。

どのプロジェクトにも属さない管理者やホームメンバーは、空の projects リストで表示されます。アドレスが確認されていないユーザーの email は空です。無効化されたユーザーとエージェントは表示されません。最大500人のユーザーが返され、管理者は常に含まれます。ユーザー、プロジェクト、メンバーシップが省略された場合は truncated が true になります。

それ以外のユーザーは、他の組織管理者ルートと同様に拒否されます。対象は人のみで、エージェントとベアラー認証情報にはルートがありません。

指定された管理者は組織の管理者招待をIDで50件ずつ一覧表示し、期限切れのものは削除します。受取人のアドレスは招待を提供した組織の管理者に見えます。トークンや認証URLは一覧に含まれません。対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

指定された管理者はメールで人を管理者に招待します。承諾すると組織の管理者に追加され、ログインがなければ作成されます。プロジェクトメンバーシップは付与されません。保留中の管理者招待を含め最大20人（organization_admin_limit）。すでに組織を管理している人物のアドレスは invalid_request です。

メール招待は7日後に期限切れとなります。同じアドレスへの未処理招待があれば再利用されます。組織名と招待者名はメールに適した内容である必要があります。ユーザーのみ対象です。エージェントやベアラ認証情報には管理者ルートがありません。

指定された管理者は未処理の管理者招待を取り消し、管理者枠を解放します。すでに取り消された招待は204を返し、承諾済みは invitation_consumed を返します。組織が保持しないIDは not_found です。対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

指定された管理者は組織のメンバー招待をIDで50件ずつ一覧表示し、期限が過ぎたものは先に期限切れにします。受取人のアドレスは招待を提供した組織の管理者に見えます。トークンや認証URLは一覧に含まれません。対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

指定された管理者は、メールで人を組織のメンバーとして招待します。承諾すると、以前のホーム組織があってもそれに代えて、その人のホーム組織がこの組織に設定され、ログインがなければ作成されます。プロジェクトメンバーシップは付与されません。

ユーザーがすでに組織のホームメンバーであるアドレスは invalid_request で、別の組織が管理しているユーザーのアドレスは managed_elsewhere です。メール招待は7日後に期限切れとなります。同じアドレスへの未処理招待があれば再利用されます。組織名と招待者名はメールに適した内容である必要があります。

スタッフ組織（plan_id staff）への招待を承諾すると、その人もスタッフになるため、この招待を送信できるのはスタッフだけです。リクエストごとに宛先は1件で、その宛先に紐づく staff_grant 証明が必要です（証明がなければ reauthentication_required）。対象は人のみで、エージェントや bearer 認証情報には管理用ルートがありません。

指定された管理者は未処理のメンバー招待を取り消します。すでに取り消された招待は204を返し、承諾済みは invitation_consumed を返します。組織が保持しないIDは not_found です。対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

指定された管理者が組織からホームメンバーを削除します。

1つのトランザクションで、ユーザーのホーム組織が解除され、組織のすべてのライブプロジェクトでのメンバーシップが、そのプロジェクトから削除した場合と同じ扱いで終了します（そのプロジェクトへの未処理のメール招待は取り消され、セッションはプロジェクトを解決しなくなります）。他の組織のプロジェクトでのメンバーシップには影響せず、ほかの組織も変更されません。

変更は組織の監査に記録されます。

IDプロバイダーが管理するユーザー（シングルサインオンまたは SCIM）は managed_member、指定された管理者は organization_admin_member（先に PUT /api/organizations/{org_id}/admins で管理者枠を削除してください）、組織のライブプロジェクトを所有するユーザーは member_owns_projects で、詳細にプロジェクト名が一覧されます（先にそれらのプロジェクトを移譲してください。何も削除されません）。組織のホームメンバーでないユーザー（すでに削除された人を含む）は not_found です。

対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

指定された管理者は、組織がプロジェクトにゲスト（ホーム組織が別の組織であるか、ホーム組織を持たない人）として受け入れる対象を設定します。mode が allow（デフォルト）の場合はすべてのゲストを受け入れ、domains の場合は検証済みメールアドレスが domains のいずれかにあるゲストを受け入れ、none の場合はゲストを一切受け入れません。domains には、重複しない小文字の DNS 名を1～20件指定します。mode が domains の場合は必須で、それ以外では省略します。それ以外は invalid_request です。

ポリシーは以前のものを置き換え、組織のリビジョンをインクリメントし、組織の監査に記録され、適用中のポリシーを返します。組織がゲストにプロジェクトメンバーシップを付与するとき、つまりプロジェクトメンバー招待（作成と承諾）および SCIM グループの紐付けの際にチェックされ、拒否された場合は guest_not_allowed が返されます。

スタッフと組織自身の管理者は対象外で、エージェントはチェックされず、ホームメンバーはゲストになりません。ポリシーを厳しくしても誰も削除されません。outside_policy は、新しいポリシーが受け入れない、すでに組織のライブプロジェクトにいる外部ユーザーの数で、GET /api/organizations/{org_id}/people はそれぞれに印を付けます（outside_guest_policy）。

対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

指定された管理者が、組織のライブラリプロジェクトを設定または解除します。project_id には組織の有効なプロジェクトの 1 つを指定し、null を指定すると解除されます。

組織の他のすべてのプロジェクトは、ライブラリのメディア、メディアフォルダー、プレイリストを読み取り（GET /api/media、/api/media-folders、/api/playlists の library=true、および ID 指定）、読み取り専用で使います。対象は、ページのメディア参照、ライブラリのフォルダーを指定する by:folder セレクター（タグセレクターと all セレクターはライブラリに届きません）、スクリーンのスケジュールとスタック、from_template です。変更できるのはライブラリ自身のメンバーだけです。

ライブラリプロジェクトにはスクリーンがありません。スクリーンのあるプロジェクトは library_no_screens となり、その後ライブラリにスクリーンを追加することもできません。ライブラリの設定にはプラン機能 library が必要です（Premium、Education、Enterprise。それ以外は feature_not_in_plan）。解除には不要で、ダウングレード後も維持されたライブラリは引き続き提供されます。

ライブラリを解除または置き換えると、その項目を指定しているメンバープロジェクトのプレイリストは、次に書き込まれる時点で解決できなくなり、スクリーンはそのメディアを受け取らなくなります。ライブラリであるプロジェクトを削除するか、組織の外へ移動すると、ライブラリは解除されます。

組織ビューを返し、組織の監査に記録され（organization.library_changed）、リビジョンを加算します。対象は人のみです。

指定された管理者は、複数のユーザーの、組織の複数のライブプロジェクトへのアクセスを、どのプロジェクトにも参加せずに、1回のリクエストでまとめて設定します。

1〜500件の各変更は、プロジェクト、ユーザー、アクセスを指定します。同じ (project_id, user_id) の組を2回指定することはできません。member はそのユーザーを、レビューを承認できないプロジェクトのメンバーにします（メンバーでない場合は追加され、approver だった場合は承認権限を失います）。approver は承認できるメンバーにします（メンバーでない場合は追加されます）。none はメンバーにしません（メンバーである場合は削除されます）。

すべてが1つのトランザクションで順に適用され、1件でも拒否されるとバッチ全体が取り消されます。各拒否は、errors[].field で changes[i]（プロジェクトまたはユーザー）または changes[i].access を指します。

この組織のライブプロジェクトでないプロジェクトは not_found です。有効なユーザーでない人（エージェント、無効化されたユーザー、不明な id）またはスタッフ、停止中のメンバーシップ、組織のユーザー（管理者、ホームメンバー、組織の他のライブプロジェクトのアクティブなメンバー。それ以外のユーザーは招待を通じて参加します）に含まれないユーザーの追加は invalid_request です。オーナーを member や none に設定することはできません（owner_cannot_leave）。アップローダーが承認者になることはありません（resource_conflict。PUT /api/members/{user_id}/approver の応答と同じ）。管理者自身を削除することは禁止されています（管理者は DELETE /api/members/{user_id} で退出します）。追加されるユーザーは招待で受け入れられる場合と同じ基準で受け入れられるため、ホームメンバーと組織の管理者は常に、外部ユーザーは現在のゲストポリシーが受け入れる場合に限り追加できます（guest_not_allowed）。

追加には、プロジェクトの200メンバーの上限とプランのメンバー数の上限が適用されます（member_limit_reached）。応答はすべての変更をリクエストの順に繰り返します。アクセスがすでに有効だった変更は changed が false になり、何も書き込まれず、記録もされません。

各変更は組織の監査（organization.project_member_added、organization.project_member_approver_changed または organization.project_member_removed）とプロジェクトのイベント（member.added_by_organization_admin、project.member_approver_changed または member.removed。組織の管理者によるものとして記録）に記録され、各プロジェクトのオーナーには、本人が行った場合を除き、バッチごとに1回メールが送信されます。

対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

指定された管理者は、組織のライブプロジェクトの1つに、スクリーンスコープもアップロードスコープもなく、レビューを承認できるメンバーとして参加します。参加することで、管理者はプロジェクトのコンテンツにアクセスできるようになります。組織のルートにはコンテンツは表示されません。

すでにスコープなしで承認できるメンバーである管理者には、joined が false の 200 が返され、何も変わりません。スクリーンまたはアップロードのスコープを持つメンバー、または承認できないメンバーは、スコープなしで承認できるメンバーになり、参加として記録されます。

プロジェクトの200メンバー上限が適用されます（member_limit_reached）。組織のゲストポリシーが組織自身の管理者に適用されることはありません。参加は組織の監査に organization.project_joined として、プロジェクトのイベントに member.added_by_organization_admin として記録され、プロジェクトのオーナーにメールが送信されます。

組織が保持しない、または削除されたプロジェクトは not_found です。対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

指定された管理者は、組織のライブプロジェクトの1つに参加せずに、現在のオーナー（アカウントが無効化されているオーナーを含む）から所有権を移し、ユーザーをそのプロジェクトのオーナーにします。

新しいオーナーは、プロジェクトのメンバーであるか、組織のホームメンバーである、検証済みのアクティブなユーザーです（プロジェクトのメンバーではないホームメンバーは、先に、スクリーンスコープもアップロードスコープもなくレビューを承認できるメンバーとして追加されます。ホームメンバーにはゲストポリシーは適用されません）。それ以外は user_id で invalid_request です。

管理者が自分自身をオーナーにできるのは、プロジェクトに参加した後のみです（POST /api/organizations/{org_id}/projects/{project_id}/access）。スクリーンスコープもアップロードスコープもなく承認できるメンバーでない場合は、user_id で invalid_request です。

効果はオーナー自身による移譲と同じで、新しいオーナーのスクリーンスコープとアップロードスコープは解除され、プロジェクトの従来の責任は新しいオーナーに紐付けられます。現在のオーナーを指定しても何も変わりません。変更は組織の監査に organization.project_owner_changed として記録され、以前のオーナーと新しいオーナーにメールが送信されます。

プロジェクトの200メンバー上限は、追加されるホームメンバーに適用されます（member_limit_reached）。組織が保持しない、または削除されたプロジェクトは not_found です。対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

指定された管理者は、組織のライブプロジェクトの1つに参加せずに、そのプロジェクトからメンバーを削除します。オーナーによる削除（DELETE /api/members/{user_id}）と同じ効果があります。メンバーシップが終了し、そのユーザーのプロジェクトへの未処理のメール招待が取り消され、セッションはプロジェクトを解決しなくなり、エージェントのメンバーシップは残ります。

オーナーは削除されません（owner_cannot_leave。先に PUT /api/organizations/{org_id}/projects/{project_id}/owner で所有権を移譲してください）。プロジェクトのメンバーでないユーザー（すでに削除された人を含む）、および組織が保持しない、または削除されたプロジェクトは not_found です。

削除は、組織の監査に organization.project_member_removed として、プロジェクトのイベントに removed_by_organization_admin が true の member.removed として記録されます。対象は人のみで、エージェントやベアラー認証には管理者ルートはありません。

1つのドメイン（検証済みまたは保留中）を削除し、組織の他のドメインは残します。今後の配置と検出は停止し、別の組織が検証できるようになります。組織に既にあるプロジェクトは残ります。組織が所有も証明もしていないドメインは not_found です。

組織がシングルサインオンを必須にしている間、検証済みドメインは resource_conflict です。シングル サインオンを必須にするをオフにすると 72 時間後に有効になり、その時点でドメインを削除できます。

メンバーが承認できるかどうかを設定します：レビューを決定し、エージェントに Manage アクセスを付与します。承認できないメンバーのエージェントは Propose に制限されます。実行できるのはプロジェクトのオーナー、またはプロジェクトの組織を管理するメンバーのみ（それ以外は forbidden）、オーナー自身の行は固定（resource_conflict）、メンバーでない場合は not_found です。

project.member_approver_changed を追加します（詳細は user_id、can_approve）。

メンバーをスクリーンフォルダー（それぞれ内側のすべてのフォルダーを含む）とスクリーンに限定するか、そのスコープを置き換えます（docs/screen-scope.md）。

1つのトランザクションで、そのユーザーがプロジェクトに連れてきたエージェントも終了し（メンバーを削除した場合と同様に agent.disconnected）、project.member_screen_scope_changed を追加します（詳細は user_id、screen_scope、previous、changed_by_user_id）。スコープはメンバーの次のリクエストで読み取られます。変更は、再度サインインしなくても、次の GET /api/session に反映されます。

実行できるのはプロジェクトのオーナー、またはプロジェクトの組織を管理するメンバーのみ（それ以外は forbidden）。オーナー自身の行、アップローダー（スコープ付きメンバーはスクリーンに、アップローダーはコンテンツに限定されます）、およびスコープ内に個別のスクリーンを持つレビュー承認メンバーは resource_conflict です。メンバーでない場合は not_found です。プロジェクトの有効なスクリーンフォルダーまたはスクリーンではないIDは、screen_scope.folder_ids[i] または screen_scope.screen_ids[i] で invalid_request です。

レビューを承認するスコープ付きメンバーが承認できるのはスコープ内のみです。承認できないメンバーは、読み取りとコマンドの実行はできますが、再生内容の変更は承認者を通じてのみ可能です（approver_required）。

スコープは、そのユーザー、またはそのユーザーが連れてきたエージェントがプロジェクトの有効なサービスクライアントを持っている間も、resource_conflict で拒否されます。詳細には最大5つのクライアントが ID（名前）として示され、残りは件数で示されます。何も書き込まれません。

ユーザーをスクリーンに限定することはスクリーンのスコープであり、Enterprise プランに含まれます。プランにこの機能が含まれていないプロジェクトは feature_not_in_plan（402）で拒否されます。設定されたスコープは、クリア（DELETE）されるまでユーザーを制限し続けます。クリアはすべてのプランで行えます。

スコープ付きメンバーに、プロジェクト全体のスクリーンを再び与えます。実行できるのはプロジェクトのオーナー、またはプロジェクトの組織を管理するメンバーのみで、スコープのないメンバーはそのままです。screen_scope を null にして project.member_screen_scope_changed を追加します。

セッションプロジェクトでのエージェントのメンバーシップを、スクリーンフォルダーとスクリーンに限定するか、そのスコープを置き換えます（docs/screen-scope.md）。エージェントの到達範囲は、このスコープを責任者のスコープで絞り込んだものであり、スコープ付きのユーザーが、自分より広いエージェントを通じて操作することはありません。

実行できるのはプロジェクトのオーナー、またはプロジェクトの組織を管理するメンバーのみ（それ以外は forbidden）。プロジェクトのメンバーではないエージェントは not_found です。agent.screen_scope_changed を追加します（詳細は agent_id、screen_scope、previous、changed_by_user_id）。

エージェントのスコープは、書き込んだインスタンスでは次のリクエストから、ほかのインスタンスでは2秒以内に適用されます。スコープは、エージェントがプロジェクトの有効なサービスクライアントを持っている間は resource_conflict で拒否されます。詳細には最大5つのクライアントが ID（名前）として示され、残りは件数で示されます。何も書き込まれません。

エージェントをスクリーンに限定することはスクリーンのスコープであり、Enterprise プランに含まれます。プランにこの機能が含まれていないプロジェクトは feature_not_in_plan（402）で拒否されます。設定されたスコープは、クリア（DELETE）されるまでエージェントを制限し続けます。クリアはすべてのプランで行えます。

セッションプロジェクトでのエージェントのメンバーシップのスコープを削除します。実行できるのはプロジェクトのオーナー、またはプロジェクトの組織を管理するメンバーのみです。screen_scope を null にして agent.screen_scope_changed を追加します。

メンバーをアップローダーにするか、アップローダーの範囲を置き換えます（docs/uploaders.md）。ページを変更できるプレイリストと、アップロード先のメディアフォルダーが対象です。

同一トランザクションで、レビューの承認も停止し、そのメンバーがプロジェクトに連れてきたエージェントを終了し（削除した場合と同様に agent.disconnected）、project.member_upload_scope_changed を追加します（詳細は user_id、upload_scope、changed_by_user_id）。

範囲はメンバーの次のリクエストで読み込まれます。変更は、再度サインインしなくても次の GET /api/session に反映されます。

実行できるのはプロジェクトのオーナー、またはプロジェクトの組織を管理するメンバーのみ（それ以外は forbidden）。オーナー自身の行は resource_conflict、メンバーでない場合は not_found、プロジェクトの有効なプレイリストまたはメディアフォルダーではないIDは upload_scope.playlist_ids[i] または upload_scope.folder_ids[i] で invalid_request になります。access が propose（デフォルト）の場合、アップローダーの変更はレビューに送られ、manage の場合は公開されます。

スクリーンに限定されたメンバーは resource_conflict です。先にそのスコープを解除してください（DELETE /api/members/{user_id}/screen-scope）。

アップローダーを再び通常のメンバーに戻します。通常のメンバーになってもレビューは承認しません（承認を有効にするには setDashboardMemberApprover を使用）。実行できるのはプロジェクトのオーナー、またはプロジェクトの組織を管理するメンバーのみで、アップローダーでないメンバーはそのままです。upload_scope を null にして project.member_upload_scope_changed を追加します。