Gumloop 功能规格 — Composable Roles

Gumloop v8.7.0 "Moosonee" 确立了 Composable Roles 的核心设计：角色可加、可组合。不同于传统层级式 RBAC（每用户一个角色，权限向下继承），Gumloop 允许成员持有多个角色，有效权限 = 所有角色权限的并集。

角色分为两类：

• Admin 角色（广泛）：Admin、Manager — 覆盖多个领域的管理权
• Feature 角色（聚焦）：Security、Developer、Analytics、Templates — 聚焦单一领域

这种设计解决了「某人需要管理安全策略但不应看到财务数据」的场景 — 只需授予 Security 角色而不给 Admin。

1. 加性优先：授予角色只会增加权限，不会减少。行为可预测
2. 最少特权：从 Member 基线开始，按需叠加最窄的角色
3. 关注点分离：安全、开发、分析、模板管理各自独立为 Feature 角色
4. 减法建模：唯一减少权限的机制是自定义角色（Custom Roles），提供精确的 deny-list 控制
5. 三级裁决：角色天花板 → 逐项分享覆盖 → 自定义角色减法，全部同意才放行

1. 消除角色爆炸：通过组合现有角色覆盖权限矩阵，无需为每个组合创建新角色
2. 安全与便利解耦：Security 角色独立于 Admin，企业可将安全策略控制委托给专人而不授予完全管理权
3. 精确减法控制：自定义角色提供白名单/黑名单/并发限制，满足严格合规场景
4. 跨组织与团队的权限一致性：同一套解析逻辑适用于组织级和团队级资源

角色为加性（additive）且可组合（composable）。成员可同时持有多个角色，最终有效权限 = 所有持有角色权限的并集。Member 是隐式基线 — 所有成员自动拥有 Member 权限，即使未显式分配。

关键行为：

• 授予角色永远增加权限，从不减少
• 移除角色的唯一效果是收回该角色贡献的权限
• 组织角色与团队角色可以共存，互不冲突

注意：Admin 和 Manager 被归类为 "Admin roles" 而非 Feature roles — 它们覆盖多个领域，与聚焦单一领域的 Feature roles 在语义上区分。

团队角色在团队范围内生效，与组织角色并行：

关键规则：

• 组织 Admin 持有 organization:manage_team_access → 可管理任何团队，无论其团队角色
• 团队角色仅影响团队范围内的资源，不影响组织级权限

自定义角色是一个独立的、减法型系统。与标准角色的加性逻辑相反：

• 只移除权限，不授予新权限
• 多个自定义角色组合时，限制叠加（更严）
• 新邀请成员自动加入默认自定义角色

权限解析按以下顺序逐级裁决，全部同意才放行：

关键约束：

• Layer 2（Sharing）不能超越 Layer 1（Roles 天花板）— 分享不能授予角色未覆盖的权限
• Layer 3（Custom Roles）只能从 Layer 1+2 的并集中减去 — 不能反向授予
• 所有三层都必须同意，操作才能成功

• 权限可视化面板：Admin 在分配角色时实时预览「最终有效权限」，降低组合误解风险
• 角色变更审计日志增强：记录每次角色变更的完整上下文（谁、何时、被谁分配、哪个 IP）
• 资源级分享增强：Item Sharing 目前为 Editor/Viewer/Use-only 三级，考虑增加「限时分享」和「分享链接过期」
• 自定义角色预设模板：提供常见场景的预设（如「实习生模式」、「外包模式」、「只读审计模式」）

• 基于属性的访问控制（ABAC）：在 RBAC 基础上叠加标签/属性维度，如「只允许编辑带有 project=marketing 标签的工作流」
• 时间绑定的角色：支持临时角色分配（如「24 小时内临时 Admin 用于紧急维护」），到期自动回收
• 跨组织角色委托：支持大型企业场景下，某组织的 Admin 将特定资源的管理权委托给另一个组织

• 策略即代码（Policy as Code）：允许通过 IaC 方式声明自定义角色，纳入版本管理和 CI/CD 流程
• 冲突检测引擎：当多个自定义角色产生矛盾限制时，引擎自动标记并被解除（目前取最严格交集，但极端情况下可能产生空权限集）

1. 从最简开始：新成员仅授予 Member，按实际需要叠加最窄的角色。避免默认授予 Manager 或 Admin
2. 优先 Feature 角色：需要安全管理时授予 Security 而非 Admin — 「管理安全的人不需要看到计费信息」
3. 季度审查：每季度审查所有成员的角色持有情况，防止角色累积（role accumulation）导致的权限膨胀
4. 自定义角色作为安全网：将自定义角色视为「组织安全基线」— 所有成员默认至少套用一个自定义角色，限制高风险操作