nocobase-acl-manage

目標

ACL と権限ガバナンスをタスク主導型のワークフローに変え、ユーザーが業務上の成果を依頼すると、スキルが以下を処理できるようにします。

• CLI コマンドの選択と引数の整形
• 機能の確認と安全策
• 書き込みの確認と読み戻しによる証跡の取得
• 影響の大きい変更についてのリスクを重視した説明

スコープ

• このスキルでは、読み取りと書き込みに CLI を優先します。
• タスクは以下の 5 つのドメインに分類されます。
• role
• global role mode
• permission（Portal へのアクセスを含む）
• user
• risk assessment
• すべての書き込みタスクは plan -> confirm -> apply -> readback に従います。
• global role mode はロールごとのフィールドではなく、グローバルなシステムポリシーとして扱います。

対象外

• CLI を迂回して、REST エンドポイントを直接呼び出さないでください。
• 場当たり的なデータベース操作で ACL を変更しないでください。
• ACL の書き込みを実行するための一時的なスクリプトファイルを作成しないでください。
• 環境やプラグインのブートストラップに他のスキルを呼び出さず、このスキル内で nb コマンドを直接使用してください。
• 影響範囲の大きい変更（グローバルモード、広範囲に適用されるスニペット、広範囲に影響するストラテジー操作）を隠さないでください。
• ガバナンスレビューが必要なワークフローに対して、ワンクリックですべてを実行できると主張しないでください。

標準タスクモデル

A）ロールドメイン

タスク	ユーザーが得られる成果	必須入力	任意入力
role.audit-all	すべてのロールを、比較可能なポリシーの概要とともに一覧表示します	なし	data_source_key、output
role.create-blank	デフォルトの読み取り専用ベースラインでロールを作成します（作成モードは 1 種類のみ）	role_name	role_title、description、hidden、allow_configure、allow_new_menu、解決済みの Portal 用に作成する場合は portal_uid または portal_hint
role.compare	ロール間の違いを説明します	role_names[]	data_source_key、output

B）グローバルロールモードドメイン

タスク	ユーザーが得られる成果	必須入力	任意入力
global.role-mode.get	現在のグローバルロールモードを読み取ります	なし	output
global.role-mode.set	グローバルロールモードを切り替えます	role_mode	strict_mode

role_mode の列挙値の対応：

• default：ロールを個別に使用します（ユニオンモードなし）
• allow-use-union：ユニオンモードを利用可能にし、ロールの切り替えも引き続き許可します
• only-use-union：複数ロールを持つユーザーにユニオンモードの使用を強制します

C）権限ドメイン

タスク	ユーザーが得られる成果	必須入力	任意入力
permission.system-snippets.set	ロールレベルのシステムスニペットを設定します	role_name、（snippet_preset または snippets）	なし
permission.route.desktop.set	ロールのデスクトップルート権限を設定します	role_name、route_ids[]	set_mode（set、add、remove のいずれか）
permission.portal.access.set	既存の Portal へのロールのアクセス権を付与または取り消します	role_name、（portal_uid または portal_hint）、access	なし
permission.data-source.global.set	1 つのデータソース内のすべてのテーブルに対するグローバルなストラテジーアクションを設定します	role_name、global_actions[]	data_source_key
permission.data-source.resource.set	1 つ以上のコレクションに個別のアクションを設定します	role_name、（collection_hint または collection_hints[]）、actions[]	data_source_key、fields_map、scope_map、resource_scope（デフォルトは all）
permission.scope.manage	再利用可能なスコープを作成／更新／一覧表示します	scope_task	data_source_key、scope_id、scope_payload

D）ユーザードメイン

タスク	ユーザーが得られる成果	必須入力	任意入力
user.assign-role	1 つのロールを 1 人以上のユーザーに割り当てます	role_name、（user_ids[] または user_filter）	allow_generic_association_write
user.unassign-role	1 つのロールを 1 人以上のユーザーから削除します	role_name、（user_ids[] または user_filter）	allow_generic_association_write
user.audit-role-membership	ロールに紐づくユーザーを確認します	（role_name または user_id）	output

E）リスクドメイン

タスク	ユーザーに提供する結果	必須入力	任意入力
risk.assess-role	1 つのロールのリスクスコアと根拠	role_name	data_source_key、output
risk.assess-user	ユーザー・ロール・権限の関係に基づくリスクスコア	user_id	data_source_key、output
risk.assess-system	システムレベルの ACL ガバナンスリスクの概要	なし	data_source_key、output

ロール作成時の対話ポリシー：

• 常に同じデフォルトの読み取り専用ベースライン（role.create-blank）で作成します
• role_name には、r_ プレフィックスを付けた NocoBase のロール UID 形式を使用する必要があります
• ユーザー入力に r_ プレフィックスがない場合は、r_<normalized_name> に正規化し、確認・読み返し時に正規化後の値を表示します
• ユーザーにロールの種類（例：「従業員／監査担当者／マネージャー／カスタム」）を選ばせないでください
• role_name が指定されている場合は、作成を直接実行します
• リクエストに現在解決済みの Portal が含まれている場合は、確認前にその Portal を解決します。ロール作成後、permission.portal.access.set を通じてそのロールに Portal への明示的なアクセス権を直ちに付与し、その後、ロールと正確な Portal の関連付けの両方を読み返します
• Portal へのアクセス権付与に失敗した場合は部分的な完了として扱い、新しいロールがその Portal で使用可能だと主張しないでください
• Portal のコンテキストを利用できない場合は、推測したり無関係な Portal へのアクセス権を付与したりせず、作成成功後に権限割り当ての案内に進みます
• 権限に関する次の選択肢：システムスニペット、デスクトップルート、Portal エントリーアクセス、データソースのグローバル戦略、データソースのリソース戦略

リソース権限の対話ポリシー：

• permission.data-source.resource.setを実行する前に、必ず以下を確認してください。
• データソースキー（ユーザーが別の値を指定しない限り、デフォルトはmain）
• 解決済みの対象コレクション
• アクションの一覧
• データ範囲（ユーザーが指定しない場合、デフォルトはall）
• 操作を表す動詞とACLアクション名を区別してください。
• add table permissionやconfigure permissionなどの表現は操作を示すものであり、ACLアクションのcreateを示すものではありません。
• ユーザーがデータ作成機能（can create records／can add data）を明確に求めている場合に限り、createを選択されたアクションとして扱ってください。
• ユーザーに正確な技術的コレクション名の提示を求める必要はありません。
• ビジネス上の名称やキーワードをcollection_hint(s)として受け付けてください。
• 選択されたデータソースのコレクション一覧から、実際のコレクション名を解決してください。
• 一致候補が複数ある場合は、候補を提示してユーザーに選択を求めてください。
• 一致するものがない場合は、より明確なビジネスキーワードをユーザーに尋ねてください。
• 書き込みの前に、スコープのバインドを解決してください。
• ユーザーがスコープを指定しない場合、デフォルトはallです。
• all → 対象データソース内の組み込みスコープkey=allのID
• own → 対象データソース内の組み込みスコープkey=ownのID
• custom → ユーザー指定のスコープID（または解決済みのスコープキー）
• 最終的なスコープがallまたはownの場合、アクションのスコープをnullのままにしないでください。
• 書き込みの完全性（厳守事項）：
• permission.data-source.resource.setでは、対象コレクションごとに完全な書き込みペイロードを1つ実行してください。
• 書き込みペイロードにはusingActionsConfig: trueを含めてください。
• 同じペイロードに、最終的なactions[]のセット、all|ownに対する明示的なスコープのバインド（scopeIdまたはscopeKey）、およびフィールド設定可能なアクションに対する空でないfields配列を含めてください。
• 「最初にアクションを設定し、その後にフィールド、スコープ、usingActionsConfigを更新する」形で、書き込みを分割しないでください。
• 書き込みの前に、確認用の概要（データソース、解決済みのコレクション、アクション、スコープ）を提示してください。
• スコープがデフォルト値の場合、確認時にscope=all (default)と明示し、ユーザーが変更できるようにしてください。
• 必須項目に不足がある、または解決されていない項目がある場合は、まずユーザーに尋ね、書き込みを行わないでください。
• フィールドのデフォルトルール：すべてのフィールド
• 全フィールドをデフォルトにする場合は、対象コレクションのメタデータから解決したフィールド名の一覧を明示的に書き込んでください。
• 全フィールドをデフォルトにすることを示すためにfields=[]を使用しないでください。
• ユーザーがフィールド単位の制限を指定していない場合、選択された各アクションに全フィールドへの権限を適用してください。
• フィールド設定をサポートする、選択されたすべてのアクション（create、view、update、export、importXlsx）に、全フィールドのデフォルトを適用してください。
• 全フィールドをデフォルトにする場合、ユーザーが明示的に除外を求めない限り、メタデータから返されたシステムフィールド（例：sort、createdBy、createdById、updatedBy、updatedById）も含めてください。
• 書き込みには技術的なフィールド名（field.name）を使用し、表示タイトルは使用しないでください。
• システム、コンテキスト、リレーション、または非表示のフィールドであるという理由だけで、フィールドを自動的に除外しないでください。ユーザーの意図で明示的に制限されている場合に限り、除外してください。
• コレクションのviewアクションでは、デフォルトですべてのフィールドを対象にしてください。
• ユーザーがコレクションに対するall permissionsを明示的に求めた場合は、実行時に利用可能なアクションを解決し、展開されたアクションのセットを確認してから書き込みを行ってください。

ポータル権限の操作ポリシー：

• 既存のカスタム Portal にロールが入れるかどうかだけを管理します。このタスクを、Portal 内部のルート、メニュー、ページ、領域、コントロール、データの権限設定として扱わないでください
• 書き込みを計画する前に、nb portal list -j を使って有効な実在の Portal を 1 つ特定します。uid、名前、パス、タイトル、または業務上のヒントを受け付けますが、一致する候補が複数ある場合は必ず絞り込みを求めてください
• nb api acl roles multi-portals ... で公開されている公式の roles.multiPortals:list/add/remove 関連付けアクションを使用します。rolesMultiPortals 中間テーブルに直接書き込まないでください
• ユニオンロールの Portal アクセスは、有効なロールのいずれかに明示的な Portal 許可がある場合に認められます。root は有効なすべての Portal に入れます
• allowNewMultiPortal は将来の Portal に対する個別のデフォルトポリシーであり、特定の既存 Portal にロールが入れることを示すものではありません
• 書き込み後は、ロールの Portal 関連付けを読み戻し、対象 Portal の uid が存在する、または存在しないことを確認してください
• Multi-portal 機能または roles multi-portals の実行時コマンドを利用できない場合は、機能に関する案内を提示して停止してください。別のコレクションを使って Portal 許可を模倣しないでください

入力コントラクト

入力	必須	デフォルト	検証	確認の質問
task	はい	なし	正規タスクまたはエイリアスのいずれか	「どの ACL ガバナンスタスクを実行しますか？」
role_name	条件付き	なし	更新／監査タスクではロールが存在すること。書き込みタスクでは r_* uid に正規化	「対象にするロールを指定してください。」
role_mode	条件付き	なし	default/allow-use-union/only-use-union のいずれか	「どのグローバルロールモードを設定しますか？」
collection_hint / collection_hints[]	条件付き	なし	permission.data-source.resource.set で必須。業務上の名称／キーワードを入力できます	「設定する業務テーブルを指定してください。」
resolved_collection_names[]	条件付き	実行時に解決	permission.data-source.resource.set の書き込み前に必須。各コレクションが選択したデータソースに存在すること	「一致するコレクションが見つかりました。どれを使用しますか？」
actions[]	条件付き	なし	permission.data-source.resource.set で必須	「これらのコレクションでどのアクションを許可しますか？」
portal_uid / portal_hint	条件付き	なし	Portal 権限タスクで必須。有効なカスタム Portal を 1 つに特定すること	「このロールにどの Portal へのアクセスを許可しますか？」
access	条件付き	なし	permission.portal.access.set では allow または deny	「このロールに Portal への入場を許可しますか、拒否しますか？」
resource_scope	いいえ	all	all / own / custom(scope_id or scope_filter) のいずれか	「どのデータスコープを使用しますか？ デフォルトは all です。必要な場合のみ own/custom を選択してください。」
data_source_key	いいえ	main	実行時に存在すること	「どのデータソースキーを使用しますか？（デフォルト：main）」
strict_mode	いいえ	safe	safe または fast	「読み戻しを含むセーフモードを使用しますか？」
allow_generic_association_write	いいえ	false	ブール値	「ユーザーロール割り当てに、ガード付きの汎用関連付け書き込みを許可しますか？」
output	いいえ	text+matrix	text、text+matrix、text+evidence	「結果の詳細度を指定してください。」

ユーザーが you decide と言った場合のデフォルトの動作：

• ロールに関する意図にはロールタスクを選択します
• ポリシーに関する意図には権限タスクを選択します
• 割り当てに関する意図にはユーザータスクを選択します
• 評価に関する意図にはリスクタスクを選択します
• ロール作成の意図では、必ず最初に role.create-blank を使用します
• data_source_key=main
• strict_mode=safe

フィルター作成ゲート

再利用可能なカスタム ACL スコープ、scope_filter、user_filter、またはその他の永続化される権限フィルターを作成する前に、トピック filter を指定して nocobase-utils スキルを読み込み、現在のタスクで フィルター条件の形式 を読んでください。各末端フィールドの実際のフロントエンドインターフェース／型を確認し、そのグループの演算子許可リストのみを使用してください。日付フィールドでは日付専用の比較演算子を使用します。バックエンドが受け付ける場合でも、$lt、$lte、$gt、$gte は数値専用です。この UI 表示可能な許可リストを、--filter-by-tk などの固定 CLI ロケーターオブジェクトや、コマンドのドキュメントに記載された直接制御フィルターに機械的に適用しないでください。

必須確認ゲート

• 確認ラウンドの最大数：2
• 1 ラウンドあたりの質問数の上限：3
• 必要な入力がすべて揃う前に書き込みを実行しないでください
• role.create-blank では、role_name が不足している場合に限り、role_name のみを尋ねてください。ロールタイプについては尋ねないでください
• role_name を含む書き込みタスクでは、r_* UID に正規化し、確認時に正規化した値を伝えてください
• permission.data-source.resource.set では、省略されている場合、ユーザーが別のデータソースを明示的に指定しない限り、data_source_key=main をデフォルトにしてください
• permission.data-source.resource.set では、コレクションのヒントを解決できない、または曖昧な場合、書き込み前に追加の質問をしてください
• permission.data-source.resource.set では、アクションが不完全な場合、書き込み前に追加の質問をしてください
• permission.data-source.resource.set では、スコープが省略されている場合、デフォルトの all を適用し、書き込み前に確認を必須としてください
• permission.data-source.resource.set では、カスタムスコープが要求されていて、スコープ ID／キーを解決できない場合、書き込み前に追加の質問をしてください
• Portal への書き込みでは、有効なカスタム Portal を 1 つ特定できるまで続行しないでください
• permission.data-source.resource.set では、ユーザーが最終的な書き込み計画を確認していない場合、書き込みを行わないでください
• ユーザーが特定のロールのモード設定を求めた場合、確認のうえ、グローバルモードの変更として正規化してください
• タスクが書き込みを伴い、対象の ID が不足している場合、停止して最初に確認してください
• CLI が認証エラー（401、403、Auth required）を返した場合、停止し、環境／認証の復旧を nocobase-env-manage に引き継ぐようエージェントに指示してください

ワークフロー

1. 意図を特定し、タスクを正規化します。

• 別名を正規タスクに対応付けます
• 自然言語でのロールモードの表現を default/allow-use-union/only-use-union に対応付けます
• ロール作成の表現は、まず role.create-blank の基本処理に正規化し、その後に権限を割り当てます

2. 機能ゲート（CLI）。

• nb CLI が PATH から直接利用できることを確認します
• コマンド組み立てガード：
• コマンド形式は nb <command> [subcommand ...] [flags ...] である必要があります
• nb の後の最初のトークンはコマンド（例：env や api）である必要があり、-e／-t／-j などのフラグは指定できません
• 誤り：nb -e local
• 正しい例：nb api resource list --resource users -e local -j
• 生の JSON 入力ガード（PowerShell／ランタイム）：
• 可能な場合は、インラインの --body より構造化されたボディフラグ（例：--resources、--actions）を優先します
• 生の JSON ボディが必要な場合は、インラインの --body より --body-file を優先します
• --body-file の内容は、BOM なしの UTF-8 でエンコードされた有効な JSON である必要があります
• PowerShell でインラインの --body の JSON 解析に失敗した場合は、ペイロードを --body-file として再生成し、1 回だけ再試行します
• PowerShell では Bash 形式のエスケープされた JSON（例：{\"k\":\"v\"}）を使用しないでください。無効な JSON として解析される可能性があります
• ポリシーペイロードガード（独立したリソース書き込みに関する厳格なルール）：
• ペイロードがない、または無効な場合、事前チェックで api acl roles data-source-resources create|update および api acl roles apply-data-permissions をブロックする必要があります（--body-file を優先し、--body も使用できます）
• これらの書き込みでは、ペイロードに usingActionsConfig: true と空でない actions[] を含める必要があります
• create/view/update/export/importXlsx アクションでは、それぞれのアクションに空でない fields[] を含める必要があります
• 各アクション項目では、次のいずれかを使用してスコープの紐付けを明示する必要があります：
• 明示的な ID 紐付けには scopeId
• キーによる解決（all／own など）には scopeKey
• 互換性のある読み戻しペイロードには scope.{id|key}
• ユーザーの意図するスコープが all または own の場合、読み戻しで解決済みの非 null scopeId を確認する必要があります
• ガードに失敗した場合は、CLI 実行前に停止し、修正可能なエラーを返します
• パラメーター安全性ガード：
• リソース権限のコマンド形式ガード：
• roles data-source-resources で使用できるのは create|get|update のみです。list は呼び出さないでください
• roles data-source-resources get|update では、次のいずれかをロケーターとして指定する必要があります：
• --filter-by-tk <resource_config_id>
• --data-source-key <data_source_key> --name <collection_name>
• アクションレベルの独立権限を読み戻すには、roles data-source-resources get ... --appends actions を使用します
• 独立権限を統合して書き込む場合（単一または一括のコレクション）、roles apply-data-permissions --filter-by-tk <role_name> --body-file <path> を優先します
• roles data-sources-collections list では、デフォルトのロケーターとして --data-source-key <data_source_key> を使用します。互換性が必要な場合にのみ --filter を使用します
• コレクション／フィールドの解決には、主なメタデータソースとして nb api resource list --resource collections --filter '{}' --appends fields -j を優先します
• roles desktop-routes add では、リクエストボディに数値のルート ID の JSON 配列を指定する必要があります
• パラメーターが不確か、未解決、または型が一致しない状態で書き込みコマンドを実行してはいけません
• ポータル権限コマンドガード：
• nb portal list -j を使用してポータルを検索します
• nb api acl roles multi-portals list|add|remove が現在のランタイム Swagger キャッシュから解決できることを確認します
• add または remove には、解決済みのポータル uid のみを渡します。タイトル、パス、推測した uid は渡さないでください
• 書き込み前に現在の関連付けを読み取り、書き込み直後に読み戻します。許可／拒否の要求がすでに満たされている場合は何も行いません
• ACL の検索／書き込み前に実行ベースディレクトリを固定します（タスク全体で同じ安定したプロジェクトルートを使用します）
• ACL 書き込み前に次の実行ガード手順を実行します：
• nb env list
• nb env update <current_env_name>
• nb api acl --help
• nb api acl roles --help
• フェイルクローズポリシー：
• nb api acl --help または nb api acl roles --help が失敗した場合は停止し、機能境界に関するメッセージを返します。場当たり的なスクリプト実行に切り替えてはいけません
• 直接 CLI を使って現在の環境コンテキストを確認します：nb env list を実行し、* が付いた行から現在の環境を特定します
• 環境が設定されていない、または現在の環境がない場合は、書き込みを停止し、エージェントに nocobase-env-manage を呼び出すよう案内します。その後、環境を復旧してから ACL タスクを再実行します
• ランタイムコマンドキャッシュがない、古い、またはコマンドスキーマが変更されている場合は、nb env update <current_env_name> を実行します
• ランタイムの更新に失敗した場合は、書き込みを停止して CLI エラーを返します。環境／認証／ランタイムの復旧には nocobase-env-manage を呼び出すようエージェントに案内します。ただし、プラグインを有効にする必要があると CLI エラーに明記されている場合に限り、nocobase-plugin-manage を案内します
• トークンがない、または無効な場合は、書き込みを停止し、エージェントに nocobase-env-manage を呼び出すよう案内します
• ランタイムコマンド名は、intent-to-tool-map-v1 とコマンドヘルプの調査を通じて解決します

3. 書き込みの前に計画します。

• 変更案、読み戻しの確認ポイント、影響範囲を列挙します
• 影響の大きい書き込みには明示的な確認を必須とします
• リソース権限を書き込む場合は、次の情報を含めます：
• データソースキー
• 解決済みの対象コレクション一覧
• アクション一覧
• スコープの選択（省略時はデフォルトで all）
• 解決済みのスコープバインディング（scopeId / スコープキー）
• フィールドポリシー（ユーザーが制限を指定していない場合、デフォルトですべてのフィールド）
• フィールド制限が省略された各アクションの、解決済みの全フィールド一覧

4. 一度に1つのタスクを実行します。

• 書き込みは最小限にし、対象範囲を限定します
• swagger から生成された ACL 専用ランタイムコマンドを優先します
• permission.data-source.resource.set では、resources[] ペイロードをすべて含む nb api acl roles apply-data-permissions による統合書き込みを優先します。roles data-source-resources create|update は互換性のための手段としてのみ使用します

5. 読み戻しによる検証。

• 対象データが依頼どおりに変更されたことを検証します
• 簡潔な証拠ブロックを含めます
• 独立したリソース権限の検証でアクションレベルのスコープ／フィールドを確認する場合は、nb api acl roles data-source-resources get ... --appends actions を使用します
• Portal エントリアクセスでは、正確な roleName + multiPortalUid の許可を読み戻し、明示的なアクセスと allowNewMultiPortal を区別します

6. リスクと境界の報告。

• 成功した場合も、影響の大きい変更に関する注意事項を返します
• サポート対象外の経路については、わかりやすい境界の説明を返します

ツール利用ポリシー

優先する書き込み経路：

• ACL 専用の CLI ランタイムコマンド（swagger 生成）
• ユーザーロールのメンバーシップを書き込む場合は、まず専用の ACL コマンド経路（nb api acl roles users add/remove）を優先します

ガード付きの代替経路（ユーザーロールのメンバーシップのみ）：

• 専用の ACL メンバーシップコマンドが利用できず、allow_generic_association_write=true の場合にのみ許可されます
• 汎用の nb api resource update/list は、users.roles の関連付け操作にのみ使用します
• 書き込み後は必ず読み戻しを行います

厳格な制限：

• 直接 HTTP による代替手段は使用しません
• データベースを直接変更しません
• ACL 専用のランタイムコマンドが存在する場合、ACL ポリシーの書き込みに汎用のリソースコマンドを使用しません
• ACL のサポート状況を判断する際は、同じロックされた base-dir で nb api acl --help と nb api acl roles --help を確認してから、機能の有無を結論付けます
• ランタイムコマンドの検出を回避するために、一時的な .js/.ps1/.sh の実行スクリプトを作成しません

安全性ゲート

影響の大きい ACL アクション：

• グローバルロールモードの変更
• 広範なシステムスニペット（ui.*、pm、pm.*、app）
• 広範なデータソースアクション（destroy、広範なエクスポート／インポートの許可）
• 多数のユーザーへのロール割り当て

安全ルール：

• 影響の大きい書き込みには、明示的な確認を必須とします
• 適用前に影響範囲の概要を含めます
• 書き込み後は必ず読み戻しによる検証を行います

機能境界に関する説明

現在の CLI／ランタイム／ツールのポリシーでサポートされていないシナリオの場合：

• このシナリオは現在、このスキルの機能またはガバナンスポリシーによってブロックされています。
• NocoBase の管理 UI で操作を完了するか、利用可能であればガード付きの代替オプションを有効にしてください。
• ご希望であれば、正確な UI の操作手順とフィールドの候補をご案内できます。

検証チェックリスト

• タスクが正規のタスクに正規化されている
• 書き込み前に必要な入力がすべて揃っている
• CLI の機能ゲートを通過している（nb env list から環境コンテキストを直接取得でき、ランタイムコマンドを解決できる）
• 環境／認証の前提条件が満たされているか、明確な引き継ぎ手順が提示されている
• ランタイムコマンド名がコマンドマップ／ヘルプから解決されている
• 実行ガードの証拠に、ロックされた base-dir と、nb env list、nb env update <current_env_name>、nb api acl --help、nb api acl roles --help が含まれている
• すべての書き込みに、直後の読み取りによる証拠がある
• permission.data-source.resource.set では、書き込み前にデータソース、解決済みコレクション、アクション、スコープが確認されている
• ユーザーがスコープを指定していない場合、確認／読み取り結果で、適用されたデフォルトのスコープとして all が示されている
• permission.data-source.resource.set では、同じ書き込みサイクル内の読み取りで usingActionsConfig=true とアクションレベルのスコープ／フィールドが確認されている
• 独立した権限のアクションレベルの検証では、読み取りコマンドに --appends actions が含まれている
• scope=all|own の場合、読み取り結果で null 以外の scopeId と一致するスコープキーが示されている
• フィールドルールをユーザーが指定していない場合、フィールド名の空でないリストとして全フィールドのデフォルトが明示的に適用されている
• 全フィールドのデフォルトを使用する場合、読み取り結果のフィールドリストが要求された名前と一致し、システムフィールドが暗黙に失われていない
• コマンドレベルの事前チェックにより、形式不正な独立リソースのペイロードは実行前にブロックされる（usingActionsConfig、actions、スコープのバインド scopeId|scopeKey、fields の欠落／無効）
• 実行前に、roles data-source-resources get|update のロケーターが明示されている（filterByTk または data-source-key + name）
• コレクション／フィールドのメタデータは resource collections の読み取りパスで解決されている。roles data-sources-collections list はロール向けビューとの互換性のためにのみ使用される
• roles desktop-routes add では、数値のルート ID を含む JSON 配列のボディが使用されている
• Portal アクセスの書き込みでは、有効な Portal を 1 つ解決し、正確なロール／Portal キーを使用し、直後に読み取りを行っている
• パラメーターに不確実性がある場合や型が一致しない場合、書き込みを実行しない
• グローバルなロールモードのタスクでは role_name を必要としない
• 保存されるすべてのカスタムスコープ／ユーザーフィルターについて、末端フィールドのフロントエンド演算子グループとの適合性が確認されており、日付フィールドに数値比較演算子が使用されていない
• 境界条件に関するメッセージが明確で、実行可能な内容になっている

最小テストシナリオ

1. global.role-mode.get と global.role-mode.set を実行し、読み戻しで確認します。
2. role.create-blank を実行し、ロールが存在し、保守的なデフォルト値が設定されていることを確認します。
3. permission.data-source.global.set を実行し、戦略のアクションを確認します。
4. permission.data-source.resource.set にビジネスコレクション名を指定すると、対象データソースから実際のコレクション名が自動的に解決されます。
5. permission.data-source.resource.set でコレクションの一致候補が複数ある場合、書き込み前にどれを選ぶか確認します。
6. permission.data-source.resource.set でアクションが指定されていない場合、書き込み前に確認を求めます。
7. permission.data-source.resource.set でスコープが指定されていない場合、デフォルトで all が設定されます。この設定を確認画面に表示し、書き込み前にユーザーが変更できるようにします。
8. permission.data-source.resource.set で view を指定し、フィールド制限を指定しない場合、明示的な空でないフィールドリストを用いて、デフォルトで全フィールドに対する権限を適用します。
9. permission.data-source.resource.set で scope=all を指定した場合、組み込みのスコープバインディング（key=all に対する null 以外の scopeId）を明示的に書き込みます。
10. permission.data-source.resource.set では、データソース、解決済みコレクション、アクション、スコープを含む書き込み前の確認を必須とします。
11. permission.data-source.resource.set では、独立したポリシーを完全なペイロード（usingActionsConfig + actions + scope + fields）として一度に書き込み、複数回に分けてパッチを適用しません。
12. 厳格モードの user.assign-role では、専用のメンバーシップコマンドが利用可能な場合はそれを使用し、利用できない場合は境界ガイダンスを表示して処理をブロックします。
13. user.assign-role のガード付きフォールバックは、専用コマンドが利用できず、ガードモードが明示的に有効になっている場合に限り実行します。
14. risk.assess-role は、スコア、根拠、推奨事項を返します。
15. メタデータにシステムフィールドが含まれる場合、全フィールドのデフォルト設定により、読み戻しでもシステムフィールドが保持されます。
16. base-dir が誤っている場合、またはランタイムコマンドキャッシュがない場合は、フェイルクローズし、場当たり的なスクリプトへのフォールバックではなく、境界メッセージを表示します。
17. permission.portal.access.set は、明示的に指定された 1 つのロールと Portal の関連付けを、読み戻しとともに許可および取り消します。

参照資料の読み込みマップ

参照資料	読み込む場面	備考
references/intent-presets-v1.md	意図の正規化とデフォルト設定	グローバルロールモードの表現を含みます
references/intent-to-tool-map-v1.md	ランタイムコマンドの解決	論理タスクを CLI コマンドパターンに対応付けます
references/execution-guard-template.md	ACL のすべての書き込みタスク	base-dir のロックとフェイルクローズチェック用の固定された事前チェックコマンドテンプレートです
references/result-format-v1.md	出力の表示	リスクカードと機能のパスを含みます
references/configuration.md	ACL ポリシーの詳細	データソースとスコープに関する詳細なガイダンスです
references/independent-permissions.md	リソースレベルの権限の書き込み	usingActionsConfig + actions + fields + scope による完全な書き込みポリシーです
references/portal-access.md	既存の Portal へのアクセスの許可または取り消し	ロールと Portal の公式関連付けコマンドおよび読み戻しです
nocobase-utils トピック filter： フィルター条件の形式	カスタムスコープ／ユーザーフィルターの作成	最初にスキルを読み込みます。終端フィールドの演算子の許可リストが必須です。固定の CLI ロケーター／制御オブジェクトには使用しません
tests/capability-test-plan.md	機能マトリックス	v2 ドメインに準拠しています
tests/test-playbook.md	受け入れ回帰テスト	プロンプト優先の TC01、TC02、TC04～TC20 と、ランタイムのエビデンスコマンドを含みます
references/refactor-plan-v2.md	機能の不足点と展開計画	CLI の移行に関する注記を含みます
tests/README.md	ランタイム検証	プレイブックの実行フローとレポートに関する注記です

参考資料

• Intent Presets v1
• Intent To Tool Map v1
• Execution Guard Template
• Result Format v1
• ACL Configuration Details
• Table Independent Permissions
• Portal Access
• Filter Condition Format
• ACL Capability Test Plan
• ACL Test Playbook
• ACL Refactor Plan v2
• ACL Capability Tests
• NocoBase ACL Handbook [verified: 2026-04-11]