nocobase-acl-manage

目标

将 ACL 和权限治理转化为任务驱动型工作流，让用户能够提出业务目标，同时由技能负责：

• 选择 CLI 命令并组织参数
• 检查能力并实施安全防护
• 确认写入并提供回读证据
• 针对高影响变更进行风险导向说明

范围

• 此技能以 CLI 为主进行读取和写入。
• 任务分为五个领域：
• 角色
• 全局角色模式
• 权限，包括 Portal 入口访问权限
• 用户
• 风险评估
• 每个写入任务都遵循 plan -> confirm -> apply -> readback。
• global role mode 视为全局系统策略，而非针对单个角色的字段。

非目标

• 不通过调用直接 REST 端点来绕过 CLI。
• 不通过临时数据库操作修改 ACL。
• 不创建临时脚本文件来执行 ACL 写入。
• 不调用其他技能来引导环境或插件；在此技能中直接使用 nb 命令。
• 不隐瞒高影响变更的影响范围（全局模式、广泛应用的片段、广泛影响的策略操作）。
• 不声称需要治理审查的工作流能够一键完成。

规范任务模型

A）角色领域

任务	用户目标	必需输入	可选输入
role.audit-all	列出所有角色及可比较的策略摘要	无	data_source_key、output
role.create-blank	使用默认只读基线创建角色（唯一创建模式）	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	为一个数据源中的所有表设置全局策略操作	role_name、global_actions[]	data_source_key
permission.data-source.resource.set	为一个或多个集合设置独立操作	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	为一个或多个用户分配一个角色	role_name、（user_ids[] 或 user_filter）	allow_generic_association_write
user.unassign-role	从一个或多个用户移除一个角色	role_name、（user_ids[] 或 user_filter）	allow_generic_association_write
user.audit-role-membership	检查与角色关联的用户	（role_name 或 user_id）	output

E）风险领域

任务	用户获得的结果	必需输入	可选输入
risk.assess-role	一个角色的风险评分和理由	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，每个目标集合执行一次完整的写入载荷
• 写入载荷必须包含 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；可接受 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	“此角色应访问哪个 Portal？”
access	有条件	无	对于 permission.portal.access.set，必须是 allow 或 deny	“应允许还是拒绝此角色进入该 Portal？”
resource_scope	否	all	必须是 all / own / custom(scope_id or scope_filter) 之一	“应使用哪种数据范围？默认是全部；仅在需要时选择 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，这些运算符仍仅适用于数字。不要将此允许列表机械地应用于固定的 CLI 定位器对象（例如 --filter-by-tk），或命令文档中列出的直接控制筛选条件。

强制澄清门槛

• 最多澄清轮数：2
• 每轮最多提问：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 之前，不要继续
• 对于 permission.data-source.resource.set，如果用户尚未确认最终写入计划，不要写入
• 如果用户要求为特定角色设置角色模式，须澄清并规范化为全局模式更改
• 如果任务意味着要执行写入但缺少目标身份，立即停止并先询问
• 如果 CLI 返回身份验证错误（401、403、Auth required），立即停止，并指示 Agent 将环境/身份验证恢复工作移交给 nocobase-env-manage

工作流

1. 明确意图并规范化任务。

• 将别名映射为规范任务
• 将自然语言中的角色模式表述映射为 default/allow-use-union/only-use-union
• 将创建角色的表述先规范化为 role.create-blank 基线，然后再分配权限

2. 能力门控（CLI）。

• 确认 PATH 中可直接使用 nb CLI
• 命令组装防护：
• 命令格式必须为 nb <command> [subcommand ...] [flags ...]
• nb 后的第一个令牌必须是命令（例如 env 或 api），不能是 -e/-t/-j 等标志
• 错误：nb -e local
• 正确：nb api resource list --resource users -e local -j
• 原始 JSON 输入防护（PowerShell/运行时）：
• 尽可能优先使用结构化请求体标志（例如 --resources、--actions），而不是内联 --body
• 如果必须使用原始 JSON 请求体，优先使用 --body-file，而不是内联 --body
• --body-file 内容必须是有效 JSON，并以 UTF-8 无 BOM 编码
• 如果内联 --body 在 PowerShell 中解析 JSON 失败，则将负载重新生成为 --body-file，并重试一次
• 在 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[]
• 对于每个操作项，必须通过以下方式之一显式绑定范围：
• scopeId（显式 ID 绑定）
• scopeKey（基于键解析，例如 all/own）
• scope.{id|key}（兼容性回读负载）
• 如果用户要求的范围是 all 或 own，回读结果必须显示已解析的非空 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 数组
• 绝不使用不确定、未解析或类型不匹配的参数执行写入命令
• Portal 权限命令防护：
• 通过 nb portal list -j 发现 Portal
• 必须从当前运行时 Swagger 缓存中解析 nb api acl roles multi-portals list|add|remove
• 仅向 add 或 remove 传递已解析的 Portal 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，并从带有 * 标记的行中解析当前环境
• 如果未配置当前环境，则停止写入，并指示 Agent 调用 nocobase-env-manage，待环境恢复后重新执行 ACL 任务
• 如果运行时命令缓存缺失/过期或命令模式已更改，则运行 nb env update <current_env_name>
• 如果运行时刷新失败，则停止写入并返回 CLI 错误；指示 Agent 调用 nocobase-env-manage 以恢复环境/身份验证/运行时，或者仅在 CLI 错误明确指出必须启用插件时调用 nocobase-plugin-manage
• 如果令牌缺失/无效，则停止写入，并指示 Agent 调用 nocobase-env-manage
• 通过 intent-to-tool-map-v1 和命令帮助发现来解析运行时命令名称

3. 写入前先制定计划。

• 列出拟议的变更集、回读检查点和影响范围
• 对于高影响写入，必须获得明确确认
• 对于资源权限写入，请包含：
• 数据源键
• 解析后的目标集合列表
• 操作列表
• 范围选择（未指定时默认为 all）
• 解析后的范围绑定（scopeId / 范围键）
• 字段策略（默认使用all fields，除非用户提供了限制）
• 未指定字段限制时，列出每项操作解析后的完整字段列表

4. 每次只执行一项任务。

• 将写入控制在最小范围内
• 优先使用根据 swagger 生成的 ACL 专用运行时命令
• 对于 permission.data-source.resource.set，优先使用 nb api acl roles apply-data-permissions，并提交完整的 resources[] 载荷以统一写入；仅在兼容性需要时使用 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 时，才允许使用
• 仅对 users.roles 关联操作使用通用的 nb api resource update/list
• 写入后必须回读

严格限制：

• 绝不使用直接 HTTP 备用路径
• 绝不直接修改数据库
• 存在 ACL 专用运行时命令时，绝不使用通用资源命令写入 ACL 策略
• 在判定功能支持状态前，必须在同一个已锁定的 base-dir 中检查 nb api acl --help 和 nb api acl roles --help
• 绝不创建临时 .js/.ps1/.sh 执行脚本来绕过运行时命令发现

安全门槛

高影响 ACL 操作：

• 更改全局角色模式
• 范围较广的系统片段（ui.*、pm、pm.*、app）
• 范围较广的数据源操作（destroy、大范围导出／导入授权）
• 向许多用户分配角色

安全规则：

• 高影响写入必须先获得明确确认
• 应用前提供影响范围摘要
• 写入后始终执行回读验证

功能边界提示

当当前 CLI／运行时／工具策略不支持某种场景时：

• This scenario is currently blocked by capability or governance policy in this skill.
• Please complete the operation in NocoBase admin UI, or enable the guarded fallback option if available.
• If you want, I can provide exact UI navigation steps and field suggestions.

验证清单

• 任务已规范化为规范任务
• 写入前已补齐所有必需输入
• 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
• 对于范围=all|own，读取回查结果显示非空 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，使用精确的角色／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 且范围为 all 时，应写入显式的内置范围绑定（键为 all 的 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. 基础目录错误或缺少运行时命令缓存时，必须安全失败并提供边界提示，不得临时回退到脚本执行。
17. permission.portal.access.set 应授予和撤销一个明确的角色/Portal 关联，并读取回显进行验证。

参考资料加载表

参考资料	使用场景	备注
references/intent-presets-v1.md	意图规范化和默认值	包含全局角色模式的措辞
references/intent-to-tool-map-v1.md	解析运行时命令	将逻辑任务映射到 CLI 命令模式
references/execution-guard-template.md	每项 ACL 写入任务	用于锁定基础目录和执行安全失败检查的固定预检命令模板
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：Filter Condition Format	编写自定义范围/用户筛选条件	请先加载技能；必须遵循末端字段运算符允许列表；不适用于固定的 CLI 定位器/控制对象
tests/capability-test-plan.md	能力矩阵	与 v2 领域保持一致
tests/test-playbook.md	验收回归	采用提示词优先的 TC01、TC02、TC04-TC20，并包含运行时证据命令
references/refactor-plan-v2.md	能力缺口和发布计划	包含 CLI 迁移说明
tests/README.md	运行时验证	操作手册执行流程和报告说明

参考文档

• 意图预设 v1
• 意图到工具映射 v1
• 执行防护模板
• 结果格式 v1
• ACL 配置详情
• 表级独立权限
• 门户访问
• 筛选条件格式
• ACL 能力测试计划
• ACL 测试指南
• ACL 重构计划 v2
• ACL 能力测试
• NocoBase ACL 手册 [verified: 2026-04-11]