安全与权限
权限
了解 Ship 当前的聊天用户权限模型
权限
当前版本面向用户暴露的权限系统，是 聊天用户权限。
项目 downcity.json 不再提供单独的 permissions 配置块。
运行时执行边界由当前版本的内建行为负责；而“谁可以和 Agent 说话，以及能做什么”则由聊天授权控制。
聊天用户权限
这一层决定“谁可以和 Agent 说话，以及能做什么”。
当前聊天权限采用的是纯权限组模型：
- 每个用户属于一个权限组
- 每个权限组拥有一组权限
- 收到消息时，系统只根据“发消息的用户”来判断是否允许
这里没有 master、owner 一类的特殊身份概念，统一都是权限组。
核心规则
- 新用户进入系统后，会先落到默认权限组。
- 私聊消息是否允许，取决于该用户是否拥有对应私聊权限。
- 群聊、频道里的消息，也只看“当前发消息的用户”的权限。
- 群本身不是权限主体，不单独配置群权限。
- 用户来自哪个平台需要区分，例如 Telegram 用户、飞书用户、QQ 用户会分别识别。
配置保存在哪里
聊天用户权限不会写进项目 downcity.json。
这部分统一保存在 city 全局 ~/.downcity/downcity.db 中，便于集中管理，也不会把用户权限明文散落到项目配置里。同一个 telegram:12345678、feishu:ou_xxx 或 qq:123456 角色会对所有连接该平台的 agent 生效。
底层不是 key-value JSON blob，而是结构化表：
chat_auth_roles：角色chat_auth_role_permissions：角色拥有的权限chat_auth_channel_defaults：各平台默认角色chat_auth_user_roles：平台用户到角色的绑定
在哪里管理
可以在 town chat 的交互式菜单中选择“管理 chat accounts → 管理访问控制”，也可以直接使用 CLI：
town chat auth set telegram:12345678执行后 CLI 会交互式选择目标权限组。常用管理动作包括：
- 查看当前权限组
- 配置某个组拥有哪些权限
- 设置默认权限组
- 把具体用户分配到指定权限组
聊天用户被拒绝时，返回消息会包含类似 town chat auth set telegram:12345678 的命令，用户可以直接转发给管理员。
一个常见的分组方式
default：新用户默认组，权限最低member：允许正常私聊、群聊使用admin：在member的基础上增加管理类权限
你不需要配置审批流，也不需要做额外 pairing。大多数场景下，把用户放进合适的权限组就够了。
一条消息是怎么判断的
当一条聊天消息进入系统时，判断顺序可以理解为：
- 识别消息来自哪个平台，以及是谁发的。
- 根据平台用户标识，查到这个用户绑定的权限组。
- 如果没有显式绑定，就使用该平台的默认权限组。
- 根据消息类型判断需要哪类权限，例如私聊权限或群聊权限。
- 只有发消息用户具备对应权限时，这条消息才会继续进入 Agent。
所以即使消息来自群聊，真正决定是否放行的仍然是“发消息的人”。