角色与权限

系统有 5 种成员角色，按最小权限分配能力。本页说明每个角色能做什么、关键设计原则，以及遇到「无权限」提示时如何理解。

能力矩阵

能力从 contributor 向 platform_admin 递增（auditor 是独立的只读审计线，不在递增链上）：

设计原则

• 平台与管理分离：platform_admin 管基础设施（成员、配置、审计），maintainer 管内容裁定（审批修复）。两者刻意不重叠——平台管理员也无法审批代码修复。
• 最小权限：每个角色只拿到完成其职责所需的能力；未授权访问一律 403 拒绝，拒绝原因在审计日志留痕。
• auditor 独立：审计员只读审计元数据，无仓库、代码、RAG 访问——保证审计视角独立于业务操作者。
• 邀请上限：邀请永不授予 platform_admin（API 校验、认领守卫、数据库 CHECK 三层拒绝）。首任管理员由部署脚本或 SQL 直授。

为什么审批只有 maintainer 能做

审批意味着决定是否对代码发起修复——这是内容裁定权。把它与平台管理权分离，可以确保 「运营平台的人」和「裁定代码的人」不会是同一批人，避免单点权力过大。 这也是为什么 platform_admin 打开审批面板时，审批按钮同样不可用。

遇到「无权限」怎么理解

看到「无权限」提示时，说明当前账号的角色没有对应能力——这是权限设计行为，不是系统故障。 处理方式：

• 确认自己当前角色：登录后右上角显示「组织 · 角色」；或调 GET /api/mu/session 看 role 字段。
• 需要提权：联系拥有「成员与角色管理」能力的管理员（platform_admin），在「组织与接入」面板调整角色。
• 仓库级 403：可能是仓库未绑定或绑定失效——maintainer/platform_admin 在仓库页完成绑定。
• 完整能力对照见上方矩阵或 deploy-kit 内 README「角色与权限速查」一节。

角色如何授予

• 邀请：管理员在「组织与接入 → 成员与邀请」面板，按 GitHub 数字 id 创建邀请并选择角色；受邀人打开邀请链接登录即认领。单次认领、有时效，详见多租户与邀请。
• 调整：platform_admin 在成员面板可直接修改既有成员角色；撤权后同会话下一请求即 403。
• 首任 platform_admin：不由邀请产生——由部署流程中的初始化 SQL 直授（见 deploy-kit README「首个平台管理员初始化」）。

权限的权威实现在仓库 console/backend/lib/multiuser/authz.mjs；本页与该实现保持同步。