[{"data":1,"prerenderedAt":44},["ShallowReactive",2],{"doc:\u002Fcontracts\u002Foauth\u002F11-roles":3},{"title":4,"route":5,"toc":6,"segments":39,"source":43},"角色与能力语义（权威定义）","\u002Fcontracts\u002Foauth\u002F11-roles",[7,11,14,17,21,24,27,30,33,36],{"id":8,"text":9,"depth":10},"1-五个角色","1. 五个角色",2,{"id":12,"text":13,"depth":10},"2-角色如何下发-claim-格式-权威","2. 角色如何下发（claim 格式 —— 权威)",{"id":15,"text":16,"depth":10},"3-能力语义与层级-权威","3. 能力语义与层级（权威）",{"id":18,"text":19,"depth":20},"3-1-两条独立的轴","3.1 两条独立的轴",3,{"id":22,"text":23,"depth":20},"3-2-运行不变量-ren-必与-admin-同授","3.2 运行不变量:`ren` 必与 `admin` 同授",{"id":25,"text":26,"depth":20},"3-3-能力语义速查","3.3 能力语义速查",{"id":28,"text":29,"depth":10},"4-下游必须遵守的规则-must","4. 下游必须遵守的规则（MUST）",{"id":31,"text":32,"depth":10},"5-角色授予矩阵-仅-oauth-后台","5. 角色授予矩阵（仅 OAuth 后台）",{"id":34,"text":35,"depth":10},"6-下游合规状态-已整改-存档","6. 下游合规状态（已整改 · 存档）",{"id":37,"text":38,"depth":10},"7-关联文档","7. 关联文档",[40],{"type":41,"html":42},"html","\u003Ch1 id=\"角色与能力语义-权威定义\" tabindex=\"-1\">角色与能力语义（权威定义）\u003C\u002Fh1>\n\u003Cp>返回 \u003Ca href=\"\u002Fcontracts\u002Foauth\">README\u003C\u002Fa>\u003C\u002Fp>\n\u003Chr>\n\u003Cblockquote>\n\u003Cp>\u003Cstrong>本文是全站五角色及其能力语义的唯一权威来源（Tier A）。\u003C\u002Fstrong> 角色由 OAuth IdP 统一定义、统一通过 JWT 下发；\u003Cstrong>下游 kungal（论坛）、moyu（补丁站）、wiki 等所有 RP 必须遵守本文的语义,不得自行发明与此冲突的解释。\u003C\u002Fstrong> 任何站点的鉴权(后端为准)在把 \u003Ccode>roles\u003C\u002Fcode> claim 映射成内部权限时,都必须满足本文 §3 的能力序与 §4 的强制规则。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Chr>\n\u003Ch2 id=\"1-五个角色\" tabindex=\"-1\">1. 五个角色\u003C\u002Fh2>\n\u003Cdiv class=\"kun-table-wrap\">\u003Ctable>\u003Cthead>\n\u003Ctr>\n\u003Cth>角色名（claim 字符串）\u003C\u002Fth>\n\u003Cth>中文\u003C\u002Fth>\n\u003Cth>语义\u003C\u002Fth>\n\u003Cth>可经 API 授予?\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>user\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>普通用户\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>隐式默认身份\u003C\u002Fstrong>——任何登录用户。\u003Cstrong>不是被显式授予的角色\u003C\u002Fstrong>(见 §2)\u003C\u002Ftd>\n\u003Ctd>—（隐式)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>creator\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>创作者\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>可信发布者\u003C\u002Fstrong>:可直接发布 galgame(跳过审核队列 + 跳过每日提交配额)。\u003Cstrong>与审核\u002F管理正交,不含任何审核或管理权\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>是（admin \u002F ren 可授;也可走申请流程,见 \u003Ca href=\"\u002Fcontracts\u002Foauth\u002F08-creator-applications\">08\u003C\u002Fa>)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>moderator\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>版主\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>内容审核\u003C\u002Fstrong>:可处置\u003Cstrong>他人\u003C\u002Fstrong>的内容(编辑\u002F删除\u002F置顶\u002F隐藏\u002F审核提交)\u003C\u002Ftd>\n\u003Ctd>是（admin \u002F ren 可授)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>admin\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>管理员\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>站点与用户管理\u003C\u002Fstrong>:用户管理、站点\u002FOAuth 客户端、统计、封禁、角色授予等;含 moderator 全部能力\u003C\u002Ftd>\n\u003Ctd>是（仅 ren 可授)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>ren\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>莲\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>admin 之上的操作者\u003C\u002Fstrong>:存储配置、artifact 文件运维、PII 可见、可授予任意角色;含 admin 全部能力\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>否\u003C\u002Fstrong>(仅可直接配置 DB,永不经 API 授予)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\u003C\u002Fdiv>\u003Cblockquote>\n\u003Cp>角色集是\u003Cstrong>固定的 5 个\u003C\u002Fstrong>,种子定义在 IdP 代码 \u003Ccode>cmd\u002Fmigrate\u003C\u002Fcode>。除此之外的任何字符串(含历史别名 \u003Ccode>super_admin\u003C\u002Fcode>)\u003Cstrong>不是有效角色\u003C\u002Fstrong>,下游不得依赖。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>站点域角色(加法扩展)\u003C\u002Fstrong>:除本文的\u003Cstrong>全局\u003C\u002Fstrong>五角色外,还有一层\u003Cstrong>只在单个站点生效\u003C\u002Fstrong>的\n站点域角色(\u003Ccode>site_roles\u003C\u002Fcode> claim,如「letmoe 的 moderator」)。它是本契约的\u003Cstrong>加法扩展\u003C\u002Fstrong>,不改动这里\n的任何语义;全局 \u003Ccode>roles\u003C\u002Fcode> claim 与授予矩阵一切照旧。详见 \u003Ca href=\"\u002Fcontracts\u002Foauth\u002F12-site-roles\">12-site-roles.md\u003C\u002Fa>。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Chr>\n\u003Ch2 id=\"2-角色如何下发-claim-格式-权威\" tabindex=\"-1\">2. 角色如何下发（claim 格式 —— 权威)\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>access_token 的 \u003Ccode>roles\u003C\u002Fcode> claim 是一个\u003Cstrong>角色名字符串数组\u003C\u002Fstrong>(见 \u003Ca href=\"\u002Fcontracts\u002Foauth\u002F04-tokens-and-errors#jwt-access-token-claims\">04 JWT Claims\u003C\u002Fa>)。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode>roles\u003C\u002Fcode> 是一个无序集合,不是有序列表,也不是数值等级。\u003C\u002Fstrong> 下游\u003Cstrong>不得\u003C\u002Fstrong>假设元素顺序,\u003Cstrong>不得\u003C\u002Fstrong>假设某个角色一定在\u002F不在数组里(除非按集合成员判断)。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>普通用户的 \u003Ccode>roles\u003C\u002Fcode> 为空数组 \u003Ccode>[]\u003C\u002Fcode>。\u003C\u002Fstrong> 字符串 \u003Ccode>"user"\u003C\u002Fcode> \u003Cstrong>不会\u003C\u002Fstrong>出现在 claim 里——它是隐式默认。\u003Cstrong>下游不得用"数组里有没有 \u003Ccode>user\u003C\u002Fcode>"来判断是否登录\u003C\u002Fstrong>(用是否持有有效 token 判断登录;用"数组是否含某个提权角色"判断提权)。\u003C\u002Fli>\n\u003Cli>角色是\u003Cstrong>可叠加的\u003C\u002Fstrong>:一个账号可同时持有多个角色(例如所有 \u003Ccode>ren\u003C\u002Fcode> 账号都\u003Cstrong>同时持有 \u003Ccode>admin\u003C\u002Fcode>\u003C\u002Fstrong>,见 §3.2 不变量)。\u003C\u002Fli>\n\u003Cli>角色变更在\u003Cstrong>下一次 token 刷新\u003C\u002Fstrong>后生效。下游\u003Cstrong>必须\u003C\u002Fstrong>每次从最新 claim \u002F userinfo 重新解析角色,\u003Cstrong>不得\u003C\u002Fstrong>把角色长期缓存到失去时效(提权\u002F降权要能在会话中途生效)。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Chr>\n\u003Ch2 id=\"3-能力语义与层级-权威\" tabindex=\"-1\">3. 能力语义与层级（权威）\u003C\u002Fh2>\n\u003Ch3 id=\"3-1-两条独立的轴\" tabindex=\"-1\">3.1 两条独立的轴\u003C\u002Fh3>\n\u003Cp>能力分两条\u003Cstrong>互相正交\u003C\u002Fstrong>的轴,下游必须分别理解:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>管理\u002F审核轴(有序,逐级包含):\u003C\u002Fstrong>\u003Cpre class=\"shiki shiki-themes github-light github-dark\" style=\"background-color:#fff;--shiki-dark-bg:#24292e;color:#24292e;--shiki-dark:#e1e4e8\" tabindex=\"0\">\u003Ccode class=\"language-text\">\u003Cspan class=\"line\">\u003Cspan>普通用户  <  moderator  <  admin  <  ren\u003C\u002Fspan>\u003C\u002Fspan>\u003C\u002Fcode>\u003C\u002Fpre>\n高一级\u003Cstrong>必须\u003C\u002Fstrong>被视为拥有低一级在本站的全部能力。即:\n\u003Cul>\n\u003Cli>任何持有 \u003Ccode>admin\u003C\u002Fcode> 的账号,\u003Cstrong>必须\u003C\u002Fstrong>被授予 \u003Ccode>moderator\u003C\u002Fcode> 的全部能力;\u003C\u002Fli>\n\u003Cli>任何持有 \u003Ccode>ren\u003C\u002Fcode> 的账号,\u003Cstrong>必须\u003C\u002Fstrong>被授予 \u003Ccode>admin\u003C\u002Fcode>(以及因此 \u003Ccode>moderator\u003C\u002Fcode>)的全部能力。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003C\u002Fli>\n\u003Cli>\u003Cstrong>发布轴(正交):\u003C\u002Fstrong> \u003Ccode>creator\u003C\u002Fcode> 是"可信发布者"标记,\u003Cstrong>只\u003C\u002Fstrong>赋予 galgame 直接发布能力(跳过审核 + 跳过提交配额),\u003Cstrong>不\u003C\u002Fstrong>赋予任何审核或管理能力。它独立于管理轴——一个 \u003Ccode>creator\u003C\u002Fcode> 不是 moderator,一个 moderator 不自动是 creator。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cblockquote>\n\u003Cp>注意:管理轴的"逐级包含"是\u003Cstrong>契约层的强制语义\u003C\u002Fstrong>(§4 规则 2),下游必须在自己的鉴权里实现它,\u003Cstrong>不能\u003C\u002Fstrong>因为内部用数值等级或角色名白名单就把某个高角色漏掉。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch3 id=\"3-2-运行不变量-ren-必与-admin-同授\" tabindex=\"-1\">3.2 运行不变量:\u003Ccode>ren\u003C\u002Fcode> 必与 \u003Ccode>admin\u003C\u002Fcode> 同授\u003C\u002Fh3>\n\u003Cp>IdP 保证(并由运维约定):\u003Cstrong>任何 \u003Ccode>ren\u003C\u002Fcode> 账号都同时持有 \u003Ccode>admin\u003C\u002Fcode>\u003C\u002Fstrong>。但下游\u003Cstrong>不得\u003C\u002Fstrong>把这条当作可省略 ren 处理的借口——按 §4 规则 2,下游仍必须把 \u003Ccode>ren\u003C\u002Fcode> 当作 ≥ \u003Ccode>admin\u003C\u002Fcode> 来对待,使系统在该不变量被打破时依然正确。\u003C\u002Fp>\n\u003Ch3 id=\"3-3-能力语义速查\" tabindex=\"-1\">3.3 能力语义速查\u003C\u002Fh3>\n\u003Cdiv class=\"kun-table-wrap\">\u003Ctable>\u003Cthead>\n\u003Ctr>\n\u003Cth>能力(语义层,不是穷举接口)\u003C\u002Fth>\n\u003Cth>最低角色\u003C\u002Fth>\n\u003Cth>说明\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>浏览公开内容\u003C\u002Ftd>\n\u003Ctd>匿名\u003C\u002Ftd>\n\u003Ctd>无需登录\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>发帖\u002F发补丁\u002F评论\u002F提交 galgame 草稿\u002F创建分类\u002F提 PR\u002F编辑删除\u003Cstrong>自己的\u003C\u002Fstrong>内容\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>user\u003C\u002Fcode>(登录)\u003C\u002Ftd>\n\u003Ctd>任意登录用户\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>直接发布 galgame\u003C\u002Fstrong>(跳过审核队列 + 跳过每日提交配额,可省略 vndb_id)\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>creator\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>由 wiki 后端在提交流中实现;经下游"提交"入口代理到 wiki 时同样生效\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>编辑\u002F删除\u002F置顶\u002F隐藏\u002F审核\u003Cstrong>他人\u003C\u002Fstrong>的内容、galgame 提交审核(通过\u002F拒绝\u002F封禁)\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>moderator\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>内容审核\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>用户管理(封禁\u002F匿名化\u002F强制下线\u002F调萌萌点)、站点 & OAuth 客户端管理、授予 moderator\u002Fcreator 角色、各站点级配置\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>admin\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>站点管理\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>客户端存储能力配置、artifact 文件浏览\u002F删除\u002F清理、查看用户 PII(邮箱\u002FIP)、授予任意角色\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>ren\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>IdP 专属;详见 IdP 后台,非下游接口\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\u003C\u002Fdiv>\u003Cblockquote>\n\u003Cp>galgame\u002Fwiki 相关能力的\u003Cstrong>具体接口与门禁\u003C\u002Fstrong>以 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FKunMoe\u002Fkun-galgame-infra\u002Fblob\u002Fmain\u002Fdocs\u002Fintegration\u002Fgalgame_wiki\">galgame_wiki 契约\u003C\u002Fa> 为准(该契约也属 Tier A);本文只定义角色与能力的\u003Cstrong>语义映射\u003C\u002Fstrong>。各下游站点自身内容(帖子\u002F补丁\u002F评分等)的具体接口在各自仓库,但其角色判定\u003Cstrong>必须\u003C\u002Fstrong>符合本文 §3、§4。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Chr>\n\u003Ch2 id=\"4-下游必须遵守的规则-must\" tabindex=\"-1\">4. 下游必须遵守的规则（MUST）\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>以集合语义解析 \u003Ccode>roles\u003C\u002Fcode>。\u003C\u002Fstrong> 按"是否包含某角色名"判断,不依赖顺序;不靠 \u003Ccode>"user"\u003C\u002Fcode> 是否在数组里判断登录(§2)。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>实现管理轴的逐级包含。\u003C\u002Fstrong> 任何把 \u003Ccode>roles\u003C\u002Fcode> 映射到内部权限的逻辑,\u003Cstrong>必须\u003C\u002Fstrong>让 \u003Ccode>ren ⊇ admin ⊇ moderator\u003C\u002Fcode>:\n\u003Cul>\n\u003Cli>不得把 \u003Ccode>ren\u003C\u002Fcode> 当作普通用户或忽略;\u003C\u002Fli>\n\u003Cli>不得把 \u003Ccode>admin\u003C\u002Fcode> 排除在 moderator 能做的事之外。\u003C\u002Fli>\n\u003Cli>若内部用数值等级,\u003Cstrong>必须\u003C\u002Fstrong>:\u003Ccode>ren\u003C\u002Fcode>、\u003Ccode>admin\u003C\u002Fcode> → 最高管理级;\u003Ccode>moderator\u003C\u002Fcode> → 审核级;映射表必须覆盖所有提权角色,不得静默丢弃。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode>creator\u003C\u002Fcode> 仅作发布能力,不授予审核\u002F管理权。\u003C\u002Fstrong> 不得用 \u003Ccode>creator\u003C\u002Fcode> 放行任何审核或后台操作。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>后端为唯一鉴权点;前端门禁仅 UX。\u003C\u002Fstrong> 前端可隐藏 UI,但\u003Cstrong>不得\u003C\u002Fstrong>作为唯一防线;真正的权限判断必须在后端按 claim 做。前端"更严于后端"(例如把某操作藏在 admin 之后而后端只要 moderator)允许,但属 UX 不一致,应尽量对齐。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>不得在下游实现角色授予\u002F撤销。\u003C\u002Fstrong> 角色变更只在 OAuth 后台进行(矩阵见 §5);下游只读 claim。\u003Ccode>creator\u003C\u002Fcode> 申请走 \u003Ca href=\"\u002Fcontracts\u002Foauth\u002F08-creator-applications\">08\u003C\u002Fa> 的中央队列,授予仍归 OAuth。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>角色时效。\u003C\u002Fstrong> 每次刷新重新解析角色,使提权\u002F降权能在会话中途生效(§2)。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Chr>\n\u003Ch2 id=\"5-角色授予矩阵-仅-oauth-后台\" tabindex=\"-1\">5. 角色授予矩阵（仅 OAuth 后台）\u003C\u002Fh2>\n\u003Cdiv class=\"kun-table-wrap\">\u003Ctable>\u003Cthead>\n\u003Ctr>\n\u003Cth>操作者\u003C\u002Fth>\n\u003Cth>可授予 \u002F 撤销\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>ren\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>user\u003C\u002Fcode> \u002F \u003Ccode>creator\u003C\u002Fcode> \u002F \u003Ccode>moderator\u003C\u002Fcode> \u002F \u003Ccode>admin\u003C\u002Fcode>(任意可管理角色)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>admin\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>仅\u003C\u002Fstrong> \u003Ccode>moderator\u003C\u002Fcode> \u002F \u003Ccode>creator\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>其他\u003C\u002Ftd>\n\u003Ctd>无\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\u003C\u002Fdiv>\u003Cul>\n\u003Cli>\u003Cstrong>\u003Ccode>ren\u003C\u002Fcode> 永不可经 API 授予\u002F撤销\u003C\u002Fstrong>(只能直接配置 DB)。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>不能修改自己的角色。\u003C\u002Fstrong>\u003C\u002Fli>\n\u003Cli>成为 \u003Ccode>creator\u003C\u002Fcode> 另有自助申请通道(任意登录用户申请 → admin 审核 → 授予),见 \u003Ca href=\"\u002Fcontracts\u002Foauth\u002F08-creator-applications\">08-creator-applications.md\u003C\u002Fa>。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Chr>\n\u003Ch2 id=\"6-下游合规状态-已整改-存档\" tabindex=\"-1\">6. 下游合规状态（已整改 · 存档）\u003C\u002Fh2>\n\u003Cblockquote>\n\u003Cp>本节最初记录的是本文落地时下游对 \u003Ccode>ren\u003C\u002Fcode> 处理的合规差距;\u003Cstrong>两站均已整改完毕\u003C\u002Fstrong>,以下为存档与现状锚点:\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cul>\n\u003Cli>\u003Cstrong>kungal（论坛)\u003C\u002Fstrong>:✅ 已整改(commit \u003Ccode>58d3f68c\u003C\u002Fcode> "unify roles to OAuth's named-role model; drop numeric tier")。数值等级已废弃;\u003Ccode>apps\u002Fapi\u002Fpkg\u002Frole\u002Frole.go\u003C\u002Fcode> 以角色名集合 + 能力函数(\u003Ccode>CanModerate\u003C\u002Fcode> = moderator∪admin∪ren、\u003Ccode>CanAdminister\u003C\u002Fcode> = admin∪ren、\u003Ccode>IsCreator\u003C\u002Fcode>)实现 §3 语义,\u003Ccode>super_admin\u003C\u002Fcode> 已按本文 §1 移除。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>moyu（补丁站)\u003C\u002Fstrong>:✅ 已整改(commit \u003Ccode>58b9710e\u003C\u002Fcode> "align role labels site-wide with the OAuth 5-role contract")。\u003Ccode>apps\u002Fapi\u002Finternal\u002Fmiddleware\u002Fauth.go\u003C\u002Fcode> 的 \u003Ccode>SuperAdminRoles = {admin, ren}\u003C\u002Fcode> \u002F \u003Ccode>ModeratorRoles = {admin, ren, moderator}\u003C\u002Fcode> 完整识别 \u003Ccode>ren\u003C\u002Fcode> 为最高管理级;前端标签已对齐契约命名。\u003C\u002Fli>\n\u003Cli>两站对 \u003Ccode>creator\u003C\u002Fcode> 的"不授予审核权"处理始终符合本契约(§3.1)。\u003C\u002Fli>\n\u003Cli>历史别名 \u003Ccode>super_admin\u003C\u002Fcode>:IdP 从不签发;两下游均已不依赖该字符串。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>整改后,只持 \u003Ccode>ren\u003C\u002Fcode>(无 \u003Ccode>admin\u003C\u002Fcode>)的账号在各站均获得完整管理权,系统不再依赖 §3.2 的"ren 必同时持 admin"运维约定,该不变量退回为纵深防御。新接入的 RP 直接按 §3、§4 实现即可,不需要参考任何历史数值等级。\u003C\u002Fp>\n\u003Chr>\n\u003Ch2 id=\"7-关联文档\" tabindex=\"-1\">7. 关联文档\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"\u002Fcontracts\u002Foauth\u002F04-tokens-and-errors#jwt-access-token-claims\">04-tokens-and-errors.md\u003C\u002Fa> —— \u003Ccode>roles\u003C\u002Fcode> claim 的 JWT 位置。\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fcontracts\u002Foauth\u002F08-creator-applications\">08-creator-applications.md\u003C\u002Fa> —— \u003Ccode>creator\u003C\u002Fcode> 申请\u002F审批流程。\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002FKunMoe\u002Fkun-galgame-infra\u002Fblob\u002Fmain\u002Fdocs\u002Fintegration\u002Fgalgame_wiki\">galgame_wiki 契约\u003C\u002Fa> —— galgame 编辑\u002F审核\u002F发布的具体接口与角色门禁。\u003C\u002Fli>\n\u003C\u002Ful>\n","kun-galgame-infra\u002Fdocs\u002Fintegration\u002Foauth\u002F11-roles.md",1783514297241]