docs: clarify workspace owner cardinality

docs/QA.md

@@ -229,7 +229,7 @@ Wiki 模式允许 Agent 根据原始文档自动生成并维护一套结构化
 - 只读用户 → `Viewer`
 - 普通成员（上传文档、维护「自己」的 KB / Agent）→ `Contributor`
 - 运维人员（管理共享模型、向量库、解析器等基础设施）→ `Admin`
-- 空间所有者（拥有删除空间权限，每空间唯一）→ `Owner`
+- 空间所有者（拥有删除空间权限；每空间至少一位，可以有多位，最后一位不能被降级或移除）→ `Owner`
 
 如果你希望开启「invite-only」（不允许自助注册到本空间），可在空间设置里打开邀请制，并通过「邀请」入口签发邀请码或链接。
 

docs/RBAC说明.md

@@ -23,10 +23,12 @@ RBAC 在原有 JWT / API Key 认证之上，叠加了一层**空间内角色矩
 | 只读 | `viewer` | 只查阅、提问的成员 | 仅读，不可发起任何变更 |
 | 贡献者 | `contributor` | 上传文档、维护自己的 KB / Agent | 可变更 `creator_id == 自己` 的资源；他人资源等同 Viewer |
 | 管理员 | `admin` | 空间内运维 | 可变更空间内任意资源；管理成员；配置共享基础设施（模型、解析器、存储、向量库等） |
-| Owner | `owner` | 空间创建者 | Admin 的全部权限 + 可删除空间；不会被其他 Admin 降级；每个空间**有且只有一位** |
+| Owner | `owner` | 空间所有者 | Admin 的全部权限 + 可删除空间；每个空间**至少有一位，可以有多位** |
 
 角色按 `viewer < contributor < admin < owner` 递增，高角色继承低角色权限。
 
+Owner 的数量约束是“至少一位”，而不是“只能一位”。系统允许同一空间存在多个活跃 Owner；降级或移除 Owner 时，只有会导致空间失去最后一位 Owner 的操作才会被拒绝。
+
 ### 鉴权层的两个例外
 
 - **跨空间超管**：`User.CanAccessAllTenants=true` 且 `enable_cross_tenant_access=true` 时，通过 `X-Tenant-ID` 切换到目标空间后等同 Admin，不需要在目标空间里有 `tenant_members` 行。用于多空间运营方。

docs/wiki/安全认证/RBAC说明.md

@@ -27,10 +27,12 @@ RBAC 引入前，只要通过 `X-API-Key` 或 JWT 认证成功，调用方在空
 | 只读 | `viewer` | 仅读 |
 | 贡献者 | `contributor` | 可变更 `creator_id == 自己` 的资源；他人资源按 Viewer |
 | 管理员 | `admin` | 可变更空间内任意资源；管理成员、共享基础设施 |
-| Owner | `owner` | Admin + 可删空间；每个空间唯一 |
+| Owner | `owner` | Admin + 可删空间；每个空间至少一位，可以有多位 |
 
 层级 `viewer < contributor < admin < owner`，高角色继承低角色。
 
+Owner 的数量约束是“至少一位”，而不是“只能一位”。系统允许同一空间存在多个活跃 Owner；降级或移除 Owner 时，只有会导致空间失去最后一位 Owner 的操作才会被拒绝。
+
 ### 鉴权层的例外
 
 - **跨空间超管**：`enable_cross_tenant_access` 打开且账号 `CanAccessAllTenants=true`，通过 `X-Tenant-ID` 切换后等同 Admin。