Request Access for Brain & Source Management

背景：把"权限被拒"变成"审批入口"

Gumloop 权限基于 Composable Roles。严格策略会拦下无权用户。访问请求流（Action Requests）让"被拦下"不再是终点，而是引导式审批入口。v10.10.0 把 Brain 和源管理纳入可请求范围。

┌──────────────────────────────────────────────────────────────────────┐
│              访问请求流 — 把"权限被拒"变成"审批入口"                     │
├──────────────────────────────────────────────────────────────────────┤
│  用户访问无权资源（agent/workflow/file/team/[v10.10.0] Brain）           │
│         │  不再是死胡同                                                │
│         ▼                                                            │
│  ┌─────────────────────┐                                             │
│  │  Request Access 按钮  │ ── 用户主动发起申请                          │
│  └─────────────────────┘                                             │
│         │  系统识别"正确的审批人"                                       │
│         ▼                                                            │
│  ┌─────────────────────────────────────────────────────────────┐    │
│  │  三通道送达：Gumloop Inbox / Slack DM / Email                │    │
│  └─────────────────────────────────────────────────────────────┘    │
│         │                                                            │
│         ▼  审批人一键 Approve / Reject —— 请求生命周期闭环              │
└──────────────────────────────────────────────────────────────────────┘

目标

1. 消除"无权限死胡同"——被拦用户有明确下一步（发起请求）
2. 自动路由到正确审批人——系统识别 owner/admin，用户无需知道找谁
3. 降低审批摩擦——Slack 一键审批，不离开工作流
4. 统一留痕——所有权限变更经请求流，满足合规审计

2.1 工作流程（三步）

步骤	动作
① 发起	用户访问无权资源（含 Brain/源管理），看到 Request Access 按钮
② 送达	请求发给正确审批人（owner 或 workspace admin），经 Email + Slack（如已连）
③ 审批	审批人审阅，一键批准或拒绝

2.2 请求路由：谁收到请求

系统按资源类型自动识别审批人（无需用户知道找谁）：

资源类型	谁收到请求
Agents	agent owner
Skills	skill owner
Workflows	workflow owner
Files	文件 owner，或创建该文件的 agent 的 owner
Teams	workspace admin
Organization roles	organization admin
Brain / 源管理（v10.10.0 扩展）	由 Composable Roles 策略层级决定（team admin / org admin） [文档已验证 + 推断]

2.3 三通道送达 + Slack 一键审批

┌──────────────────────────────────────────────────────────────────────┐
│  请求送达通道                                                          │
├──────────────────────────────────────────────────────────────────────┤
│  ① Gumloop Inbox（站内）—— 始终可用                                    │
│     通知含：请求人名 / 请求的资源或角色 / 提交时间                        │
│     四个响应选项：Approve / Open / Reject / Dismiss                     │
│                                                                      │
│  ② Slack DM（如审批人已连 Slack）—— 一键审批                            │
│     DM 含 Approve / Deny 按钮，单击即决，无需离开 Slack                   │
│     ⚠️ 当前仅 team / organization 访问请求支持 Slack 一键审批            │
│        其他请求类型正逐步推出                                            │
│                                                                      │
│  ③ Email —— 兜底通道                                                   │
│     任一方未连 Slack 时仅走 Email                                       │
└──────────────────────────────────────────────────────────────────────┘

2.4 Inbox 审批四选项

选项	行为
Approve	立即批准，授予访问权
Open	先查看请求详情再决定
Reject	不可逆地拒绝
Dismiss	忽略请求，不采取行动

已处理请求移到 Resolved tab 供查阅，可用 Clear 清理。

2.5 请求生命周期

状态	含义
Pending	请求已发送，等待决定
Accepted	审批人批准，访问已授予
Rejected	审批人拒绝
Expired	请求在过期窗口内未被处理

🔴 请求只能被处理一次。若被拒绝，请求人之后可重新提交新请求。

模块 A — 发起请求

ID	触发场景	系统行为	优先级
A1	访问无权 Brain/源管理	显示 Request Access 按钮（非死胡同）	P0
A2	点击 Request Access	创建请求记录，状态置 Pending	P0
A3	创建请求	按资源类型 + 角色策略识别正确审批人	P0

模块 B — 多通道送达

ID	触发场景	系统行为	优先级
B1	请求创建	始终送达 Gumloop Inbox	P0
B2	双方都已连 Slack	送达 Slack DM（含 Approve/Deny 按钮）	P0
B3	team/org 访问请求	Slack 一键审批可用	P0
B4	任一方未连 Slack	仅经 Email 送达	P0
B5	其他请求类型	Slack 一键审批逐步推出	P1

模块 C — 审批与生命周期

ID	触发场景	系统行为	优先级
C1	审批人点 Approve	状态置 Accepted，授予访问权	P0
C2	审批人点 Reject	状态置 Rejected（不可逆）	P0
C3	审批人点 Dismiss	忽略请求，不采取行动	P1
C4	超过过期窗口	状态置 Expired	P0
C5	请求已处理	移到 Resolved tab，只能处理一次	P0
C6	请求被拒后	请求人可重新提交新请求	P1