| name | auth-manager |
| version | 1.3.5 |
| user-invocable | true |
| description | 数据权限管理技能：支持资源权限查询与权限申请。 先判定“查询权限”还是“申请权限”，再按资源类型执行对应接口。 当用户提出“申请权限”、“查是否有权限”、“给某资源授权”时使用。 |
| metadata | {"openclaw":{"skillKey":"auth-manager"}} |
| allowed-tools | Bash(curl *), Bash(kweaver call *) |
| argument-hint | ["权限需求描述，可包含 resource_type/resource_id/resource_name/applicant_id/applicant_name/applicant_account"] |
数据权限管理
渐进式加载: 核心概念 → 认证与 Token → 申请人发现 → 资源发现 → 部门查询（独立） → 用户组查询（独立） → 用户组成员查询（独立） → 应用账户查询（独立） → 管理控制台用户搜索（独立） → 用户角色查询（独立） → 申请参考 → 查询参考 → 数字员工查询（独立） → 行列规则接口（独立）
文档指南: README.md · 共享约束: core/core-constraints.md
本 skill 是权限管理统一入口，负责意图识别、参数校验、接口路由；HTTP 字段与示例在 references/，枚举清单在 resources/。
核心能力
技能入参
技能接受以下入参，大模型在调用技能时建议按此结构传递：
{
"query": "用户权限诉求（必须）",
"context": "补充上下文，可包含资源ID、申请人、时间等（可选）"
}
入参说明
| 参数名 | 类型 | 必填 | 说明 |
|---|
query | string | 是 | 第一优先级：识别「查询权限」或「申请权限」 |
context | string | 否 | 填充 resource_id、resource_name、resource_type、applicant_id、applicant_name、applicant_account、resources、action 等，不替代 query 的意图判定 |
入参使用场景总览
| 场景 | query | context |
|---|
| 申请某类资源权限（数据视图 / 知识网络 / 行列规则等） | ✅ 须体现「申请 / 授权 / 开通」等 | ✅ 建议含 resource_type + (resource_id 或 resource_name) + (applicant_id 或 applicant_name/applicant_account) + 操作列表 |
| 批量查询是否具备指定操作 | ✅ 须体现「查询权限 / 是否可查 / 能否操作」等 | ✅ 建议含 (resources 或 resource_name) + object_type + 待校验 action |
| 仅澄清枚举（读文档） | ✅ 说明查阅目的 | 可选 |
入参职责区分
重要：不得混用职责。
| 入参 | 职责 |
|---|
query | 意图路由：只用于判定走申请还是查询（及是否属于本 skill） |
context | 字段补齐：提供调用接口所需的结构化信息，不改变 query 已确定的入口 |
使用优先级
query 始终必填，决定流程入口。context 在缺参时补齐；不得单独凭 context 反转 query 的「申请 / 查询」判定。- 缺
resource_id 时先做资源发现：通过资源检索接口获取候选并回填 ID（见 references/resource-discovery.md）。
- 申请分支缺
applicant_id 时先做申请人发现：通过用户名/账号检索接口获取候选并回填 ID（见 references/applicant-discovery.md）。
- 枚举与硬约束以
core/core-constraints.md 为准。
前置条件
- 可用的
Authorization: Bearer <access_token>（获取与携带方式见 references/authentication.md）
- 可访问的 auth-service（如
http://127.0.0.1:8155）
- 请求头
Content-Type: application/json
摘要：用 kweaver call 时，可 kweaver auth login 从磁盘凭据自动带 Token；也可设置 KWEAVER_TOKEN + KWEAVER_BASE_URL 用环境变量静态 Token（CI 常用）。用 curl/Postman/脚本 时把 Token 放进 Authorization: Bearer … 或读自定义变量（详见上文链接）。
关键约束
详细约束（单一事实来源）: core/core-constraints.md
- 先意图、后请求：必须先完成步骤二「独立安全拦截 · 写操作」与「查询 vs 申请」判定及参数校验，再发 HTTP。
- 枚举原值：
resource_type、auth_operations、applicant_type 等与文档及 enum.go 一致，禁止同义词。
- 类型匹配：操作码必须与资源类型可搭配。
- 行列规则：
data_view_row_column_rule 的 row_rules 须对照 examples/row-rules.md。
- 申请前先查：申请分支在提交
/data-auth/apply 前，需先按 references/auth-query.md 校验申请人是否已具备目标操作；若已具备则直接返回“无需申请”。
- 鉴权失败重试：所有接口遇到
401/403/Unauthorized/token expired 时，必须先刷新 token，再重试原请求 1 次。
- 防死循环：每个接口请求最多 2 次（首次 + 重试一次）；二次失败后立即返回原始错误，不得继续循环。
- 失败处理：须保留接口原始错误信息，不得假称成功。
- 进度硬约束：每完成门禁或分支内任一步，须立即输出一次「任务进度清单」；当前步未输出进度前不得进入下一步；失败即停，不得将后续步骤标为已完成。
- 写操作与安全拦截：步骤二（意图识别）内最先执行「独立安全拦截 · 写操作」全条（见下文 §1) 意图识别）。命中业务数据写操作硬拦截，或敏感初检触发且未能满足「治理写操作例外」与放行语义时，须立即终止全流程，不得进入查询/申请分支及任何 HTTP；不得代用户生成或解释如何执行 DML、DDL、停机或可类比写指令；触发拦截时不得假称已放行。
门禁机制（必须先执行）
本节步骤一～三在上下文已校验时可跳过重复执行（如 Token 仍有效），但不可跳过进度输出；步骤四起不得省略。
0) Token 预检（每次回答前必须执行）→ 步骤一
- 跳过条件（上下文已校验）：当前对话上下文中，已有可复核的等价结论（例如前文已成功
kweaver auth whoami / kweaver auth status 显示 active 且未过期）。满足时不得重复登录，但必须本步输出进度：「步骤一（Token 预检）：已跳过（上下文已校验）」或 「已校验通过（复用上下文）」，并一句指明依据。
- 非跳过：先执行
kweaver auth status。
- 若状态为
active：继续后续流程。
- 若不可用（过期/缺失/401）：按
references/authentication.md 的“预检与刷新标准流程”先刷新再继续。
- 若使用
KWEAVER_TOKEN 静态凭据：不支持 refresh 换发，失效时需替换新 token。
- 若 Token 缺失或过期且无法刷新：立即停止，提示用户登录或替换 Token。
0.1) 接口统一鉴权重试（所有接口）
- 适用于本技能下所有 HTTP 接口（申请、查询、资源发现、申请人发现、数字员工、行列规则 CRUD）。
- 若首次调用返回
401/403/Unauthorized/token expired：先执行 token 刷新，再按同参数重试原请求一次。
- 重试后仍失败：立即停止并返回原始错误。
- 严禁无上限重试；必须显式维护“已重试一次”状态，防止死循环。
1) 意图识别 → 步骤二
目标：在查询/申请分流前完成安全拦截，并判定流程入口。
2) 参数校验 → 步骤三
- 申请最小集：
resource_type、applicant_type、auth_operations、expired_at + (resource_id 或 resource_name) + (applicant_id 或 applicant_name/applicant_account)。
- 查询最小集：
action + (resources 或 (resource_name + object_type))。
- 缺参则补齐，禁止臆造 ID 或枚举。
2.1) applicant 存在性校验（实现对齐）
- 仅当
applicant_id 与当前用户 ID 不一致时执行存在性校验。
applicant_type=digital_employee：通过 GET /api/dip-studio/v1/digital-human/{id} 校验。- 其他
applicant_type：通过 user-management / authorization 相关接口校验。
- 校验失败时必须停止后续申请并返回原始错误。
2.2) 申请前权限预检（新增）
- 仅适用于申请分支，且在
resource_id、applicant_id、auth_operations 补齐后执行。
- 使用
/api/auth-service/v1/data-resource/operations 按同资源、同操作、同申请人进行预检（subject=applicant）。
- 若预检结果对目标操作全部
effect=true：直接返回“该用户已具备权限，无需重复申请”。
- 若存在
effect=false：继续调用 /api/auth-service/v1/data-auth/apply 发起申请。
3) 路由到分支 → 步骤四
- 完成步骤一～三后，根据意图进入 查询分支 或 申请分支（见下文「子流程衔接」与「任务进度清单」）。
- 不得在步骤四之前调用
POST …/data-resource/operations 或 POST …/data-auth/apply。
子流程衔接（序号连续）
- 总入口固定执行 步骤一～四（Token 预检 → 意图识别 → 参数校验 → 路由到分支）。
- 路由到 查询分支 时，继续执行 步骤 5～9（见「任务进度清单（阶段：查询）」及
references/auth-query.md）。
- 路由到 申请分支 时，继续执行 步骤 5～12（见「任务进度清单（阶段：申请）」及
references/auth-apply.md）。
- 动态编号规则：令 S 为进入当前分支前已完成的最后一步编号（通常为 4），分支内全局步号为 第 S+1 步 至 第 S+N 步。
- 子流程内引用「第 N 步」均以该连续编号为准；禁止跳步、并步、倒序。
查询分支（步骤 5～9）
- 资源发现（按需）：缺
resources[].object_id 时，按 references/resource-discovery.md 检索并回填；多候选须澄清。
- 枚举与类型校验：核对
object_type、action 与 resources/resource.md、resources/operations.md。
- 构造查询请求体：按 references/auth-query.md 组装
resources、action；可选 subject。
- 调用权限查询接口：
POST /api/auth-service/v1/data-resource/operations；失败即停，保留原始错误。
- 总结交付：返回各资源
effect、最小口径（资源 ID/类型、操作列表、访问者），标注 流程完成。
申请分支（步骤 5～12）
- 资源发现（按需）：缺
resource_id 时，按 references/resource-discovery.md 检索并回填。
- 申请人发现（按需）：缺
applicant_id 时，按 references/applicant-discovery.md 检索并回填。
- 数字员工发现（按需）：
applicant_type=digital_employee 且仅有名称时，按 references/digital-human-discovery.md 确认 ID。
- 行列规则校验（按需）：
resource_type=data_view_row_column_rule 时，对照 examples/row-rules.md 校验 row_rules / resource_attributes。
- applicant 存在性校验（按需）：
applicant_id 与当前用户不一致时执行（见上文 2.1）。
- 申请前权限预检：按 references/auth-query.md 校验目标操作；全部
effect=true 则返回「无需申请」并标注 流程完成。
- 构造并调用申请接口：按 references/auth-apply.md 组装并
POST …/data-auth/apply；失败即停，保留原始错误。
- 总结交付：返回申请结果（成功/失败、申请单信息或原始错误）、所用资源与操作口径，标注 流程完成。
进度显示规范（必须执行）
- 总入口与查询/申请分支统一使用 连续步骤编号 展示进度。
- 每完成一步，立即输出一次进度，不得仅在最后汇总时输出。
- 进度输出须包含：阶段名称、当前已完成步骤、下一步计划。
- 若当前步骤尚未输出进度，不得进入下一步。
- 缺步、跳步或步骤失败时，立即停止并说明原因；不得将失败后的步骤标为已完成。
- 分支结束时须在清单中标注最后一步「已完成」，并追加 「流程完成」。
- 步骤一、二复用上下文时，以及进入查询/申请分支后，均继续使用同一模板（更新「已完成 / 待完成 / 进行中」状态）。
推荐模板：
## 📋 任务进度清单（阶段：总控制台）
- [x] 已完成 · 步骤N（步骤名称）
- [ ] 待完成 · 步骤N+1（步骤名称）
标准进度输出示例
## 📋 任务进度清单（阶段：查询）
- [x] 已完成 · 步骤5（资源发现）
- [x] 已完成 · 步骤6（枚举与类型校验）
- [ ] 进行中 · 步骤7（构造查询请求体）
- [ ] 待完成 · 步骤8（调用权限查询接口）
- [ ] 待完成 · 步骤9（总结交付）
## 📋 任务进度清单（阶段：申请）
- [x] 已完成 · 步骤5（资源发现）
- [x] 已完成 · 步骤6（申请人发现）
- [ ] 进行中 · 步骤10（申请前权限预检）
- [ ] 待完成 · 步骤11（构造并调用申请接口）
- [ ] 待完成 · 步骤12（总结交付）
路由规则
1) 资源发现（缺 ID 时必走）
data_view：GET /api/mdl-data-model/v1/data-views?name=<resource_name>。knowledge_network：GET /api/bkn-backend/v1/knowledge-networks?name_pattern=<resource_name>&offset=0&limit=20。- 多候选时必须澄清目标资源；单候选可自动回填
resource_id。
2) 申请人发现（申请缺 applicant_id 时必走）
- 优先按账号精确匹配：
GET /api/user-management/v1/account-match?account=<applicant_account>。
- 兜底按用户名搜索：
GET /api/user-management/v1/search-in-org-tree?keyword=<applicant_name>&type=user&role=<role>&offset=0&limit=20。
- 多候选时必须澄清目标申请人；单候选可自动回填
applicant_id。
- 若回填后的
applicant_id 与当前用户一致，可跳过存在性校验并继续申请流程。
2.1) 管理控制台用户搜索（全量 / 按部门）
- 接口：
GET /api/user-management/v1/console/search-users/{fields}。
name 非必填；可使用 department_id、account、code 等条件检索。role 为必填 query 参数，且服务端会校验当前 token 用户是否拥有该角色。department_id 缺失或 -1（未分配组）时，仅 super_admin/sys_admin/sec_admin/audit_admin 可用。- 详细规则见 references/console-user-search.md。
2.2) 用户角色查询（按用户 / 按角色）
- 按用户查角色：
GET /api/user-management/v1/users/{user_ids}/{fields}（fields 包含 roles，且 query 必填 role）。
- 按角色查成员：
GET /api/user-management/v1/role-members/{roles}。
- 角色值需使用原始英文 code（
super_admin/sys_admin/audit_admin/sec_admin/org_manager/org_audit/normal_user）。
- 详细规则见 references/user-role-discovery.md。
2.3) 组织对象检索（部门 / 用户组 / 应用账户）
3) 数字员工查询（独立检索）
- 列表：
GET /api/dip-studio/v1/digital-human。
- 详情：
GET /api/dip-studio/v1/digital-human/{id}。
- 当
applicant_type=digital_employee 且仅有名称时，先查询候选再确认 ID。
4) 权限申请（/data-auth/apply）
- 支持的
resource_type：见 resources/resource.md。
resource_id、auth_operations 为数组；expired_at 为秒级时间戳。data_view_row_column_rule：必填 resource_attributes；row_rules 见 examples/row-rules.md。data_view：可传 apply_type（可为空字符串）。
5) 权限查询（/data-resource/operations）
文档结构
auth-manager/
├── README.md # 文档指南与分层索引
├── SKILL.md # 本文件 - 主入口
├── core/
│ ├── core.md # 核心概念 (L1)
│ └── core-constraints.md # 共享约束（单一事实来源）
├── references/ # HTTP 模板与示例 (L2)
│ ├── authentication.md # Token 获取与 Authorization 携带
│ ├── applicant-discovery.md # 用户名/账号到 applicant_id 的检索与回填
│ ├── resource-discovery.md # 资源名到 resource_id 的检索与回填
│ ├── department-discovery.md # 部门查询（独立）
│ ├── group-discovery.md # 用户组查询（独立）
│ ├── group-members-discovery.md # 用户组成员查询（独立）
│ ├── app-account-discovery.md # 应用账户查询（独立）
│ ├── console-user-search.md # 管理控制台用户搜索（全量/按部门）
│ ├── user-role-discovery.md # 用户角色查询（按用户/按角色）
│ ├── digital-human-discovery.md # 数字员工列表/详情查询（独立）
│ ├── data-model-row-column-rules.md # data_model 视图行列规则增删改查（独立）
│ ├── auth-apply.md # 申请接口模板
│ └── auth-query.md # 查询接口模板
├── resources/
│ ├── resource.md
│ ├── operations.md
│ └── accessors.md
└── examples/
└── row-rules.md
渐进式加载指南
用户请求
│
├─ 仅需了解能力与端点 ──▶ core/core.md
│
├─ Token / Bearer / kweaver CLI ──▶ references/authentication.md
│
├─ 缺申请人ID（用户名/账号补齐） ──▶ references/applicant-discovery.md
│
├─ 缺资源ID（资源名补齐） ──▶ references/resource-discovery.md
│
├─ 查部门 / 组 / 组成员 / 应用账户 ──▶ references/department-discovery.md, references/group-discovery.md, references/group-members-discovery.md, references/app-account-discovery.md
│
├─ 查全部用户 / 按部门查用户 ──▶ references/console-user-search.md
│
├─ 查询用户角色 / 角色成员 ──▶ references/user-role-discovery.md
│
├─ 申请权限 / 构造 apply 体 ──▶ references/auth-apply.md + resources/*
│
├─ 批量查询是否可操作 ──▶ references/auth-query.md + resources/*
│
├─ 搜索数字员工（独立） ──▶ references/digital-human-discovery.md
│
├─ 查询行列规则 CRUD（独立） ──▶ references/data-model-row-column-rules.md
│
├─ 行列规则 row_rules ──▶ examples/row-rules.md + core/core-constraints.md
│
└─ 争议或完整门禁 ──▶ SKILL.md + core/core-constraints.md
快速导航
📋 任务进度清单（阶段：总控制台）
📋 任务进度清单（阶段：查询）
📋 任务进度清单（阶段：申请）
典型调用
/auth-manager 给用户申请 data_view 的 data_query 权限
/auth-manager 申请 knowledge_network 的查询与详情权限
/auth-manager 给某 data_view 申请行列规则权限（rule_apply）
/auth-manager 检查某个 data_view 是否具备 view_detail 权限
/auth-manager 查询“销售订单明细视图”当前用户是否有 data_query（未提供资源ID）
/auth-manager 给账号 zhangsan 开通“销售订单明细视图”的 data_query 权限（未提供用户ID）
/auth-manager 查询某个部门下的用户并按账号筛选
/auth-manager 根据角色查询成员用户（super_admin,sys_admin）
/auth-manager 查询应用账户列表（app）并定位目标账户
示例：未提供资源ID也可查询权限
用户输入：
/auth-manager 查询“销售订单明细视图”我是否有 data_query 权限
技能执行（对应「阶段：查询」进度清单）：
1) 步骤一～四：Token 预检 → 意图=查询 → 参数校验 → 路由查询分支
2) 步骤5：发现缺少 resources[].object_id，触发资源发现
3) 调用 GET /api/mdl-data-model/v1/data-views?name=销售订单明细视图
4) 若仅 1 个候选：回填 object_id，构造 resources=[{object_id, object_type=data_view}]
5) 步骤6～8：枚举校验 → 构造请求体 → POST …/data-resource/operations，action=["data_query"]
6) 步骤9：返回 effect=true/false，标注流程完成
示例：按用户名补齐用户ID后授权
用户输入：
/auth-manager 给账号 zhangsan 开通“销售订单明细视图”的 data_query 权限
技能执行（对应「阶段：申请」进度清单）：
1) 步骤一～四：Token 预检 → 意图=申请 → 参数校验 → 路由申请分支
2) 步骤5：发现缺少 resource_id，触发资源发现并回填 resource_id
3) 步骤6：发现缺少 applicant_id，调用 GET /api/user-management/v1/account-match?account=zhangsan
4) 回填 applicant_id 与 applicant_name（若缺失）
5) 步骤10：申请前权限预检（subject=applicant）
6) 步骤11～12：构造 apply 体 → POST …/data-auth/apply → 返回申请结果，标注流程完成
