koishi-plugin-new-auth 0.1.0

package/newauth.md

@@ -0,0 +1,1458 @@
+# 新 权限
+
+*Exported on 2026年5月25日 18:55:17*
+
+**Assistant**:
+
+
+
+下面是一版收敛后的完整设计方案。核心原则是：
+
+> **权限管理以“角色”为中心；指令注册后进入权限系统；Koishi 管理员决定每个角色能用哪些指令；普通群主不会天然获得 Bot 实例权限。**
+
+---
+
+# 1. 设计目标
+
+新权限系统解决这些问题：
+
+1. **多群隔离**
+   - 同一个人在群 A 是群主，在群 B 是管理员，在群 C 是成员，权限结果不同。
+
+2. **角色视角管理**
+   - WebUI 主界面展示角色。
+   - 点进角色后，配置这个角色能用哪些指令。
+
+3. **新指令默认安全**
+   - 插件新增指令后，不自动开放给群主、管理员、成员。
+   - 默认只有 Bot 管理员可用，等待 Koishi 管理员配置。
+
+4. **旧 `authority` 兼容但不直接放权**
+   - 老插件的 `.authority(3)` 只作为“建议值”。
+   - 最终是否能执行，仍由新权限系统决定。
+
+5. **角色系统保持简单**
+   - 不做复杂继承。
+   - 不搞复杂权限树。
+   - 自定义角色本质上就是“用户分组 + 可用指令列表”。
+
+6. **群主权限和 Bot 管理权限分离**
+   - 群主只能代表当前群。
+   - 群主不能自动管理插件、文件、数据库、全局配置。
+
+---
+
+# 2. 核心概念
+
+系统内部有四个核心对象：
+
+```txt
+角色 Role
+指令 Command
+作用域 Scope
+策略 Policy
+```
+
+它们之间的关系是：
+
+```txt
+某个作用域下，某个角色，能不能使用某个指令。
+```
+
+也就是：
+
+```txt
+scope + role + command -> allow / deny / inherit
+```
+
+用户执行命令时，系统判断：
+
+```txt
+当前用户在当前作用域里属于哪些角色；
+这些角色是否允许使用当前指令。
+```
+
+---
+
+# 3. 内置角色设计
+
+内置角色保持简单：
+
+```txt
+Bot 管理员
+群主
+群管理员
+群成员
+访客
+```
+
+## 3.1 Bot 管理员
+
+这是管理 Koishi 实例的人。
+
+拥有：
+
+```txt
+插件管理
+全局配置
+数据库管理
+控制台管理
+所有未配置指令的执行权
+```
+
+Bot 管理员只能通过 Koishi 管理员显式设置，不能由平台身份自动获得。
+
+也就是说：
+
+```txt
+QQ群主 ≠ Bot 管理员
+Discord 服务器 owner ≠ Bot 管理员
+```
+
+## 3.2 群主
+
+来自平台身份。
+
+例如：
+
+```txt
+QQ群主
+Discord 服务器拥有者
+Telegram 群 owner
+```
+
+只在当前群作用域生效。
+
+```txt
+用户 A 在群 1 是群主，只代表他在群 1 里拥有“群主”角色。
+```
+
+不影响其他群。
+
+## 3.3 群管理员
+
+同样来自平台身份。
+
+```txt
+QQ群管理员 -> 群管理员
+Discord 有管理权限的成员 -> 群管理员
+```
+
+只在当前群生效。
+
+## 3.4 群成员
+
+普通群成员。
+
+## 3.5 访客
+
+用于：
+
+```txt
+私聊场景
+无法识别身份的用户
+未绑定用户
+非群上下文用户
+```
+
+---
+
+# 4. 自定义角色设计
+
+自定义角色不要复杂。
+
+创建角色时只需要：
+
+```txt
+角色名称
+适用范围
+成员列表
+```
+
+例如：
+
+```txt
+角色名称：点歌管理员
+适用范围：群内
+成员：张三、李四
+```
+
+或者：
+
+```txt
+角色名称：活动管理员
+适用范围：群 A
+成员：王五
+```
+
+自定义角色不做继承。
+
+不设计：
+
+```txt
+高级管理员继承管理员
+点歌管理员继承群成员
+角色 A 继承角色 B
+```
+
+如果用户想让新角色拥有类似管理员的权限，提供一个简单操作：
+
+```txt
+从“群管理员”复制可用指令
+```
+
+复制之后两者独立，不存在继承关系。
+
+---
+
+# 5. 作用域设计
+
+权限必须带作用域，否则多群场景一定会乱。
+
+作用域分为：
+
+```txt
+global
+guild:<platform>:<guildId>
+```
+
+可以预留频道作用域：
+
+```txt
+channel:<platform>:<channelId>
+```
+
+但第一层主要用：
+
+```txt
+global
+guild
+```
+
+## 5.1 global
+
+全局默认配置。
+
+例如：
+
+```txt
+默认情况下，群成员可以用签到
+默认情况下，群管理员可以用禁言
+默认情况下，插件重载只有 Bot 管理员可用
+```
+
+## 5.2 guild
+
+单群覆盖配置。
+
+例如：
+
+```txt
+群 A：
+群成员不能用签到
+
+群 B：
+群成员可以用签到
+
+群 C：
+只有群主可以用点歌
+```
+
+群作用域只影响当前群，不影响其他群。
+
+---
+
+# 6. 指令登记机制
+
+每个 Koishi 命令在注册时，都会进入权限系统的“指令登记表”。
+
+例如插件注册：
+
+```txt
+sign
+mute
+plugin/reload
+file/delete
+```
+
+权限系统登记为：
+
+```txt
+command:sign
+command:mute
+command:plugin.reload
+command:file.delete
+```
+
+这个 ID 是系统内部用的。
+
+WebUI 不需要直接展示：
+
+```txt
+command:sign
+```
+
+而是展示：
+
+```txt
+签到
+禁言
+插件重载
+删除文件
+```
+
+---
+
+# 7. 指令状态
+
+每个指令有一个配置状态：
+
+```txt
+已配置
+待配置
+已禁用
+```
+
+## 7.1 待配置
+
+插件新增指令后，默认进入待配置状态。
+
+待配置指令默认规则：
+
+```txt
+只有 Bot 管理员可用。
+```
+
+群主、群管理员、群成员都不能直接使用。
+
+这样可以避免：
+
+```txt
+群主把 Bot 拉进群后，突然能用删除文件、重载插件、执行脚本之类的指令。
+```
+
+## 7.2 已配置
+
+Koishi 管理员给某些角色勾选了这个指令后，它变成已配置。
+
+例如：
+
+```txt
+签到：
+群成员 可用
+群管理员 可用
+群主 可用
+
+禁言：
+群成员 不可用
+群管理员 可用
+群主 可用
+
+插件重载：
+只有 Bot 管理员 可用
+```
+
+## 7.3 已禁用
+
+指令存在，但被权限系统整体禁用。
+
+即使角色原本有权限，也不能使用。
+
+---
+
+# 8. `authority` 的定位
+
+旧插件可能写：
+
+```txt
+.authority(1)
+.authority(2)
+.authority(3)
+.authority(4)
+```
+
+新系统里，`authority` 不再直接决定用户权限。
+
+它只作为指令登记时的建议值。
+
+例如：
+
+```txt
+authority 0 -> 建议访客/成员可用
+authority 1 -> 建议成员可用
+authority 2 -> 建议群管理员可用
+authority 3 -> 建议群主可用
+authority 4+ -> 建议 Bot 管理员可用
+```
+
+WebUI 里可以显示：
+
+```txt
+指令：禁言
+来源插件：xxx
+旧权限建议：群主可用
+当前实际配置：群管理员、群主可用
+```
+
+也可以提供按钮：
+
+```txt
+采用插件建议
+```
+
+但重点是：
+
+```txt
+authority 只是建议，不是最终授权。
+```
+
+最终授权来自：
+
+```txt
+角色 + 指令配置
+```
+
+---
+
+# 9. WebUI 设计
+
+WebUI 主入口应该是角色，而不是指令矩阵。
+
+## 9.1 主页面：角色列表
+
+展示：
+
+```txt
+角色
+- Bot 管理员
+- 群主
+- 群管理员
+- 群成员
+- 访客
+- 点歌管理员
+- 活动管理员
+```
+
+每个角色显示摘要：
+
+```txt
+Bot 管理员       全局角色      58 个可用指令
+群主             群内角色      21 个可用指令
+群管理员         群内角色      16 个可用指令
+群成员           群内角色      8 个可用指令
+点歌管理员       自定义角色    4 个可用指令
+```
+
+## 9.2 角色详情页
+
+点进“群管理员”后，看到：
+
+```txt
+角色：群管理员
+当前范围：全局默认 / 群 A / 群 B
+```
+
+下面是指令列表：
+
+```txt
+基础
+- 帮助          开
+- 签到          开
+- 天气          开
+
+群管理
+- 禁言          开
+- 踢人          关
+- 撤回          开
+
+娱乐
+- 点歌          开
+- 切歌          开
+- 清空歌单      关
+
+Bot 管理
+- 插件重载      不可用
+- 安装插件      不可用
+- 删除文件      不可用
+```
+
+不过普通情况下，“Bot 管理”这类不应该出现在群角色页面里。
+
+更推荐：
+
+```txt
+群角色页面只展示可以被下放/配置的群内指令。
+```
+
+高级审计模式下才显示不可配置指令。
+
+## 9.3 当前范围切换
+
+页面顶部有范围选择：
+
+```txt
+配置范围：
+- 全局默认
+- 群 A
+- 群 B
+- 群 C
+```
+
+选择“全局默认”时，配置默认规则。
+
+选择“群 A”时，配置群 A 的覆盖规则。
+
+例如：
+
+```txt
+全局默认：
+群成员可以签到
+
+群 A 覆盖：
+群成员不可以签到
+```
+
+最终群 A 里，成员不能签到。
+
+其他群仍然按照全局默认。
+
+---
+
+# 10. 待配置指令页面
+
+虽然主界面是角色列表，但仍然需要一个“待配置指令”页面。
+
+这个页面不是主权限编辑方式，而是提醒 Koishi 管理员：
+
+```txt
+检测到这些新指令，还没有配置给任何角色。
+```
+
+例如：
+
+```txt
+待配置指令
+
+- 抽奖 lottery
+  来源插件：lottery
+  插件建议：群成员可用
+
+- 清空歌单 music/clear
+  来源插件：music
+  插件建议：群管理员可用
+
+- 插件重载 plugin/reload
+  来源插件：market
+  插件建议：Bot 管理员可用
+```
+
+管理员可以点进去快捷分配：
+
+```txt
+这个指令允许哪些角色使用？
+[ ] 访客
+[ ] 群成员
+[ ] 群管理员
+[ ] 群主
+[ ] Bot 管理员
+[ ] 点歌管理员
+```
+
+但长期管理仍然推荐从角色详情页进入。
+
+---
+
+# 11. 群主可配置范围
+
+群主不能配置所有指令。
+
+需要有一个概念：
+
+```txt
+允许群内自治
+```
+
+也就是说，Koishi 管理员可以决定某个指令是否允许群主在自己群里开关。
+
+例如：
+
+```txt
+签到：允许群内自治
+点歌：允许群内自治
+欢迎语：允许群内自治
+禁言：允许群内自治
+插件重载：不允许群内自治
+删除文件：不允许群内自治
+数据库管理：不允许群内自治
+```
+
+群主打开自己群的配置页时，只能看到：
+
+```txt
+允许群内自治的指令
+```
+
+看不到或者不能修改：
+
+```txt
+插件管理
+文件管理
+数据库管理
+全局广播
+重启 Bot
+执行脚本
+```
+
+这条很重要。
+
+即使某人是群主，他也只是：
+
+```txt
+guild:<当前群> 下的群主
+```
+
+不是：
+
+```txt
+global 下的 Bot 管理员
+```
+
+---
+
+# 12. 权限判断流程
+
+用户执行命令时，流程如下：
+
+## 12.1 解析命令
+
+例如用户发送：
+
+```txt
+/禁言 @张三
+```
+
+Koishi 解析到命令：
+
+```txt
+mute
+```
+
+权限系统找到内部指令 ID：
+
+```txt
+command:mute
+```
+
+## 12.2 构建上下文
+
+从 session 得到：
+
+```txt
+platform
+userId
+guildId
+channelId
+```
+
+例如：
+
+```txt
+platform = onebot
+userId = 10001
+guildId = 888888
+```
+
+当前作用域：
+
+```txt
+guild:onebot:888888
+global
+```
+
+## 12.3 收集用户角色
+
+系统从多个来源收集角色：
+
+```txt
+平台身份
+手动绑定角色
+Bot 管理员身份
+自定义角色
+```
+
+例如用户在当前群是管理员：
+
+```txt
+群管理员
+```
+
+如果他同时是 Bot 管理员：
+
+```txt
+Bot 管理员
+群管理员
+```
+
+如果他还被加入了“点歌管理员”：
+
+```txt
+Bot 管理员
+群管理员
+点歌管理员
+```
+
+## 12.4 查找指令权限
+
+先查当前群覆盖配置：
+
+```txt
+guild:onebot:888888
+```
+
+再查全局默认配置：
+
+```txt
+global
+```
+
+如果当前群没有单独配置，则使用全局默认。
+
+## 12.5 得出结果
+
+规则：
+
+```txt
+只要用户拥有的任一角色允许该指令，就允许执行。
+```
+
+例如：
+
+```txt
+用户角色：群管理员、点歌管理员
+指令：清空歌单
+
+群管理员：不允许
+点歌管理员：允许
+
+最终：允许
+```
+
+这里的“不允许”只是表示这个角色不提供权限，不是全局封禁。
+
+真正的封禁应该单独做成：
+
+```txt
+用户黑名单
+群黑名单
+指令禁用
+```
+
+不要混在角色权限里。
+
+---
+
+# 13. 策略状态设计
+
+每个角色对每个指令在某个作用域下有三种状态：
+
+```txt
+继承
+允许
+关闭
+```
+
+## 13.1 继承
+
+使用上级配置。
+
+例如群 A 没有单独设置“群成员能否签到”，就继承全局默认。
+
+## 13.2 允许
+
+当前作用域明确允许。
+
+例如：
+
+```txt
+群 A：
+群成员 可以签到
+```
+
+## 13.3 关闭
+
+当前作用域明确关闭。
+
+例如：
+
+```txt
+群 A：
+群成员 不可以签到
+```
+
+注意：
+
+```txt
+关闭只对这个角色生效。
+```
+
+如果这个用户还有其他角色，而其他角色允许这个指令，仍然可以执行。
+
+这能避免复杂的“显式拒绝优先”问题。
+
+---
+
+# 14. 数据结构设计
+
+## 14.1 指令表
+
+```txt
+commands
+- id
+- name
+- commandPath
+- aliases
+- plugin
+- description
+- legacyAuthority
+- status
+- allowGuildOverride
+- createdAt
+- updatedAt
+```
+
+说明：
+
+```txt
+id                 内部稳定 ID，例如 command:music.clear
+name               WebUI 显示名，例如 清空歌单
+commandPath        Koishi 命令路径
+aliases            别名
+plugin             来源插件
+legacyAuthority    旧 authority 建议
+status             pending/configured/disabled
+allowGuildOverride 是否允许群内自治
+```
+
+## 14.2 角色表
+
+```txt
+roles
+- id
+- name
+- type
+- scopeType
+- builtin
+- createdAt
+- updatedAt
+```
+
+例如：
+
+```txt
+bot-admin
+guild-owner
+guild-admin
+guild-member
+guest
+custom:music-admin
+```
+
+字段解释：
+
+```txt
+type:
+  builtin
+  custom
+
+scopeType:
+  global
+  guild
+```
+
+## 14.3 角色成员表
+
+```txt
+role_members
+- roleId
+- platform
+- userId
+- scope
+- createdAt
+```
+
+用于自定义角色和 Bot 管理员。
+
+平台身份角色不一定需要写入数据库。
+
+例如 QQ 群管理员可以直接从 session 动态读取。
+
+## 14.4 权限策略表
+
+```txt
+role_command_policies
+- scope
+- roleId
+- commandId
+- state
+- updatedAt
+```
+
+其中：
+
+```txt
+state:
+  inherit
+  allow
+  deny
+```
+
+这里的 `deny` 在 UI 上叫“关闭”，语义是：
+
+```txt
+这个角色在这个作用域下不拥有此指令权限。
+```
+
+不是全局强拒绝。
+
+---
+
+# 15. 平台身份接入
+
+Adapter 或 session 层提供当前用户在群内的平台身份。
+
+例如 OneBot：
+
+```txt
+owner  -> 群主
+admin  -> 群管理员
+member -> 群成员
+```
+
+Discord：
+
+```txt
+server owner -> 群主
+有管理权限 -> 群管理员
+普通用户 -> 群成员
+```
+
+平台身份建议动态读取，不强制持久化。
+
+好处：
+
+```txt
+群管理员变更后可以自动生效
+不需要同步平台权限表
+不会出现数据库身份过期
+```
+
+如果平台无法提供身份，则降级为：
+
+```txt
+访客
+```
+
+或者使用手动绑定角色。
+
+---
+
+# 16. Bot 管理员的来源
+
+Bot 管理员必须由 Koishi 实例拥有者显式配置。
+
+来源可以是：
+
+```txt
+配置文件
+控制台账号
+数据库绑定
+启动时初始化账号
+```
+
+但不能来自：
+
+```txt
+群主身份
+群管理员身份
+平台频道 owner 身份
+```
+
+这是安全边界。
+
+换句话说：
+
+```txt
+能管理一个群 ≠ 能管理这个 Bot。
+```
+
+---
+
+# 17. 命令执行接入点
+
+权限检查应该接在命令执行的统一入口。
+
+位置是：
+
+```txt
+命令解析完成后
+action 执行前
+```
+
+此时系统已经知道：
+
+```txt
+当前 session
+当前命令
+当前命令 ID
+来源插件
+legacyAuthority
+```
+
+然后调用权限服务：
+
+```txt
+检查当前用户能否执行当前命令
+```
+
+如果拒绝，直接返回统一错误：
+
+```txt
+你没有权限使用该指令。
+```
+
+不要让每个插件自己实现权限判断。
+
+---
+
+# 18. 旧插件兼容
+
+标准旧插件写法：
+
+```txt
+ctx.command('mute').authority(3)
+```
+
+处理方式：
+
+```txt
+1. 命令注册时记录 legacyAuthority = 3
+2. WebUI 显示建议：群主可用
+3. 指令默认进入待配置
+4. 未配置前只有 Bot 管理员可用
+5. 管理员确认后，按新权限策略执行
+```
+
+也就是说：
+
+```txt
+authority 不参与最终判定。
+```
+
+## 18.1 插件内部硬编码 authority
+
+有些老插件可能自己写：
+
+```txt
+if (session.user.authority < 3) return
+```
+
+这类无法完全优雅解决，但可以做兼容桥。
+
+设计一个 legacy authority provider（默认行为可以在web ui修改 或禁用此类硬编码插件）：
+
+```txt
+当前上下文下，根据角色反推一个近似 authority。
+```
+
+例如：
+
+```txt
+Bot 管理员 -> 4
+群主 -> 3
+群管理员 -> 2
+群成员 -> 1
+访客 -> 0
+```
+
+如果某个命令已经通过新权限系统放行，也可以在该命令执行上下文中临时保证：
+
+```txt
+session.user.authority >= 当前命令 legacyAuthority
+```
+
+这样可以减少旧插件内部二次判断导致的误拒绝。
+
+但这只是兼容层，不是新权限系统核心。
+
+---
+
+# 19. 缓存设计
+
+权限判断频率很高，需要缓存。
+
+缓存 key 可以包含：
+
+```txt
+platform
+userId
+guildId
+channelId
+commandId
+```
+
+缓存内容：
+
+```txt
+当前用户角色集合
+当前作用域策略
+最终权限结果
+```
+
+需要失效的情况：
+
+```txt
+角色成员变更
+角色权限变更
+指令状态变更
+插件加载/卸载
+群覆盖配置变更
+Bot 管理员变更
+```
+
+平台身份缓存可以使用短 TTL。
+
+例如：
+
+```txt
+30 秒
+60 秒
+```
+
+避免群管理员变更后长期不生效。
+
+---
+
+# 20. 权限服务架构
+
+整体可以拆成几个服务。
+
+## 20.1 Command Registry
+
+负责收集命令。
+
+能力：
+
+```txt
+监听命令注册
+生成 commandId
+记录来源插件
+记录 legacyAuthority
+维护 pending/configured/disabled 状态
+提供 WebUI 查询
+```
+
+## 20.2 Role Service
+
+负责角色。
+
+能力：
+
+```txt
+读取内置角色
+创建自定义角色
+管理角色成员
+解析用户当前角色
+```
+
+## 20.3 Policy Service
+
+负责策略。
+
+能力：
+
+```txt
+读取某角色可用指令
+写入角色-指令策略
+处理 global 和 guild 覆盖
+判断 inherit/allow/deny
+```
+
+## 20.4 Permission Evaluator
+
+负责最终判断。
+
+输入：
+
+```txt
+session
+commandId
+```
+
+输出：
+
+```txt
+allow / deny
+reason
+matchedRole
+matchedScope
+```
+
+例如：
+
+```txt
+allow:
+  matchedRole = guild-admin
+  matchedScope = guild:onebot:888888
+```
+
+或者：
+
+```txt
+deny:
+  reason = command_pending
+```
+
+## 20.5 Platform Role Provider
+
+负责把平台身份转为角色。
+
+例如：
+
+```txt
+OneBotRoleProvider
+DiscordRoleProvider
+TelegramRoleProvider
+```
+
+输出：
+
+```txt
+当前用户在当前群是群主/管理员/成员
+```
+
+## 20.6 Legacy Authority Bridge
+
+负责旧插件兼容。
+
+能力：
+
+```txt
+读取命令 legacyAuthority
+给 WebUI 提供建议
+为 session.user.authority 提供兼容值
+```
+
+---
+
+# 21. WebUI 权限边界
+
+WebUI 本身也要受权限系统控制。
+
+例如：
+
+```txt
+查看角色列表：Bot 管理员
+修改全局权限：Bot 管理员
+修改所有群权限：Bot 管理员
+修改当前群自治权限：群主，且只限 allowGuildOverride 的指令
+创建全局自定义角色：Bot 管理员
+创建群内自定义角色：Bot 管理员或被授权的群主
+```
+
+群主即使进入 WebUI，也只能看到当前群可管理内容。
+
+不能看到：
+
+```txt
+其他群配置
+Bot 全局配置
+插件安装卸载
+文件管理
+数据库
+Token
+环境变量
+```
+
+---
+
+# 22. 指令 ID 设计
+
+指令 ID 要稳定，避免重命名导致权限丢失。
+
+推荐格式：
+
+```txt
+command:<pluginName>:<commandPath>
+```
+
+例如：
+
+```txt
+command:music:play
+command:music:clear
+command:admin:plugin.reload
+```
+
+显示名可以变化，但 ID 尽量稳定。
+
+别名不生成新 ID。
+
+例如：
+
+```txt
+/play
+/点歌
+/music play
+```
+
+如果它们指向同一个命令，内部都是：
+
+```txt
+command:music:play
+```
+
+子命令可以独立成 ID：
+
+```txt
+command:plugin:install
+command:plugin:uninstall
+command:plugin:reload
+```
+
+因为它们危险性和授权对象可能不同。
+
+---
+
+# 23. 默认规则
+
+系统默认规则应当保守：
+
+```txt
+新指令：待配置
+待配置指令：只有 Bot 管理员可用
+Bot 管理员：默认可用所有指令
+群主/群管理员/群成员：默认不获得新指令
+```
+
+可以在 WebUI 里提供批量操作：
+
+```txt
+采用插件建议
+本插件所有指令给群成员
+本插件所有指令给群管理员
+本插件所有指令仅 Bot 管理员
+```
+
+但这些必须由 Koishi 管理员确认。
+
+---
+
+# 24. 最终行为示例
+
+## 24.1 签到插件
+
+插件注册：
+
+```txt
+sign
+legacyAuthority = 1
+```
+
+进入 WebUI：
+
+```txt
+待配置指令：签到
+插件建议：群成员可用
+```
+
+Koishi 管理员采用建议：
+
+```txt
+群成员：允许
+群管理员：允许
+群主：允许
+Bot 管理员：允许
+```
+
+结果：
+
+```txt
+普通成员可以签到。
+```
+
+## 24.2 禁言插件
+
+插件注册：
+
+```txt
+mute
+legacyAuthority = 3
+```
+
+WebUI 显示：
+
+```txt
+插件建议：群主可用
+```
+
+Koishi 管理员手动配置：
+
+```txt
+群主：允许
+群管理员：允许
+群成员：关闭
+```
+
+结果：
+
+```txt
+群主和管理员能禁言，成员不能。
+```
+
+## 24.3 删除文件插件
+
+插件注册：
+
+```txt
+file/delete
+legacyAuthority = 3
+```
+
+WebUI 显示：
+
+```txt
+待配置
+插件建议：群主可用
+```
+
+但因为 `authority` 只是建议，不会自动生效。
+
+如果 Koishi 管理员没有配置：
+
+```txt
+只有 Bot 管理员可用。
+```
+
+所以普通群主把 Bot 拉进群，也不能删除文件。
+
+---
+
+# 25. 一句话总结
+
+这套方案的核心是：
+
+```txt
+指令注册后进入权限系统；
+权限管理以角色为中心；
+角色详情页配置可用指令；
+新指令默认只给 Bot 管理员；
+authority 只做建议，不直接授权；
+群主只是当前群角色，不是 Bot 管理员。
+```
+
+这样既能兼容 Koishi 老插件，又不会让普通群主意外获得 Bot 实例级权限，同时 WebUI 也不会变成复杂难懂的权限矩阵。
+
+---
+
+KOISHI侧边栏的图标不使用默认的 使用⌗
+同时根据F:\chatluna-1.4.0-alpha.17 为指令权限限制制作一个AI自动分配