# 账号权限、协作和配额管理 Input v0

> 阶段状态：Input 根模型主体已确认；2026-08-20 团队会议新增一组待裁剪项、组冻结归档方向和月度配额周期问题，需在进入 Spec 前继续收口。Admin 动作矩阵后置到各模块动作梳理完成后统一处理。
> 来源：`01_Product_Specs/account_permission_collaboration/(【CSM】反馈池)权限账号反馈池.xlsx`，主要读取「需求描述（原始）」列。
> 生成日期：2026-07-10；范围复核：2026-07-13；CRM / 跨境支付范围补充：2026-07-21；账号根模型复核：2026-08-13；对象协作根模型复核：2026-08-14；服务端 Scope 配额口径复核：2026-08-17；团队会议复核：2026-08-20。

> **生效口径**：本 Input 仅有一套当前方案，即「组织身份与组内身份解耦 + 多组成员 + 单组项目 + 全局组身份切换 + Owner/Collaborator 对象协作」。第 7.4-7.13、9.1、9.2 节只保留历史废案及否决原因，不参与 spec、研发或验收。全文出现旧 `T1`、对象 `Viewer / Editor` 时仅用于描述线上字段或历史讨论；当前产品概念统一使用组织 `Owner / Admin / Member`、组内 `T2 / T3` 与对象 `Owner / Collaborator`。只读访问属于查看范围或显式查看授权，不属于协作者身份。

> **UI 标记口径**：`【UI交互】` 表示必须提供用户入口、控件或可操作状态；`【UI反馈】` 表示必须在界面展示校验、确认、进度、结果或通知；`【UI建议】` 表示 Input 阶段对入口复用和复杂度的初步建议。未标记的规则仍需服务端实现，但不一定新增界面。

> **2026-08-20 会议变更口径**：会议提出“考虑移除”的六项能力仍是待决策，不在本次记录中直接改写为已删除；在替代路径确认前，正文原规则继续作为当前基线。会议已明确的“退组由组织 Owner/Admin 操作且必须经过 `REMOVING -> REMOVED`”和“分组不硬删除、改为允许带遗留数据冻结归档”直接并入当前方案。

## 1. 背景

Q3 规划中已经将「账号权限、协作和配额管理」列为独立方向。本次输入来自项目内 CSM 反馈池中的 42 条遗留需求。复核后，本轮主线收敛为「主子账号和权限」；「数据配额」仅将账号级额度分配、个人额度可见性等强关联项作为配套能力，其他项后置；「数据导出」完整沉淀为 TODO，不进入本轮输入主范围。

这些反馈不是单点 UI 优化，而是同一个组织管理问题在不同模块里的重复外显：

- 管理员希望能集中管理成员、账号等级、业务资格、协作范围和额度，不再逐个项目手动补协作者。
- 普通成员希望只看到与自己相关的数据和额度，避免被团队总额度、团队标签、团队项目干扰。
- CSM 希望系统能在席位、权限、额度等场景给出可解释提示，减少误会和人工答疑。
- 研发实现中已有部分基础能力，但分散在子账号、配额、CRM、邮件项目、搜索、跨境支付等页面，缺少统一产品口径。

## 2. 事实依据

### 2.1 反馈池事实

项目内 Excel 与此前 Downloads 中的同名文件 SHA-256 一致。本次重新以项目内文件为唯一来源，原始分类基线为：

| 原始「具体模块」 | 数量 | Excel 行号 | 本 Input 处置 |
| --- | ---: | --- | --- |
| 主子账号和权限 | 18 | 2, 3, 5, 7-9, 11-16, 25, 33, 34, 40-42 | 全部保留在问题池；按证据强度、实现基础和风险拆为 P0 / P1 / TODO |
| 数据配额 | 8 | 4, 6, 10, 17, 27, 35, 39, 43 | 行 10 为账号级强关联 P0，行 17 为低成本高证据 P1，其余进入配额/商业权益 TODO |
| 数据导出 | 16 | 18-24, 26, 28-32, 36-38 | 全部转入 TODO，并保留原始行号，不进入本轮 spec 和验收 |
| 合计 | 42 | 2-43 | 无遗漏 |

为便于产品讨论，再按用户问题交叉聚类为六类；交叉聚类允许同一反馈行出现于两个问题域，但不改变上面的 42 条总数：

| 类别 | 反馈行 | 代表诉求 | 初步判断 |
| --- | --- | --- | --- |
| 组织角色与管理视角 | 11, 12, 14, 40, 41, 42 | 主账号管理视角；管理员/组长分层；查看、编辑、删除边界 | 进入主线，但高风险编辑/删除后置 |
| 子账号检索与成员管理 | 3, 16, 33, 34 | 成员和协作人搜索；席位满邀请拦截；降级续约限制；验证邮件提示 | 搜索进入主线；席位提示研发现状已实现、本版本强制回归；降级续约后置 |
| 数据权限与标签治理 | 2, 5, 13 | CRM 标签删除权限；消息标签按创建来源筛选；CRM 协作人只读 | 进入主线 |
| 项目/资源协作 | 7, 8, 9, 40 | 消息框跨项目协作；管理员强制成为协作人；个人/团队对接范围 | 进入主线 |
| 配额与用量 | 4, 6, 10, 15, 17, 25, 27, 35, 39, 43 | 月度额度/用量、周期展示、单账号剩余、隐藏团队总额、批量加额度、无限制展示、版本权益提示 | 行 10、15、25 为 P0，行 17 为 P1，其余进入专项 TODO |
| 数据导出相邻诉求 | 18-24, 26, 28-32, 36-38 | 导出字段、范围、去重、次数提示、数据一致性、用量记录字段 | 转入 TODO / 数据导出专项，不进入本轮主线 |

### 2.2 `kol-next` 代码事实

已确认的真实实现入口：

| 能力 | 入口/文件 | 当前事实 |
| --- | --- | --- |
| 子账号团队管理 | `../kol-next/pages/brand/sub-account/index.vue`、`assets/script/constant/subAccount.js` | 有成员列表、分组、邀请记录、席位展示和添加成员弹窗；角色值仅有管理员 `1`、成员 `0`、组长 `2`，没有独立「超级管理员」值；成员/邀请列表暂无搜索筛选 |
| 协作人选择器 | `../kol-next/components/filter/cooperatorSelect.vue` | 已支持协作人多选、全选、`canManageMembers` 附加能力和锁定成员；未发现通用只读协作者等级，当前 `el-select` 未开启 `filterable`，无法按昵称/邮箱搜索 |
| 子账号配额管理 | `../kol-next/pages/brand/sub-account/quota.vue`、`components/setting/subAccount/dialog/setQuota.vue` | 有「当期使用 / 累计使用」、按账号表格、单个/批量设置额度、周期起止时间展示；当前 `setType=0` 表示共享团队额度、`setType=1` 表示设置账号上限，已有“不设个人上限”的实现雏形；批量操作仍没有“在现有值上增加/减少”模式 |
| 组成员关系级业务资格 | `../kol-next/pages/brand/sub-account/index.vue`、`components/setting/subAccount/dialog/addMember.vue` | 当前成员列表和邀请流程没有按 `uid + groupId` 配置可分配型 Scope 上限的字段或接口；邀请弹窗只收集邮箱。该能力需要新增 GroupMembership 配额契约，不能复用组织级 `data.vue` 配置冒充；不可分配 Scope 不应为此新增数值配置 |
| 数据管理权限 | `../kol-next/pages/brand/sub-account/data.vue`、`assets/script/constant/subAccount.js` | 当前只覆盖 `crm` 权限列表和 `email[12]` 强制添加管理员协作人 |
| 邮件项目协作 | `../kol-next/components/email/dialogs/createEdit.vue` | 邮件项目有协作人选择和管理协作人能力，可按 `email[12]` 锁定管理员协作人；这里明确只有 `adminStatus=1` 算管理员，`adminStatus=2` 只算组长，说明跨页面角色能力需要统一 |
| 跨境支付 | `../kol-next/pages/payment/list/index.vue`、`pages/payment/list/list.js`、`components/payment/paymentDialog.vue`、`api/payment.js` | 当前有组织钱包 USD 总余额、支付单/草稿列表和“我创建的”筛选；草稿与正式支付单均以 `orderId` 贯通，但未发现账号级模块准入、协作者 ACL、账号支付额度或资金占用台账；创建/更新、手动触发、预约调整、转立即支付、取消/作废分别走独立接口 |
| 主账号动态视角 | 当前子账号/配额页及相关知识库 | 已有按账号配额表和邀请操作记录；研发已确认不存在满足目标字段的跨模块审计模型。本版本优先复用既有列表、账号筛选和创建人/操作人字段，并为高风险写动作新增最小统一审计事件，不建设完整动态中心 |
| 数据导出记录 | `../kol-next/pages/service/data-out.vue` | 仅作为 TODO 事实记录；该页有刷新按钮和导出记录列表，但本轮不围绕数据导出展开 |
| 搜索高级筛选权限 | `../kol-next/pages/search/_platform/_searchType.vue` | 搜索前会通过 `/ws/quota` 对付费筛选项做权限预检；明确 `remainder=0/-1` 才弹升级 |

### 2.3 服务端 Scope 配额事实

服务端团队提供 `scope_quota_product_rules.md`，其元信息标记 `last_verified_at: 2026-08-14`、`confidence: medium`。本 Input 将其作为当前 Scope 产品规则和服务端实现约束的直接证据；它用于修正配额抽象，不覆盖本 Input 已确认的目标组织、组和对象协作模型。

- Scope 是套餐与账号权益的能力标识，不等同于统一的“可扣次数”。现有产品至少包含按结果消耗、团队去重的一次解锁、资源席位或容量、结果窗口、频率限制和纯功能门禁六类语义。
- 组织权益是父级硬边界。子账号个人配置只能收窄组织已有 Scope，不能创造组织套餐不存在的能力；同一 Scope 使用团队共享统计还是实际操作账号统计，由该 Scope 的产品规则决定。
- 现行通用约束主要是组织/主账号总能力与子账号个人上限；研发静态代码确认 `uid + groupId` 的组级上限、多组个人上限、统一 `currentGroupId` 上下文和三级原子消费均不存在，是本需求净新增能力。
- Scope 不授予项目访问或协作权限。即使额度足够，账号仍需通过 GroupMembership、对象 Owner/Collaborator、查看范围和动作权限校验。
- 只有服务端现行允许设置子账号个人上限、且经 Scope 矩阵确认适合向下分配的 Scope，才在本版本增加组级和 GroupMembership 级数值上限；窗口、频率和纯功能门禁等不可分配 Scope 直接继承组织 Entitlement，本期不支持针对单个组或成员关闭。
- 跨境支付金额继续使用组织钱包余额、组级追加分配账本、账号人工上限和资金占用台账，不并入普通 Scope 的通用 `limit / used` 契约。

### 2.4 线上与研发核验边界

已在本机 Chrome 登录态核验 `https://cn.noxinfluencer.com/brand/sub-account/data`，确认 CRM 数据管理线上展示四项写权限；截图保存在 `01_Product_Specs/account_permission_collaboration/crm_write_permissions_online.png`。2026-08-18 研发进一步按旧服务 `project/KOLServer@c8f1ff327c` 与新服务 `project/kol_server_v2@4a42875b` 完成静态代码和 Mapper 核对，结果见 `pm_confirmation_code_evidence_2026-08-18.md`。

该回复已确认 CRM 写权限组合、CRM 全组织读范围、Scope 组级能力缺失、支付正式单/草稿范围、钱包占用时点、现有清退副作用和跨模块审计缺失；但未连接环境或扫描数据库。因此部署分支一致性、空 `ownerUser/creatorUid` 规模、历史组数据分布、外部退款回调和迁移脚本可行性仍不得视为已确认。

### 2.5 行业权威参照

本轮补充调研优先参考官方帮助中心 / 开发者文档，不使用二手博客作为主证据。

调研结论不是“聚星应该照搬一套大而全权限中台”。成熟 SaaS 的共同点更适合作为设计护栏：它们会把 **账号组织、角色权限、团队范围、对象共享、许可证/配额** 拆开建模，避免未来混乱。但聚星当前的真实需求来自 CSM 反馈和已有页面能力，本期应优先做 **增量适配**：

1. 先解决客户已经明确反馈、且归属「主子账号和权限」的痛点：找账号、角色/组长口径、控制标签删除、消息标签按创建来源筛选、管理员默认协作、个人/团队范围。
2. 本版本配额只处理账号权限强相关的部分：隐藏团队总额、子账号额度分配、当前账号剩余额度提示；周期展示作为 P1 评估，月度规则和版本权益提示进入 TODO，导出核对类需求不进入。
3. 先复用 `kol-next` 已经存在的入口：子账号页、配额页、数据管理页、邮件协作人。
4. 行业方案只用于防止错误抽象，例如不要把配额当对象 ACL、不要让管理员在组织策略未开启时天然拥有所有业务数据、不要只靠角色硬编码对象访问；可分配型 Scope 的有效可用量为 0 只阻断对应消耗型动作。
5. 不在本轮做可视化权限矩阵、自定义角色市场、跨组织多账号治理、复杂继承链、全量对象 ACL 控制台。

| 产品 | 官方实现要点 | 对本需求的启发 | 来源 |
| --- | --- | --- | --- |
| Salesforce | 将权限拆成 Profile、Role、Permission Set、Sharing Settings：Profile/Permission Set 决定对象和字段能做什么，Role hierarchy/Sharing Rules 决定具体记录能看哪些；推荐给用户最小基础权限，再用 Permission Set / Permission Set Group 扩展 | Nox 不应只做“主账号/子账号”两级；应拆成「功能动作权限」和「数据可见范围」两套模型。CRM 标签、资源夹、项目记录属于对象级共享，不应仅用角色硬编码 | [Trailhead - Configure Users and Security](https://trailhead.salesforce.com/content/learn/modules/admin-essentials-for-public-sector-solutions/set-up-users-application-categories-regulatory-authorities-and-more), [Trailhead - Role Hierarchy and Sharing Rules](https://trailhead.salesforce.com/content/learn/modules/approval-process-in-salesforce-scheduler/set-up-role-hierarchy-and-sharing-rules) |
| HubSpot | 权限由 seat 限制下的用户权限控制；对象访问常见范围为 All、Their team's、Their；Permission Sets 用来复用一组权限，不必逐个用户手配 | 可采用「全部 / 本组 / 自己」表达 CRM、项目等数据范围；消息标签本期只借用该范围表达做创建来源筛选，不升级为权限模型；配额/seat 与权限集要分离 | [HubSpot user permissions guide](https://knowledge.hubspot.com/user-management/hubspot-user-permissions-guide), [Create and assign permission sets](https://knowledge.hubspot.com/user-management/create-permission-sets) |
| GitHub Enterprise | 区分 Organization roles、Repository roles、Team roles；角色是一组 permissions，可分配给个人或团队；仓库级角色遵循最小权限原则，也支持自定义角色 | Nox 可采用「组织级管理角色 + 对象级协作角色」双层：现有管理员负责组织管理；资源夹/邮件项目/监控项目的协作人角色属于对象级 | [Roles in an organization](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization), [Repository roles for an organization](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) |
| Google Workspace | Admin Role 由 privileges 组成，可使用预置或自定义角色；角色可赋给用户或安全组；部分角色可限制在特定 Organizational Unit；Super Admin 不能通过普通组分配 | Nox 可借鉴“组织管理身份与组织单元范围分离”，但组内 T2 仍是业务身份；现有组织管理员映射为 Admin，而不是跨组业务 T2 | [Administrator privilege definitions](https://knowledge.workspace.google.com/admin/users/administrator-privilege-definitions), [Assign specific admin roles](https://knowledge.workspace.google.com/admin/users/assign-specific-admin-roles) |
| Atlassian Cloud | 拆分 Organization admin、Site admin、App admin；组织管理员管理用户、组、安全；应用管理员管理特定 app；组织管理员本身不自动拥有所有 app 内容访问 | Nox 不要让“账号管理员”天然拥有所有业务对象操作权；需要区分「管理账号/权限」和「访问业务内容」 | [What are the different types of admin roles?](https://support.atlassian.com/user-management/docs/what-are-the-different-types-of-admin-roles/) |
| Slack Enterprise | Workspace / Organization 两级；System roles 可叠加赋予成员；User groups 可管理 workspace、channel membership 和权限 | Nox 可把「分组」从展示字段升级为可授权主体：组可被自动加入资源夹/项目协作，也可作为标签/项目可见范围 | [Types of roles in Slack](https://slack.com/help/articles/360018112273-Types-of-roles-in-Slack), [Manage user groups from the admin dashboard](https://slack.com/help/articles/115004952926-Manage-user-groups-from-the-admin-dashboard) |
| Notion | Workspace member、guest、group、teamspace、page permission 多层组合；页面可分享给个人、群组、teamspace 或外部 guest，并设置权限级别 | CRM/资源夹等协作对象可参考其共享语义；消息标签的客户痛点是数量太多、难找，本期不引入私有或指定成员共享 | [Sharing & permissions settings](https://www.notion.com/help/sharing-and-permissions), [Who’s who in a workspace](https://www.notion.com/help/whos-who-in-a-workspace) |
| Stripe | Organization 可包含多个 account；管理员可在组织级查看成员、给成员分配 organization/account 角色；多个角色会合并权限，但官方提醒要注意权限冲突和意外授权 | Nox 若支持多品牌/多账号空间，需提前区分 organization-level 和 account-level；多角色叠加时需要可解释的“最终权限预览” | [Manage access to your organization](https://docs.stripe.com/get-started/account/orgs/team), [User roles](https://docs.stripe.com/get-started/account/teams/roles) |

#### 从聚星现状反推的适配原则

行业调研对聚星最有价值的不是“功能全集”，而是以下取舍原则：

| 原则 | 用户问题 | 聚星已有基础 | 本期增量方向 |
| --- | --- | --- | --- |
| 组织身份和组内身份分开 | 老板、全局管理员也要作为执行成员参与日常业务 | 现有 `adminStatus=0/1/2` 混合了组织管理与组内角色 | 组织侧使用唯一 Owner、0..N Admin、Member；每条 `GroupMembership` 独立记录 T2/T3，组织身份不产生业务对象权限 |
| 权限动作和数据范围分开 | 客户说“主账号能看/编辑子账号所有数据”，但真实风险是不同对象操作风险不同 | `data.vue` 已有 CRM / Email 数据管理配置雏形 | 先把 CRM 标签删除、邮件/资源/监控协作这几个反馈高频动作独立成开关，不做全量自定义权限集 |
| 配额和权限分开 | 客户混淆团队总额度、个人剩余额度、套餐周期 | `quota.vue` 已有当期/累计、账号表格、批量设置 | 先做账号权限相关的配额解释和隔离；月度规则原为低优，2026-08-20 因“年付额度按月向下分配”升级为是否进本期的待确认项 |
| 分组是业务隔离边界 | 客户需要平行团队的数据、配置和额度隔离，又不希望引入嵌套组织 | 成员页已有分组和组长，但未形成统一业务上下文 | 账号可加入多个组，通过全局组身份切换确定当前业务上下文；项目固定归属于一个组，本期不允许跨组协作 |
| 对象共享只覆盖高频协作对象 | 客户不想每个项目重复添加协作者 | 邮件项目已有协作人和强制管理员协作人，CRM 已有记录对接人，支付单已有稳定 `orderId` 和创建人范围 | 本期覆盖邮件、资源夹、内容监控、CRM 记录和跨境支付单/草稿；组织可开启“组长默认成为组内所有项目协作者”，以 T2 系统来源替代旧 Admin/T1 强制协作；旧任务列表与消息会话进入 Backlog |

#### 内部建模护栏，不作为本期功能全集

行业成熟方案可以抽象成一个 Nox 内部的「九层权限模型」。这只是后续 spec/研发建模时的护栏，不代表本期要全部产品化：

| 层级 | 解决的问题 | Nox 建议落点 |
| --- | --- | --- |
| 1. 组织 / 账号空间 | 谁属于同一个企业，主账号和子账号关系是什么 | 抽象 `Organization`；组织内有且仅有 1 个 Owner、0..N Admin 与普通 Member，Owner 可迁移但组织不可由主账号直接解散 |
| 2. Plan / Seat | 企业买了什么、最多能分多少 | 功能 Entitlement、子账号席位、组织总额度；作为账号配置不能突破的硬上限 |
| 3. Organization Role | 这个人能否管理组织或一组团队 | Owner / Admin / Member；Admin 的管理范围可覆盖 0..N 个组且可重叠，管理范围只授予管理和汇总能力，不授予业务明细权限 |
| 4. GroupMembership | 这个人在什么业务组、以什么身份工作 | 一个账号可有 1..N 条 `GroupMembership`；每条关系独立保存 `groupId`、T2/T3、状态和配额配置；每组允许 0..N 名 T2 |
| 5. Group Permission / Quota Ceiling | 一个组最多可消耗多少 | 仅对可分配型 Scope 增加组级 `inherit / capped` 上限；不可分配的门禁、窗口和频率能力直接继承组织 Entitlement；T2 仅在组织开关允许时管理本组账号配置且不得突破组上限 |
| 6. Membership Grant / Allocation | 某账号在某组可消耗多少 | 可分配型 Scope 按 `uid + groupId` 配置 `inherit / capped`；不设置横向 Permission Set 或岗位模板；不可分配 Scope 不出现数值输入；跨境支付独立使用组级追加分配账本与账号人工上限，组织层受钱包可用余额约束 |
| 7. Organization Policy | 账号进入业务后，统一业务规则如何生效 | 组长是否默认成为组内所有项目协作者、支付同组查看范围、标签管理限制、T2 邀请或管理权限等组织级策略；策略不生成跨组权限，也不能突破配额、组身份等硬限制 |
| 8. Active Group Scope | 本次业务动作属于哪个组 | 全局当前组决定项目创建、候选成员、组内筛选和配额扣减上下文；切换组不改变已有项目 `groupId` |
| 9. Project/Object ACL / Sharing | 某个具体项目或对象实例分享给谁、能做什么 | 项目型对象固定保存 `groupId`、唯一 `ownerUid` 和协作者关系；CRM 等组属业务记录固定保存 `groupId`，个人责任字段 `assigneeUid` 可空，不强制建立项目 Owner。协作者默认获得对象常规业务读写，不再分 Viewer/Editor；只读需求单独保存为查看范围或显式查看授权，附加能力按需保存。只有同组 `ACTIVE` 成员的对象授权生效；组织策略开启时，T2 系统协作是一种可解释的普通协作者来源 |

#### 权限规则分类

后续每条权限结论必须归入以下一种类型，不把所有规则都做成开关：

| 类型 | 定义 | 当前已确认内容 |
| --- | --- | --- |
| 系统不变量 | 保证身份、权限计算和数据安全可以稳定解释，组织不可修改 | 组织唯一 Owner；账号可加入 1..N 组；每组 0..N T2；项目型对象唯一 `groupId`、`ownerUid`；CRM 记录必须有 `groupId`、允许 `assigneeUid` 为空；同组 `ACTIVE` 是对象授权生效前提；不允许跨组协作；协作者默认拥有常规业务读写；只读范围不成为协作者且不产生写权限；附加能力不可转授；多重授权按来源合并正向能力；硬限制优先；资金承担与执行人分离；退组完成前必须处理项目型 Owner 对象 |
| 组织/分组管理配置 | Owner/Admin 在管理范围内设置委派边界 | Admin 管理范围、可分配型 Scope 的组上限、组成员关系；管理范围允许汇总查看和管理动作，但不产生项目 ACL |
| GroupMembership 直接配置 | 对账号在某个组的身份和可分配资源直接配置 | T2/T3、可分配型 Scope 的 `inherit / capped`；下级上限之和允许超过父级，实际消耗按 Scope 规则逐层拦截；不可分配 Scope 直接继承组织 Entitlement；跨境支付账号上限默认 `unlimited`，组级显式分配只允许追加并逐笔留痕，资金来源仍为组织钱包 |
| 组织策略 | 允许企业统一配置业务规则，不改变根模型 | 组长是否默认成为组内所有项目协作者、T2 是否可管理本组账号权限、T2 是否可邀请成员进入本组、同组成员是否获得支付单查看范围、级联敏感信息读取、内容监控标签管理限制；策略不能产生跨组授权 |
| 对象级人工授权 | 在同组边界内，对单个对象分配或调整 | 转交项目 Owner、设置 CRM Assignee、添加/移除 Collaborator、授予/收回显式查看权限、向协作者授予/收回 `can_manage_collaborators`，以及支付单的 `can_execute_payment`；支付 Owner 仅可经数据移交流程改变 |
| 套餐/系统约束 | 由产品版本、席位和额度决定，组织配置不能突破 | 子账号席位、Admin 数量上限预留、功能 Entitlement、组织/组配额、组织钱包余额、账号及 GroupMembership 状态 |

“T2 能否管理本组账号权限”和“T2 能否邀请成员进入本组”为组织全局开关；Owner 与 Admin 均可修改。“组长是否默认成为组内所有项目协作者”同样是组织级全局开关，Owner 可修改，Admin 是否可修改及所需管理动作权限进入 Admin 动作矩阵。其他组织策略的操作主体在 spec 动作矩阵中按风险收敛。任何策略都不生成跨组协作者；显式授权必须绑定具体对象。该组长协作开关开启时，系统按 `groupId + ACTIVE T2` 动态计算并展示授权来源，不批量写入对象 ACL；关闭时只撤销该系统来源，不影响显式协作者、显式查看授权或附加能力。修改影响已有对象时必须展示影响范围、二次确认并记录审计日志。

本期只落其中最贴近反馈池和现有代码的部分：

- 必做：组织身份与 GroupMembership 分离；可分配型 Scope 的正式分组上限与 `uid + groupId` 个人上限；全局组身份切换；少量 `Object ACL / Sharing` 的协作对象扩展；进入 spec 前建立 Scope 类型与可分配性矩阵。
- 暂缓：横向角色、Permission Set、岗位权限模板、账号级模块内动作矩阵、复杂组织层级、多组织/多账号空间、全对象 ACL、权限冲突预览。

#### 对本 Input 的口径修正

基于以上参照，本需求后续不建议表述为「主账号支持查看、编辑子账号所有数据」这种绝对句式，而应改为：

- Owner / Admin 在各自管理范围内拥有 **管理成员关系、分组上限和汇总数据** 的组织管理权限；组织管理身份不隐式产生任何业务对象权限。
- 业务对象的数据访问通过 **Owner / Collaborator、查看范围与附加能力** 共同控制，管理员是否能直接查看、编辑、删除，需要由对象类型和风险等级决定。
- T2 是 `GroupMembership` 上的 **组内业务负责人**，不是弱化版 Admin。账号在每个组可分别为 T2 或 T3；只有组织策略“组长默认成为组内所有项目协作者”开启时，T2 才通过系统来源成为本组项目 Collaborator，高风险动作仍需独立能力判断。
- 项目型对象统一采用 **Group + Owner / Collaborator**：对象固定归属于一个组，不随 Owner 改组自动迁移；协作者默认拥有对象允许的常规业务读写，不再设置通用 Viewer/Editor 或 `can_edit`。只读访问另用范围可见或显式查看授权表达；Owner、协作者和显式查看对象必须是对象组内 `ACTIVE` 成员，本期不允许跨组授权。
- 套餐/seat、Scope 产品类型、可分配上限、组织策略和对象 ACL 需要分开建模；本版本不设置独立模块启用/禁用字段。不可分配的门禁、窗口和频率类 Scope 随组织 Entitlement 继承，不能用“额度为 0”模拟成员级禁用；可分配上限只控制对应 Scope 的使用，不直接替代对象读权限。
- 对 CRM、搜索数据范围等场景，`自己 / 当前组 / 管理范围汇总` 分别对应对象责任、当前业务组和组织管理视角；“全组织汇总可见”不等于可进入任意项目明细。消息标签仅使用相似文案做创建来源筛选，不混入权限模型。

## 3. 本轮目标

本轮目标不是新增一个独立后台，也不是建设大而全的权限中台，而是在现有子账号、数据管理、邮件协作页面上补齐「主子账号和权限」主线；配额页只做必要配套：

1. 管理员能更快找到成员和项目协作人，并完成目前已经存在但不好用的角色、分组、邀请、额度操作。
2. 与子账号管理强相关的额度分配、团队总额隐藏、当前账号剩余额度解释清楚，减少 CSM 人工答疑。
3. 普通成员只看到自己或被授权范围内的数据、项目和用量，并能按创建来源收窄消息标签列表。
4. 把邮件项目已有的“强制管理员协作”收敛为组织策略“组长默认成为组内所有项目协作者”；开关开启时，同组 T2 通过动态系统来源成为项目普通 Collaborator。显式协作者、显式查看授权和附加能力必须绑定具体项目、CRM 记录或支付单/草稿，且只有对象组内 `ACTIVE` 成员的授权生效。邮件、资源夹、内容监控、CRM 和跨境支付作为 P0；CRM 线上四项写权限等价迁入统一模型，跨境支付补齐同组查看范围、敏感读取、资金执行、支付金额配额与历史收款账号共享；旧任务列表和消息会话进入 Backlog。
5. 对权限不足、席位不足、配额不足给出前置和可解释提示。

本轮明确不追求：

- 不做完整自定义角色/权限集配置器。
- 不做全站所有对象的统一 ACL 控制台。
- 不做跨企业、多组织、多品牌账号空间治理。
- 不重构支付通道、组织钱包资金台账、套餐或计费系统；本轮只接入支付金额配额校验、对象协作和资金占用所需的接口，不改变钱包余额作为组织支付硬上限的事实。
- 不做数据导出专项。
- 不把所有业务数据和编辑/删除能力默认开放给主账号或管理员。

## 4. 用户与场景

### 4.1 组织 Owner / Admin

作为组织 Owner 或 Admin，我希望能在全组织或获分配的管理范围内集中管理成员、分组、权限上限和配额，并查看管理范围汇总；当我参与具体业务时，仍按自己当前组的 T2/T3 身份和对象 ACL 工作。组织中有且仅有一名 Owner，并允许设置多名 Admin 承担日常组织管理。

关键场景：

- 公司有 20+ 子账号，人员频繁变动，需要通过邮箱/昵称快速搜索账号。
- 新增成员后，希望在邀请时显式配置其首个组、组内身份和业务配额，不产生不可解释的默认权限；跨境支付账号上限默认 `unlimited`，邀请者可在允许范围内显式设置。
- 希望看到管理范围内各组的使用和额度汇总，便于管理预算和复盘；汇总查看不自动授予项目明细权限。
- 希望限制普通成员删除 CRM 标签、查看团队总额度或操作他人资源。

### 4.2 T2（现“组长”）

作为某个组的 T2，我希望在组织开启组长默认协作策略时自动查看和协作本组项目，并在其他委派开关开启时管理本组账号配置或邀请新成员进入本组；策略关闭时，我仍按对象 Owner、显式授权和其他范围规则参与项目。我不能清退成员、调整既有 GroupMembership、修改组织身份，也不能访问其他组的数据。同一账号可以在多个组分别担任 T2 或 T3，切换当前组后再以对应身份工作。

关键场景：

- 按小组管理邮件开发、CRM、数据看板。
- 查看本组汇总和用量；项目明细需命中组长默认协作策略或其他有效对象授权。
- 组织策略开启时，作为本组项目的系统普通协作者参与工作并获得常规业务读写；策略关闭时不产生该来源。无论开关状态，T2 身份都不自动获得协作者管理、支付执行等附加能力。

### 4.3 普通成员

作为普通成员，我希望系统只展示我负责或被授权的数据，避免团队标签、团队项目和团队额度混在一起。

关键场景：

- 只看自己的剩余额度和消耗。
- 消息中心标签可以按「我创建的 / 当前组成员创建的 / 全部」快速筛选，减少团队标签过多造成的查找干扰。
- 搜索隐藏已沟通/合作网红时，可以区分「我对接过」和「团队成员对接过」。

### 4.4 CSM / 客户成功

作为 CSM，我希望系统在席位、权限和账号额度上给出明确提示，减少客户误解。

关键场景：

- 企业版周期不是自然月，用户误以为每月 1 号更新。
- 子账号席位满后，当前提示不清晰。
- 客户无权限选择高级筛选项时，希望前置说明而不是搜索后才弹升级；该项属于商业版本权益体验，不进入本版本。

## 5. 范围定义

### 5.1 组织成员与角色体系

#### A1. 成员与协作人搜索（P0）

现状问题：反馈中有客户 27 个子账号，内部账号变动频繁；同一条反馈还明确提出项目协作人需要按账号筛选。当前成员页没有搜索，公共协作人选择器也未开启搜索。

需求：

- 【UI交互】团队成员列表支持按邮箱、昵称搜索。
- 【UI交互】协作人选择器支持按昵称、邮箱搜索，并复用到邮件项目、资源夹、内容效果监控、CRM 记录及支付单/草稿等本版本 P0 对象。
- 搜索只过滤当前组织、当前模块和当前对象原本允许选择的账号，不因命中关键词扩大可选账号范围。
- 【UI交互】邀请记录按邮箱搜索、成员按角色/分组筛选作为 P1 搭车项，不阻塞 P0。

验收：

- 当团队成员数大于 20 时，管理员能通过邮箱/昵称快速定位目标账号。
- 协作人超过一屏时，用户能通过昵称/邮箱定位目标成员，不需要逐项滚动查找。
- 套餐未包含对应业务、账号停用、邀请待接受等原本不可被选为有效协作者或显式查看对象的账号，不因搜索结果命中而变为可选；可分配型 Scope 的有效可用量为 `0` 不单独阻止其成为候选，但对应消耗型动作仍会被拦截。
- 搜索不影响原有分页、分组、设为管理员、设为组长、删除成员等操作。

#### A2. 组织身份、组内身份与管理范围（P0）

需求：

| 身份层 | 当前实现/建议口径 | 本期处理 |
| --- | --- | --- |
| 组织 Owner | 企业账号所有者，由主子账号关系识别，不是 `identifyMap` 中的独立角色值 | 【UI交互】全组织唯一；拥有完整组织管理范围，以及 Owner 转让、账单/合同/组织支付设置、任免 Admin 等所有者专属动作；不能解散组织；同时必须通过 GroupMembership 以 T2/T3 参与业务 |
| 组织 Admin | 现有 `adminStatus=1` 的组织管理能力 | 【UI交互】可设置 `0..N` 名，并配置 0..N 个可重叠管理组；在范围内管理组、成员关系、权限/配额上限和汇总数据；不拥有 Owner 专属动作，也不因 Admin 身份获得项目明细权限 |
| 组织 Member | 组织内无 Owner/Admin 管理能力的账号 | 只能通过自己的 GroupMembership 和对象授权参与业务；组织身份与模块、配额、项目协作解耦 |
| 组内 T2 | 现有 `adminStatus=2` 需要迁移到 GroupMembership | 【UI反馈】每组允许 `0..N` 名；组织的组长默认协作策略开启时成为本组项目普通协作者，但不自动获得附加能力或高风险治理动作；其他组织开关可另行允许其管理本组账号权限/配额或邀请新成员进入本组，但不能维护既有成员关系或组织身份 |
| 组内 T3 | 普通执行成员 | 在当前组保持 `ACTIVE` 且具备对象权限后，查看对象；需要消耗配额的动作再按对应配额校验 |

验收：

- 同一个账号在成员页、配额页、数据管理页和项目协作人列表中的组织身份、当前组及当前组身份解释一致；不再用单一 `adminStatus` 同时承担两层含义。
- 每个组织有且仅有一名 Owner，Admin 为 `0..N`；Owner/Admin 的组织管理范围与其各组 T2/T3 身份独立计算。
- 一个账号可有多条 `ACTIVE` GroupMembership；每条关系只能是 T2 或 T3，每组允许 `0..N` 名 T2，并允许先建无成员、无 T2 的空组。
- Owner/Admin 可以添加、移除 GroupMembership；Admin 只能操作管理范围内的组。T2 不能维护既有成员关系；仅在组织邀请开关开启时可邀请新账号直接成为本组 T3。
- `adminStatus=2` 迁移后在所有页面都按当前 GroupMembership 的 T2 解释，不因 `Boolean(adminStatus)` 被误当组织 Admin。
- Owner/Admin、T2/T3 均不作为模块和配额的权限聚合体；修改身份不会自动复制另一组的模块、配额或 ACL。
- 账号未在对象组保持 `ACTIVE` GroupMembership，或套餐不包含对应业务时，组织身份、T2 系统协作来源和显式对象授权均不能绕过该硬限制；可分配型 Scope 的有效可用量为 `0` 只影响对应消耗型动作。
- 删除、负责人转交、协作者管理不能仅凭模块“编辑”权限执行，必须通过独立动作权限判断。

#### A3. 组织管理视角与组成员权限配置（P0）；编辑/删除能力（TODO）

需求：

- 【UI建议】本版本不新建“团队动态中心”，优先在现有成员、配额和业务列表中补齐账号、当前组、创建人和负责人筛选；Owner/Admin 可查看管理范围汇总，但进入项目明细仍需当前组身份和业务授权。
- 【UI交互】团队成员列表提供统一的“组内身份与配额”入口；可分配型 Scope 的模式/上限按 `uid + groupId` 保存，不绑定横向角色、Permission Set 或岗位权限模板。不可分配 Scope 只读展示“随组织权益”，不提供数值输入。
- 【UI交互】Owner/Admin 为管理范围内各组设置可分配型 Scope 的 `inherit / capped`，并可直接维护该组每条 GroupMembership 的 T2/T3 和可分配上限；不可分配 Scope 不进入组上限配置。
- 【UI交互】全局委派开关开启时，本组任一 T2 都可以在组上限内修改自己及本组 T2/T3 的可分配型 Scope 配置；不可分配 Scope 仍只读继承组织权益。所有 T2 权限对等，不额外设置“首席 T2”。
- 不存在“未分组业务态”或隐藏分组。迁移时所有存量成员和业务对象归入一个真实默认组；新成员必须至少配置一个业务组后才能完成邀请。
- 【UI交互】引入新成员时必须经过显式“首个组 + T2/T3 + 可分配型 Scope 配额”表单：可分配型 Scope 默认 `inherit`，表示不设个人上限、使用组共享额度；不可分配 Scope 只读展示“随组织权益”；跨境支付只读展示目标组当前资金状态，账号支付上限默认 `unlimited`，邀请者可在允许范围内改为具体金额。邀请者可以在最终确认前修改可配置项，本版本不使用分组默认配置模板。
- 【UI交互】Owner/Admin 邀请时可选择其管理范围内的组；组织邀请开关开启时，T2 只能邀请新账号作为本组 T3，不能修改目标组。邀请完成后再加入其他组，由 Owner/Admin 通过独立 GroupMembership 流程处理。
- 【UI反馈】邀请确认前展示目标组、组内身份、可分配型 Scope 的模式/上限、随组织继承的能力摘要和席位占用；提交或接受邀请继续复用现有席位满校验。
- 本版本账号直配粒度只到“可分配型 Scope 的模式/上限”，不为每个账号配置模块内查看、编辑、删除动作矩阵，也不设置独立模块启用/禁用字段。纯门禁、窗口和频率类能力本期不能针对单个成员关闭。
- 账号在当前组拥有相应业务资格只代表可以尝试完成对应动作；进入后，系统针对对象 `groupId` 继续合并 Owner、显式协作者、显式查看授权、组织策略开启时的 T2 系统协作来源、附加能力和硬限制。可分配型 Scope 的有效可用量为 `0` 时不直接隐藏已有对象或撤销对象授权。
- 【UI交互】多组账号必须先切换当前组；项目创建、协作者候选、标签来源筛选和配额扣减均使用当前组上下文。切换组不改变已有项目归属。
- 【UI交互】配额页继续提供按 GroupMembership 的用量；资源夹和内容监控优先补归属组、创建人/协作人信息及筛选；旧任务列表不在本版本搭车扩展。
- 「查看所有子账号全部动作」若需要完整审计轨迹，单独依赖后端事件/日志能力评估，不在本 Input 中假设已经具备。

后置项：

- 主账号编辑或删除子账号创建的收藏夹、CRM 标签、邮件项目、监控项目，需按对象类型分别评估，不做无差别全开。
- 对高风险编辑/删除增加二次确认和操作日志；反馈行 42 已注明刚需和杠杆待确认，不进入本版本。

边界：

- 不默认开放主账号直接删除任意子账号所有历史数据。
- 套餐无权益、账号停用和非 `ACTIVE` GroupMembership 是硬限制，不能通过 Owner/Admin/T2 身份或对象 ACL 绕过；可分配型 Scope 的有效可用量为 `0` 只阻断对应消耗动作，不等同于关闭模块，也不直接收回对象读取。
- 账单、合同和组织支付设置仅 Owner 可访问，Admin 不继承这些所有者专属权限。

### 5.2 账号权限关联的配额配套

配额反馈不作为本轮主线。行 10、15、25 与“按账号分配和隔离额度”直接相关，列为 P0；行 17 虽关联度低，但有 `10+` 次反馈且现有页面已有基础，列为 P1；行 4、6、27、35、43 和商业版本权益行 39 进入 TODO。

#### B0. 类型化 Scope 与可分配型三级使用上限（P0）

已确认口径：

- Scope 先按产品语义分类，再决定是否存在可分配上限和可展示用量；不建立覆盖所有 Scope 的统一 `limit / used` 假象。进入 spec 前必须形成 Scope 矩阵，至少标记 `产品类型、组织计量范围、是否可向组/成员分配、周期、去重对象、返还/释放规则、业务上下文来源`。
- 只有可分配型 Scope 进入组织/组/GroupMembership 三级约束。组织层继续使用现有 Entitlement 和团队总量；组和 GroupMembership 层新增 `inherit / capped(limit)`。`inherit` 表示不追加本层上限，仍受所有父级约束；`capped` 表示增加本层最大可用量，不代表预留额度。
- 纯功能门禁、结果窗口和频率限制等不可分配 Scope 直接继承组织 Entitlement，本期不提供组级或成员级禁用、数值上限和“剩余量”输入。资源容量、一次解锁等其他类型是否可分配，以 Scope 矩阵为准，不能仅凭存在数值配置推断。
- 支付金额配额不属于普通 Scope 通用契约；由组织钱包可用余额、组级追加分配账本和账号人工上限共同计算，并保存支付 `pending`。
- 【UI反馈】组织层的跨境支付 `payment_amount` 不保存 `unlimited`，其有效上限直接取支付域返回的组织钱包当前可用余额（暂定 `walletAvailableAmount`；该值应已包含支付域对已支付和已形成待支付占用的处理）。组默认使用组织尚未向其他组承诺的共享余额；组织需要部门资金隔离时，可以向组追加分配明确金额。账号层默认 `unlimited`，表示不追加账号上限，允许改为具体金额。
- 【UI交互】【UI反馈】组级普通配置不提供可直接改小的总额输入，只提供“追加分配”。每次追加金额必须大于 `0`、不超过组织当前未分配余额，并新增不可修改的分配记录；至少记录 `allocationId、organizationId、groupId、amount、currency、operatorUid、reason、beforeLimit、afterLimit、createdAt`。组支付上限等于有效分配记录的累计净额，正常分配动作只能增加。
- 组织当前未分配余额按“组织钱包可用余额减去所有已分配组的剩余可用金额”计算；增加某组上限时只校验本次增加量不超过该余额，不能持续使用“所有组历史上限之和不超过当前钱包余额”的错误条件。已分配组的剩余可用金额按组上限扣除已支付和 `pending` 计算；未显式分配的共享组只能使用组织未分配余额，不能消耗其他组已承诺的剩余额度。
- 【UI交互】组上限减少不作为普通编辑能力。纠错、组关闭或预算回收必须创建引用原分配记录的独立冲正/收回交易，不修改原记录；冲正金额不得超过原分配尚未冲正部分和该组当前未支付、未占用余额。该操作必须二次确认、填写原因并完整审计，最终操作主体进入 Admin 动作矩阵。
- 配置可分配型 Scope 时，单个分组的 `capped` 不得超过组织当前有效上限，单条 GroupMembership 的 `capped` 不得超过组当前有效上限；同一父级下多个子级 `capped` 之和允许超过父级，不在配置时要求总和守恒。
- 对象型动作使用对象稳定 `groupId` 和实际操作人 `uid` 定位 GroupMembership；搜索、榜单、详情等无业务对象动作使用经服务端验证的 `currentGroupId`。切组只改变之后的配额归属，不改写历史消耗。
- 可分配型 Scope 的实际校验、去重、扣减、占用、释放或返还仍由该 Scope 产品规则决定。需要消耗或占用时，上限校验与用量写入必须由后端原子完成；团队去重 Scope 只有首次形成有效使用时计入对应组和实际操作账号，后续团队内复用不重复计入。
- 存量 Scope 迁移不为补齐 `groupId` 伪造无法证明的历史归属。组织级历史用量、占用、已解锁状态和有效剩余额度继续按线上口径承接；只有能从现有业务对象、操作账号或其他稳定证据确定归属的数据才迁入默认组或默认组 GroupMembership。
- 资源席位、容量等反映当前业务对象状态的 Scope，按迁移后对象的稳定 `groupId` 计算默认组当前占用；仅有事件记录且无法可靠关联对象或组的历史消耗保留为组织级基线，不回填组用量。默认组初始使用 `inherit`，因此不要求伪造组账也能继续受组织剩余额度约束。
- 现有账号个人上限迁入该账号的默认组 GroupMembership；可稳定按 `uid` 汇总的本周期个人用量一并承接，无法稳定归属的部分只保留在组织层。账号之后加入其他组时，默认组历史个人用量不计入新组 GroupMembership。
- 已在组织内完成的一次解锁继续全组织复用，不追溯向默认组或账号扣量，也不得因历史记录缺少 `groupId` 再次收费。上线后首次形成的新消耗、占用或解锁必须保存经服务端验证的 `groupId + actorUid`；项目型动作取对象组，无对象动作取 `currentGroupId`，缺少有效组上下文时不得静默记到组织或默认组。
- 【UI反馈】只有存在可比较的 `limit / used` 或容量占用语义时，才展示剩余量和耗尽层级。下调 `capped` 低于当前有效用量/占用时不回滚历史，当前可用量按 `0` 处理并在保存前展示影响；纯门禁、窗口和频率类 Scope 不伪造剩余量。
- 【UI交互】第一版前端继续采用组成员关系级二选一：`使用所属组共享额度` 将全部可分配型 Scope 设为 `inherit`，`设置个人上限` 才展示可分配项输入；暂不增加逐 Scope 模式切换。不可分配 Scope 单独只读展示，不参与二选一。
- 【UI反馈】`inherit` 的展示文案统一使用“不设个人上限，使用所属组共享额度”；不可分配 Scope 使用“随组织权益”；支付金额的 `unlimited` 展示为“不设额外支付金额上限，受组织钱包余额约束”，不能展示为真正的无限支付。
- 【UI反馈】支付金额配额在预约提交时立即形成 `pending` 占用。已分配组的实际可用支付金额取“组织钱包可用余额、组级剩余可用金额、账号级上限剩余”的最小值；共享组使用“组织未分配余额、账号级上限剩余”的最小值。取消、失败释放和退款回补均按原 `fundingGroupId + fundingUid` 冲正，不能返回其他组或账号。

未来若将某个普通可分配型 Scope 改为预先切分的配额池，再把该 Scope 的配置校验改为“本次增加量不得超过父级未分配余额”。切换时必须单独处理存量超配状态，不能假设所有 Scope 共用同一组 `limit / used` 字段。支付金额已经使用独立的组级资金守恒规则，不适用普通 Scope 的同层超配策略。

#### B1. 当前周期明显展示（P1）

现状事实：配额页和线上页面已有 `startTime/endTime` 展示，但只是“当期使用 / 累计使用”切换控件下方的一行说明文字；反馈仍有 `10+` 次误解，说明位置和文案不够有效。

已确认落地口径：

- 【UI建议】不新增页面或弹窗，继续使用现有 `/brand/sub-account/quota`。
- 【UI交互】仅在“当期使用”状态展示，位置固定为切换控件下方、额度汇总卡片上方，确保进入页面首屏可见。
- 展示两行：标题 `会员配额周期`，内容 `YYYY-MM-DD HH:mm 至 YYYY-MM-DD HH:mm`。该周期只解释后端当前团队配额汇总口径，不覆盖每日上限、频率窗口、跨周期解锁历史或永久容量。
- Owner、Admin、T2、T3 在各自有权访问的当前组或管理范围额度视图中使用同一周期字段和文案。
- 只展示后端返回的实际起止时间，不新增“每月 X 日更新”等推导文案，不修改周期计算、额度重置规则或接口；逐 Scope 周期仍由其产品规则决定。
- 不增加历史月份选择、按月统计或逐配额项周期标识；这些仍属于 B2 配额专项。
- 周期字段缺失时不自行推算，隐藏日期内容并记录接口异常。

验收：

- 用户进入配额页“当期使用”首屏即可在汇总卡片之前看到实际额度周期。
- 切换到“累计使用”时不错误展示“会员配额周期”。
- 本项上线前后后端周期值、重置时点和历史用量完全一致。

#### B2. 月度配额、月度用量与按月重置标识（待确认）

该需求原本作为低关联 TODO；2026-08-20 会议提出“年付套餐与月度下级分配”场景后，升级为配额模型待确认项。是否进入本版本仍未确定。

需求：

- 支持在权限/配额管理中标注某项额度是否按月更新。
- 子账号额度设置支持按月设置或按周期设置，周期口径与套餐周期一致。
- 「当期使用」支持按月查看，而不是只有当前汇总和历史累计两个总量视角。
- 保留历史累计使用，不因月度重置丢失历史。

待确认：

- 必须拆开两个概念：`套餐权益/组织额度的发放与有效周期` 由商业套餐和服务端 Scope 规则决定；`组或 GroupMembership 的分配控制周期` 只限制下级在某一窗口内最多可用多少，不得反向改写组织套餐、预留或锁定父级额度。
- 企业版年付但组织额度按月发放：组织层直接使用服务端当月实际发放窗口和额度；组/成员若按月配置，应继承同一窗口，不能先生成一份年度总额再由前端模拟月度拆分。
- 非企业版额度按年发放但希望按月分给组/成员：建议保留组织年度总额，同时为可分配型 Scope 增加可选的下级月度控制窗口。执行时同时校验“组织年度剩余”和“当前月组/成员剩余”；月度上限不预占年度额度，未使用部分不自动转成额外年度额度。
- 默认建议为 `inherit parent period`；只有明确需要月度管理时才切换为 `monthly allocation window`。该能力只适用于 Scope 矩阵中允许分配且允许设置子周期的项目，不能统一套给门禁、频率、永久容量或跨周期去重能力。
- 仍需产品确认：月度窗口使用自然月、会员周期月还是合同锚点月；未用额度是否结转；中途提高/降低上限的生效方式；时区和重置时点；历史月查询范围。建议第一版不结转，降低到已用量以下时剩余按 `0` 处理且不回滚历史，但该建议尚未锁定。

#### B3. 批量增加组成员额度（P0）

现状事实：反馈行 25 属于「主子账号和权限」。配额页已有批量选择和设置固定额度能力，但反馈明确需要「每个子账号加 5000 发件额度」这类增量操作。

已确认落地口径：

- 该项是独立的增量需求：保留现有“共享所属层级额度 / 设置固定个人上限”的入口、默认模式、字段和接口语义，不改变已有流程。
- 在现有批量设置中新增单独的“在当前个人上限上增加”模式；本版本不做批量减少，需要下调时继续使用现有固定上限设置。
- Owner 可操作全组织；Admin 可操作管理范围内的组；T2 只有在“T2 能否管理本组账号权限”开启时才能操作当前组；T3 不可操作。
- 操作目标是 GroupMembership 而不是全局账号；支持对已选成员关系或当前管理范围内全部成员关系执行，同一 `uid` 在不同组可出现多行并分别调整。
- 只有可分配型 Scope 中对应项为 `capped` 的账号参与增加；`inherit` 账号保持共享额度模式，不自动转为个人上限，并在摘要中列为“使用共享额度，已跳过”。不可分配 Scope 不出现在批量增加候选中。
- 增加后的单条 GroupMembership 上限不得超过所属组上限。同组各成员上限之和仍允许超过组上限，不增加总和守恒校验。
- 【UI反馈】提交前展示操作预览：管理范围、目标账号数、实际调整数、跳过的 `inherit` 账号数、各配额项增加量和调整后示例。
- 【UI反馈】任一实际调整账号会突破父级上限时，提交前列出对应账号并阻止整批提交；不静默截断、不部分成功。
- 【UI反馈】操作成功后展示结果摘要：成功账号数、跳过账号数、各配额项增加量和新的上限区间；操作失败时整批不生效并展示失败原因。
- 记录操作人、目标账号、配额项、调整前后值和时间。

验收：

- Owner/Admin 可一次性给管理范围内所有 `capped` GroupMembership 各增加 5000 发件额度，现有固定上限设置流程不受影响。
- 混有 `inherit` 账号时，系统只调整 `capped` 账号，并在提交前预览和操作后结果摘要中明确说明跳过数量。
- 存在父级上限冲突时整批不提交；校验通过后所有实际调整账号的额度变化与结果摘要一致。

#### B4. 团队总额度与个人额度隔离（P0）

对应反馈：行 10、15，分别解决“弹窗显示团队剩余量”和“普通成员看到团队总额度”两个问题。

现状事实：

- 线上配额页当前向登录账号展示组织额度汇总卡片和多账号明细。
- 页面会为所有品牌账号请求组织当期/累计汇总和全成员列表，只用 `Boolean(adminStatus)` 控制编辑列；现有 `adminStatus=2` 的 T2 也会被视为管理员，查看范围和修改权限没有分开。

已确认落地口径：

- 【UI交互】新增组织策略 `成员可查看团队总体额度`，它只控制查看范围，不授予任何配额修改权限。
- 【UI反馈】开关开启时保持当前透明模式：组织成员可查看组织总体额度和成员明细，但不因此获得项目明细或额度修改权。
- 【UI反馈】开关关闭时按组织管理范围和当前组返回数据：
  - Owner 查看全组织汇总、全部组和全部成员关系。
  - Admin 查看其管理范围内的组汇总和成员关系。
  - T2 查看当前组汇总和当前组成员关系。
  - T3 仅查看自己在当前组的额度、消耗和剩余量。
- 开关由 Owner/Admin 修改。修改后立即生效并记录操作人、修改前后值和时间。
- 存量组织初始化为开启，保持当前展示行为；新组织初始化为关闭，采用最小范围默认值。
- 汇总和明细接口必须在服务端按策略和账号等级裁剪结果，不能只由前端隐藏卡片、表格或编辑按钮。
- T2 能否修改自己和本组 T3 的配额，仍只由 `T2 能否管理本组账号权限` 委派开关决定；额度查看开关不得绕过该规则。
- 【UI反馈】各业务场景的配额消耗提醒始终展示“当前账号在对象所属组此刻可用额度”，不受团队额度查看开关影响：
  - 可分配型 Scope 的 `capped` 取 GroupMembership、对象组、组织三层有效可用量的最小值。
  - 可分配型 Scope 的 `inherit` 跳过个人上限，取对象组和组织有效可用量的最小值。
  - 共享额度文案使用“当前可用共享额度”，不表述为已为当前账号保留的固定余额。
  - 额度为 `0` 时指出实际耗尽层级：账号个人上限、分组共享上限或组织共享上限。
  - 纯门禁、窗口和频率类 Scope 只返回当前是否可用及对应原因，不伪造个人剩余额度。

验收：

- 存量组织上线后展示内容不变；新组织的 T3 默认看不到组织总额度和其他成员明细。
- 关闭开关后，Owner、Admin、T2、T3 分别只能收到全组织、管理范围、当前组、个人当前组的汇总或明细数据。
- 开启开关不会使 T2/T3 获得配额编辑能力；关闭开关也不会取消已由委派开关授予 T2 的本组编辑能力。
- 配额不足或消耗确认弹窗展示当前账号的有效剩余量，并能解释由哪一层上限形成限制。

#### B5. 组织套餐无限额度展示（TODO）

需求：

- 仅对组织套餐父级返回的真正无限额度统一展示为「无限制」；账号 `inherit` 统一展示“不设个人上限 / 使用共享额度”，两者不得混用。
- 不在网页端展示误导性的数字上限。
- `-2/-3` 等特殊值只按后端约定映射，不在前端自行推导套餐。

验收：

- 基础数据、资源夹创建数量等无限制额度，在用户侧展示为「无限制」。

#### B6. 所有版本可查看自身剩余额度（TODO）

对应反馈：行 43。该项是套餐展示一致性，不是主子账号权限能力，不进入本版本。

需求：

- 所有支持基础数据额度的版本，都能查看当前账号自己的已用、剩余和周期。
- 是否展示团队总额继续遵循 B4 的角色/团队开关，不因开放个人剩余量而泄露团队额度。
- 套餐本身没有该额度时展示版本权益说明，不伪造剩余值。

### 5.3 数据权限与标签治理

#### C1. CRM 标签删除权限（P0）

现状问题：删除自定义标签后影响全部博主，管理员希望该动作可控。

需求：

- 【UI交互】CRM 标签删除以独立高风险动作权限纳入团队数据管理；CRM 普通写范围、记录 Assignee/Collaborator 和组长默认协作策略均不能自动授予标签删除。沿用现有数据管理页作为策略入口。
- CRM 标签继续是组织共享定义，但需保存 `creatorUid + createdGroupId` 来源快照，以便解释“自己的标签”和“当前组来源标签”。
- Owner 可删除；Admin 仅可删除其管理范围覆盖 `createdGroupId` 的标签；T2 仅在获得独立委派后可删除当前组来源标签；标签创建者是否可删除自己的标签沿用现有配置。T3 不因项目编辑权获得团队标签删除权。
- `createdGroupId=null` 或来源组已删除的标签只能由 Owner 或具备全组织标签治理权限的 Admin 删除。
- 【UI反馈】删除团队标签前提示影响范围，并要求二次确认。

验收：

- 未授权成员不能删除团队标签；同一账号切换组后不能用另一组 T2 身份删除当前组范围外的标签。
- 删除团队标签时能看到影响博主数量或风险说明。

#### C2. 消息中心自定义标签按创建来源筛选（P0）

现状问题：原始反馈明确指向消息中心全部团队标签混在一起，客户反馈标签太多、难找，并提出“私有/公开”或按账号显示。结合当前增量目标，本版本只解决标签查找效率，不引入标签私有化或新的共享权限模型。

现状事实：

- 当前标签新增、编辑接口只有标签名称和操作状态，没有返回前端可用于筛选的创建人信息。
- 消息中心标签选择器与网红备注/CRM 入口复用同一 `CreateLabels` 组件和 `/ws/remark/labels`、`/ws/remark/updateLabel` 接口；消息中心左侧标签列表另走 `/ws/messageCenter/labels`。
- 当前“收藏标签”只用于标记个人常用标签，不能按创建人或分组批量收窄列表。

已确认落地口径：

- 所有标签继续保持全团队可见；本项只改变列表筛选，不改变标签查看、编辑、删除或应用权限。
- 标签相关列表接口返回 `creatorUid`、`creatorName`、`createdGroupId`。`createdGroupId` 是创建时当前组快照，不按创建者此后的组关系动态推导。
- 【UI交互】标签筛选项为：
  - `我创建的`：`creatorUid` 等于当前账号。
  - `当前组成员创建的`：`createdGroupId` 等于全局当前组，包含自己在该组创建的标签。
  - `全部`：组织内全部标签。
- 【UI交互】首次默认选择 `全部`，保持当前行为；之后按账号记忆上次选择。
- 【UI交互】所有账号只要当前组为 `ACTIVE` 就展示中间筛选项；不存在隐藏分组例外。
- 已应用在博主或会话上的标签仍按当前方式展示，不受标签列表筛选状态影响。

为避免成员转组或离组导致历史标签随账号漂移，确认补充以下规则：

- `当前组成员创建的` 按 `createdGroupId` 判断，不按创建者当前属于哪些组动态计算。
- 创建者转组、离组或离开组织后，历史标签仍归属于原创建分组；创建者仍可通过 `我创建的` 或 `全部` 找到这些标签。
- 创建者进入新分组后，新建标签记录新的 `createdGroupId`，不批量搬迁旧标签。
- 来源组被删除后，其历史标签仍保留在 `全部` 和创建者的 `我创建的` 中，不自动归入其他组。
- 存量标签统一回填默认组 `createdGroupId`；无法识别创建人的仍可进入默认组的中间筛选，`creatorUid` 保持空值。若未来允许无当前组的组织管理入口创建标签，则记录 `createdGroupId=null`，只进入 `全部` 和可识别创建者的 `我创建的`。

验收：

- 切换三个筛选项时，只改变可选标签列表，不改变任何标签权限或既有标签关系。
- 成员离组后，其历史标签不会从原来源组的 `当前组成员创建的` 结果中消失；加入新组也不会把旧标签带入新组。
- 多组账号切换当前组时，中间筛选结果只随 `currentGroupId` 变化，不受组织 Owner/Admin 身份影响。

#### C3. CRM 记录统一协作与线上权限兼容迁移（P0）

现状事实：

- 线上 `团队和权限 > 数据管理` 已有四项 CRM 记录写权限配置：`对接人和管理员可编辑`、`对接人和同组组长可编辑`、`对接人和同组成员可编辑`、`所有人可编辑`。
- 研发确认：`ownerUser` 非空时 Owner 始终可写，四项配置分别增加团队实际管理员、Owner 同组组长、Owner 同组成员和当前主账号体系全体成员的普通写权限；多项同时勾选取并集。`ownerUser` 为空时存在仅管理员可写的兼容分支，不能套用同一真值表。
- 现有配置控制对接人、合作状态、网红名称、网红链接和归档等写动作；CRM 批量标签操作逐条复用该权限并跳过无权记录，但直接标签应用和标签定义删除没有 CRM 写鉴权。四项配置不是 CRM 记录的读权限或协作者配置。
- 研发确认 `/ws/crm/getList`、`getChannelDetail`、`getCRMRecord` 只按 `parentUid` 做租户隔离，没有登录人、Owner、角色或组级记录裁剪；当前同一主账号体系内所有成员均可读取全部 CRM 记录。
- CRM 记录已有 `ownerUser` 对接人；CRM 自定义视图已有的 `viewAuthors` 只控制视图分享，不是 CRM 记录协作者。

已确认落地口径：

- 【UI反馈】CRM 记录作为「组属业务记录」接入统一权限计算，稳定保存 `groupId`、可空的 `assigneeUid`、显式 Collaborator，并为原始“协作人只读”诉求提供独立的显式查看授权；线上 `ownerUser` 迁移为 `assigneeUid`，空值保留为合法的「未分配」状态，不补造项目 Owner。`groupId` 决定记录归属和同组范围，不能由对接人当前所在组动态推导；对接人变更不改变记录组。
- `assigneeUid` 只表达 CRM 对接责任和现有对接人写权限来源，不等同于项目型对象的 `ownerUid`，不进入项目 Owner 转交、迁组或强制移交规则。但 Assignee 是 CRM 记录天然的协作治理人，可以添加/移除显式 Collaborator 和显式查看对象，并向任一有效 Collaborator 授予或收回不可传递的 `can_manage_collaborators`。非空 Assignee、显式 Collaborator 和显式查看对象都必须是记录组内 `ACTIVE` 成员；Collaborator 获得当前记录的常规业务读写，显式查看对象只有读权限。
- 【UI交互】【UI反馈】CRM 日常 Assignee 分配/改派只允许两类主体：非空记录的当前 Assignee 和记录组内任一 `ACTIVE T2` 都可以为已有记录指定一个新的 Assignee；未分配记录因为不存在当前 Assignee，只能由同组 `ACTIVE T2` 分配。两类主体使用同一改派动作，目标必须是记录组内另一名 `ACTIVE` 成员，不要求新 Assignee 接受；日常动作不允许把非空 Assignee 清空为 `null`。普通 Collaborator 即使拥有普通写权限或 `can_manage_collaborators` 也不能设置、清空或改派 Assignee；组织 Owner/Admin 也不能仅凭组织身份或管理范围直接执行该业务动作。改派后原 Assignee 立即失去天然写权限和协作治理权，只有其另有显式 Collaborator、查看范围或其他策略来源时才继续访问；记录 `groupId` 不变。
- 【UI交互】`assigneeUid=null` 时，记录保持有效，但新增/移除 Collaborator、显式查看对象和授予/收回 `can_manage_collaborators` 的入口锁定，并优先提示“请先分配对接人”。只有同组 `ACTIVE T2` 可以将其重新分配给具体 Assignee。已有对象授权继续按自身来源提供读写或查看，但已有 `can_manage_collaborators` 在未分配期间暂停用于治理，分配新 Assignee 后再按当前有效授权恢复。
- T2 的 Assignee 分配/改派权是固定组内分工动作，不依赖“组长默认成为组内所有项目协作者”开关。开关开启时，T2 另有系统 Collaborator 普通写来源；开关关闭时，T2 仍可在分工清单查看记录标识、网红名称、所属组和 Assignee 状态等必要信息并完成分配，但不因此获得完整记录明细、普通写权限或 `can_manage_collaborators`。该动作必须留审计。若未分配记录所在组没有 `ACTIVE T2`，Owner/Admin 只能先通过组管理任命至少一名 T2，再由 T2 分配 Assignee；不能直接越级操作 CRM。
- CRM 同样接入组织级“组长默认成为组内所有项目协作者”策略，不存在组织 Owner/Admin 的通用隐式业务权限。开关关闭时不产生 CRM 的 T2 系统协作者来源；Admin 若通过线上 CRM 策略获得编辑权，也必须同时是记录组内 `ACTIVE` 成员并通过对应业务资格校验。
- 【UI交互】线上四项配置迁入同一个权限合并器，不再保留平行鉴权分支：
  - `对接人和管理员可编辑`：非空 Assignee + 记录组内 `ACTIVE` 的组织 Admin 获得普通写范围；这是 CRM 显式模块策略，不是 Admin 的通用业务权限，也不把范围命中者写成协作者。
  - `对接人和同组组长可编辑`：非空 Assignee + 记录组内全部 `ACTIVE T2` 获得普通写范围；组长默认协作开关同时开启时，T2 还会命中系统协作者来源，两个来源必须分别保留。
  - `对接人和同组成员可编辑`：非空 Assignee + 记录组内满足 CRM 业务资格的 `ACTIVE` 成员获得普通写范围。
  - `所有人可编辑`：目标稳态拟在严格组隔离下收敛为非空 Assignee + 记录组内满足 CRM 业务资格的 `ACTIVE` 成员，不产生跨组写权限；这比当前“主账号体系全体成员”更窄，属于待确认的权限收紧，不能称为等价映射。`assigneeUid` 为空不影响按记录 `groupId` 计算该组范围。
- 研发已给出四项配置组合真值，但当前权限 `1` 的团队实际管理员不要求属于记录组，旧“同组”权限 `2/3` 又依赖现有 `kol_user_group_relation`。目标映射要求 Admin 属于记录组会缩小权限 `1`；把存量多个 CRM 组全部压入默认组会扩大权限 `2/3`；把“所有人”收敛为记录组会缩小权限 `4`。因此“默认组天然等价”不成立。进入 spec 前必须在“保留旧 CRM 组映射、增加可迁移的旧范围授权来源、明确接受权限变化”中确认一种迁移方案；组织后续主动拆组后，所有范围按记录稳定 `groupId` 收敛仍是目标方向。
- 组长默认协作开关是四项旧策略之外的可选授权来源。默认关闭时不新增 T2 系统来源；四项配置值和既有有效授权按最终选定的迁移方案承接，不能在方案未定时宣称无损。组织显式开启后，即使未勾选“对接人和同组组长可编辑”，同组 `ACTIVE T2` 也会作为 Collaborator 获得记录常规业务读写。该变化属于管理员主动启用后的权限扩展，开启前必须展示 CRM 等受影响模块和对象范围。
- Assignee、显式协作者、显式查看授权、开关开启时的 T2 系统协作和四项迁移策略进入同一权限合并器；每个授权来源独立保留，正向能力取并集，非 `ACTIVE` GroupMembership、套餐无权益和对应配额不足等硬限制优先。配额不足只阻断消耗型 CRM 动作，不直接撤销已有记录读取或对象授权。
- CRM 标签删除继续按 C1 独立判断；直接标签应用当前全组织可调用，是否改为要求记录普通写/对象 ACL 进入本轮新增决策。CRM 自定义视图继续使用现有创建人和 `viewAuthors`，不并入本轮记录 ACL。

验收：

- 只有在 CRM 旧分组迁移方案确定后，才能验收四项配置在存量选择组合下的普通字段写权限结果。迁移完成后不再运行无法解释的平行旧鉴权分支；组长默认协作开关默认关闭，因此上线迁移本身不新增 T2 系统来源。
- 组织 Owner/Admin 不能仅凭组织身份打开 CRM 记录、设置或改派 Assignee；只有同组有效授权来源才能访问明细。无 T2 导致未分配记录无人处理时，Owner/Admin 只能先完成组长任命。CRM Assignee 是普通业务责任与协作治理来源，不是组织 Owner。
- 显式查看对象能查看被明确授权的 CRM 记录但不能修改，且不出现在协作者列表；Collaborator 能执行当前 CRM 常规读写动作，但不能因此删除标签或获得对象治理权限。只有 Assignee，或 Assignee 显式授予 `can_manage_collaborators` 的 Collaborator，可以治理记录协作；未分配状态必须先设置 Assignee。
- 存量账号在迁移完成前继续遵循当前全组织读范围；迁移完成后的记录读取必须以最终确认的 CRM 迁移来源、记录组范围和对象授权计算，管理范围汇总不得意外开放记录明细。
- CRM 自定义视图的创建、分享、编辑和删除权限不受本轮记录协作改造影响。
- 研发已关闭当前 CRM 读范围与四项写权限组合真值。进入 spec 前仍需扫描空 `ownerUser` 的数量与分布以评估「未分配」界面和查询影响，但空值不再触发 Owner 兜底或迁移阻断；同时确认旧 CRM 分组迁移方式和直接标签应用目标权限，再补齐统一权限判定。Assignee 离组规则已确认：按记录所属组可选一个同组 `ACTIVE` 接收人批量改派，未选择则在最终完成退组时置为未分配。CRM 协作与分工主体也已确认：非空 Assignee 天然治理协作；已有 Assignee 时，当前 Assignee 与同组 `ACTIVE T2` 都能指定新的同组 Assignee；未分配时仅同组 `ACTIVE T2` 可以分配；日常改派不能主动清空。

### 5.4 项目和资源协作

#### D1. 组长默认协作策略与对象级授权（邮件/资源夹/内容监控/CRM/跨境支付 P0）

现状事实：邮件项目已有 `email[12]`，通过枚举组织管理员并写入锁定协作者实现默认协作。新根模型取消组织 Admin 的隐式业务权限，并提供组织级“组长默认成为组内所有项目协作者”开关，由客户决定是否让项目所属组的 T2 自动参与组内项目。

已确认口径：

- 邮件项目、资源夹/收藏夹、内容监控项目和支付单/草稿作为项目型对象，必须保存稳定 `groupId`、唯一 `ownerUid` 和对象授权，身份只有 Owner 与 Collaborator 两级。CRM 记录作为组属业务记录，必须保存稳定 `groupId` 和对象授权，但只保存可空 `assigneeUid`，不强制建立项目 Owner；各类对象均不设置通用 Viewer/Editor。消息会话与旧任务列表不在本版本接入。
- Collaborator 默认获得当前模块定义的常规业务读写；不新增通用 `can_edit`。删除、归档、Owner 转交、对象归组、协作者管理和支付执行等高风险动作按对象类型固定判断，不能从“协作者可写”直接推导。
- 只读需求不创建协作者：按业务需要使用组/策略产生的查看范围，或绑定具体对象的显式查看授权。查看范围命中者和显式查看对象不进入协作者列表，也不获得任何写权限。
- 项目型对象 Owner 必须是对象组内 `ACTIVE` 成员；CRM Assignee 非空时也必须是记录组内 `ACTIVE` 成员。显式 Collaborator 和显式查看对象只有在对象组内保持 `ACTIVE` GroupMembership 时生效。本期不允许跨组选择协作者、跨组查看授权或跨组转交项目 Owner；对应消耗型动作另行校验业务配额。
- 【UI交互】【UI反馈】新增组织级全局开关“组长默认成为组内所有项目协作者”，默认关闭，统一作用于本期已接入对象。开启后，对象所属组的全部 `ACTIVE T2` 通过系统授权来源成为该对象普通 Collaborator，替代旧 T1/Admin 强制协作；关闭后不产生或立即撤销该系统来源。开关不按组或模块分别配置。
- 新组织和存量组织均默认关闭；存量显式协作者、锁定协作者和附加能力按迁移真值保留，不因默认值被删除。组织 Owner 可修改；Admin 是否可修改由 Admin 动作矩阵中的独立组织策略管理动作决定，未授予时只读；T2/T3 不可修改。
- 【UI交互】【UI反馈】开关对已有对象立即生效。开启前展示将新增 T2 系统协作者的组、模块、账号和对象数量；关闭前展示将失去该系统来源的范围，并说明同一账号的显式 Collaborator、显式查看授权和附加能力仍保留。两种变更均需二次确认、审计日志和操作结果摘要。
- T2 系统协作来源不批量写入对象 ACL，在协作者列表中以锁定项展示并说明来源，不能被项目 Owner 或 CRM 记录治理人手动删除。T2 获得常规业务读写，但不自动获得 `can_manage_collaborators`、`can_execute_payment` 等附加能力或模块高风险治理动作。
- T2 系统协作只在开关开启且 T2 本人的 GroupMembership 为 `ACTIVE` 时生效；不能绕过组织 Entitlement、账号状态或对应业务规则。可分配型 Scope 的有效可用量为 `0` 不撤销对象协作来源，但不能完成相应消耗型动作。T2 离组或降为 T3 时该系统来源即时失效，但其独立显式授权仍可保留。
- 同一账号同时命中项目 Owner 或 CRM Assignee、T2 系统来源、显式协作者、查看范围或附加能力时，各授权来源必须分别保留并返回；最终正向能力取并集，不能只返回一个无法解释的角色或布尔值。移除显式来源不能误删 T2 系统来源，反之亦然。
- 【UI交互】项目型对象 Owner 与非空 CRM Assignee 天然可以添加、移除显式协作者与显式查看对象，并向任一有效 Collaborator 授予或收回不可传递的 `can_manage_collaborators`；该授予形成独立显式能力来源，不覆盖 T2 系统来源。获得该能力的非 Owner/Assignee Collaborator 可以添加、移除普通 Collaborator 或显式查看对象，但不能向自己或他人继续授予该能力；只读查看对象不能获得。CRM 未分配时暂停所有协作者治理，必须先由同组 `ACTIVE T2` 设置 Assignee；普通 Collaborator 和组织 Owner/Admin 均不能反向影响 Assignee。候选选择器只能检索对象所属组的 `ACTIVE` 成员。
- 组织 Owner/Admin 如果未命中对象组内有效项目 Owner、CRM Assignee、显式协作者、查看范围或显式查看授权，且未在组长默认协作开关开启时作为同组 T2 命中系统来源，只能看到管理范围汇总，不能打开对象明细或管理协作者。
- 邮件 `email[12]` 不再为新项目写入组织管理员；存量锁定管理员关系按迁移真值转为有效显式 Collaborator，以保持已有项目权限。不能依据旧 `email[12]` 自动开启全组织的组长默认协作开关，因为这会把单模块设置扩大为全模块权限。
- 存量模块中已有协作者统一迁为 Collaborator，并保持升级前可执行的常规业务动作；`canManageMembers` 等既有附加字段映射为对应附加能力。上线不要求用户重新选择协作等级，也不通过迁移静默收窄或扩大其当前有效权限。
- 资源夹/收藏夹现有 `私有 / 公开 / 部分可见` 首先按查看范围迁移：公开不把全体成员批量写成 Collaborator，部分可见也不能仅因 `membersUid` 字段名直接推导协作者读写；`myself` 等 Owner-like 语义和共享成员的实际动作由后端真值表确认后，分别映射为 Owner、Collaborator 或显式查看授权。

验收：

- 任何组织 Admin 都不能仅凭组织身份访问对象明细；项目 Owner、CRM Assignee、有效显式协作者、查看范围和显式查看授权始终按统一权限合并器生效，同组 T2 仅在组长默认协作开关开启时增加系统 Collaborator 来源。T2 的 CRM Assignee 分配/改派是独立的固定组内分工动作，不产生对象读取或普通写来源；Owner/Admin 不具备该业务动作。
- 开关开启时，新增/降级 T2 不需要逐项目写 ACL 即可即时生效或失效；关闭开关时全部 T2 系统来源即时失效。协作者列表能解释并锁定该系统来源。
- 所有显式协作者和显式查看对象候选均限制在对象组内，搜索不能扩大范围；多来源正向能力取并集，硬限制优先。
- 邮件、资源夹/收藏夹、内容监控、CRM 和跨境支付共用组边界、授权来源合并和硬限制规则；唯一 Owner 只适用于项目型对象，CRM 使用可空 Assignee。各模块动作差异留到 spec 权限矩阵定义。

#### D1.1 内容监控/视频监控标签管理限制（P1）

2026-07-22 新增原始诉求：

> Owner/Admin 可以设置“是否限制 T3 增减编辑标签”，默认关闭；无论是否打开，Owner/Admin 和任一有效 T2 都有对共享标签定义的管理权限，只限制 T3。

原始需求的明确适用范围是内容监控/视频监控模块；CRM、消息中心和网红备注标签不是本条原始需求范围。

跨模块复用候选：后续讨论各模块完整动作权限矩阵时，需要重新抛出“其他具有共享标签体系的模块是否也需要同类 T3 限制”。该候选只作为参考，不自动扩大当前需求范围，也不覆盖 C1 的 CRM 标签删除权限或 C2 的消息标签来源筛选结论；若决定扩展，必须按模块分别确认标签动作、现状和优先级。

当前已明确：

- 需要为内容监控/视频监控提供一个由 Owner/Admin 管理的组织级标签权限策略，默认关闭。
- 策略只限制 T3；Owner/Admin 与任一组的 `ACTIVE T2` 始终保留目标标签定义动作权限。
- 开启后，该组 T3 不能执行被纳入策略的标签动作；关闭后保持当前 T3 行为，不额外扩大其现有权限。
- 现有标签控件实际混合了两类动作：标签定义通过 `updateLabelList` 以 `status=1/2/3` 创建、删除、改名；标签应用通过 `saveVideoLabels`、`saveVideoDetailLabels` 等接口给具体监控内容添加或移除已有标签。本需求必须拆开鉴权，不能继续以同一个控件是否可见代替动作权限。
- 现有标签定义查询与更新只传标签类别 `tagType/groupId=1/2/3`，没有账号正式分组 ID；本版本继续将其视为组织共享标签库，不拆分分组标签库或标签归属。
- 本开关只限制共享标签定义的创建、改名和删除。开启后，仅账号状态正常且套餐包含内容监控的 Owner/Admin、任一 `ACTIVE T2` 可以管理标签定义，T3 不可执行；关闭后维持 T3 当前行为。
- 给具体监控项目或内容应用、替换、移除已有标签不受本开关限制，继续跟随该对象的有效业务权限：Owner、有效 Collaborator 或命中模块普通写范围的账号可以操作；仅命中查看范围的账号不可以。
- 【UI反馈】标签定义管理权限不反向授予任何监控对象的读写权限；T2 能管理标签定义，也不能因此访问其他分组或未授权监控对象。
- 【UI交互】前端对无权账号隐藏或禁用标签定义的新建、改名、删除入口，但继续保留已有标签的选择和应用能力；后端必须分别校验定义管理接口和对象标签保存接口，不能只依赖前端控制。
- 【UI交互】策略采用内容监控模块的组织级全局开关，默认关闭，所有正式分组共用同一个值，不支持逐组差异化配置。共享标签库不能出现“A 组允许 T3 修改、B 组禁止”但修改结果仍影响全组织的虚假隔离。
- 【UI交互】【UI反馈】Owner/Admin 均可修改该全局开关，T2/T3 不可修改。修改立即影响后续标签定义动作，但不删除、转移或改写已有标签及标签关系，并记录修改人、组织身份、前后值和时间。
- 全局开关关闭时，具备内容监控业务资格的 T3 继续保持当前标签定义管理行为；开启时所有 T3 均不能创建、改名或删除标签定义。某组无 T2 不会向 T3 回退权限。
- 标签定义是组织共享数据，因此账号只要在任一组具有有效 T2 身份且套餐包含内容监控，就可以管理该共享标签库；该管理能力不授予其任何其他组的监控项目明细权限。此跨组影响必须在操作提示和审计中明确。

行为口径与 P1 优先级已确认完成；本版本进入内容监控/视频监控动作权限矩阵和 P1 验收候选。CRM、消息中心等其他共享标签模块是否参考复用仍按跨模块候选单独讨论，不因本条确认自动扩围。

本条的动作边界、配置粒度、修改人与无 T2 行为均已确认；开关变化只影响后续动作权限，不删除、转移或改写已有标签及标签关系。

#### D2. 跨境支付金额配额、支付单协作与资金限制（P0）

现状事实：

- 研发确认正式支付单 `flagForMe` 缺省/`false` 返回当前主账号体系全部记录，`true` 只返回当前账号创建的记录；但列表 `editFlag` 只表示是否为创建人，服务端更新、取消、改预约、转立即和手动发起等接口实际只校验同一 `parentUid` 与订单状态，当前同组织成员可能操作非本人订单。
- 草稿没有有效的 `flagForMe` 范围，列表、详情、更新和删除均只允许草稿 `uid` 对应的创建人；因此草稿与正式支付单当前不是同一套读写范围。
- 正式单已有 `creatorUid + parentUid`，草稿已有 `uid`；历史字段缺失时，现有支付日志无法稳定回填创建人。预约和立即支付均在创建正式支付单时把预估金额从组织钱包 `balance` 转入 `pending`，取消、审核拒绝和三方建单失败会释放。
- 历史收款账号已确认按 `parent_uid + channel_id + platform` 隔离，支持组织内同频道复用。退款/召回虽有修复逻辑，但外部通知控制器被注释，不能据静态代码确认完整退款回补闭环。

已确认生效口径：

- `跨境支付` 不设置独立的 GroupMembership 模块启用/禁用字段；支付金额使用独立的 `payment_amount` 组级追加分配、账号人工上限和组织钱包余额约束，不并入普通 Scope 的统一数值契约。组或账号实际可用支付金额为 `0`、或组织钱包无可用余额时，不能完成需要形成/执行资金承诺的业务动作，但不因此撤销已经有效的对象读取或对象授权。
- 支付单与草稿是同一根对象生命周期，创建时保存稳定 `orderId + groupId + createdBy + ownerUid`；草稿转正式单沿用 Owner、Collaborator 和附加能力，不重新授权。支付单只有显式迁移才能改变 `groupId`，Owner 改组不触发隐式变更。
- 正式支付单固定对其 `groupId` 内全部 `ACTIVE` 成员提供只读查看范围，与是否存在 Collaborator 无关；该范围不写入对象 ACL、不显示为协作者，也不产生任何写权限。草稿不进入同组查看范围，只有 Owner 和有效 Collaborator 可见。
- 【UI交互】正式单同组只读是系统固定规则，不设置“同组成员可查看支付单”父开关。组织级策略只保留 `同组成员可查看支付敏感信息`，默认关闭；关闭时同组只读范围看到脱敏收款信息且不能下载支付回执，开启后可查看完整收款信息和回执，但仍无任何写权限。Owner 和有效 Collaborator 为完成工作可读取完整支付信息。
- 【UI反馈】支付单接入 D1 的组长默认协作策略；组织 Owner/Admin 不因组织身份获得支付单明细、敏感信息、协作者管理或资金执行权限。开关开启时，T2 作为普通 Collaborator 获得支付对象常规业务读写，但永不自动获得 `can_execute_payment`。协作者列表需区分系统锁定来源与显式授权来源。
- 显式 Collaborator 必须是支付单组内 `ACTIVE` 成员。Collaborator 可以查看草稿和正式单，并在支付状态允许时填写、修改支付信息；没有 `can_execute_payment` 时只能保存草稿，不能把草稿提交为正式支付单。仅命中正式单同组查看范围的账号永远不能编辑、管理协作者或执行支付。
- 【UI交互】支付资金执行独立使用 `can_execute_payment`。当前对象 Owner 天然拥有；Owner 可以为 Collaborator 显式授予或收回，非 Owner Collaborator 不能继续转授，组织 Owner/Admin 和 T2 系统来源均不产生该能力。是否允许管理范围 Admin 作为应急治理动作授予/收回，留在 Admin 动作矩阵中确认，未确认前按不允许处理。
- `can_execute_payment` 覆盖立即/预约提交为正式支付单、支付者手动放行、修改预约时间、转立即支付、取消或作废；会形成、变更或执行资金承诺的动作还必须通过 `payment_amount` 配额、组织钱包可用余额、账号/组关系、订单状态和统一资金校验。系统到期执行记录 `actorType=system`。
- 当前服务端“同组织成员均可写正式单”属于宽于 UI 和目标模型的鉴权缺口，不迁为 Collaborator 或隐式授权。目标上线后，非 Owner、非有效 Collaborator 或缺少 `can_execute_payment` 的账号必须由服务端拒绝对应写/执行动作，并单列安全回归。
- 【UI交互】草稿可由对象 Owner 或有效 Collaborator 删除；正式支付单不硬删除。该规则是支付对象的固定动作边界，不由通用“可写”字段推导。删除草稿必须二次确认；`can_execute_payment` 与 `can_manage_collaborators` 相互独立，任一都不能推导另一项。
- 【UI反馈】预约提交成功时即形成资金承诺，不论后续审批或放行人是谁。提交、手动放行等资金动作入口必须展示当前有效的执行权限和支付金额校验结果；`fundingUid` 固定为提交时 `ownerUid` 快照，并同时记录 `fundingGroupId=groupId`，作为当前账号/组额度占用和后续冲正的稳定归属；执行人只记录 `actorUid`。取消、失败释放和退款回补都回到原资金记录，Owner 或项目后续迁移不改写历史承担方。
- 本期 `payment_amount` 完整接入组织、组和账号三级资金校验：组织层取钱包当前可用余额；组默认使用组织未分配共享余额，也可通过逐笔追加分配形成部门上限；账号默认不追加个人上限，也可配置具体金额。组级追加不得超过组织未分配余额，普通操作只能增加；减少只能通过引用原分配记录的受控冲正/收回交易完成。`paymentFundMode=shared` 只表示实际资金来源仍为组织钱包，不代表无限支付，也不取消组级资金承诺账本。预约提交立即产生 `pending` 占用，取消、失败释放和退款回补回到原 `fundingGroupId + fundingUid`；分配和冲正记录的页面化对账、筛选与导出在 spec 细化。
- 【UI交互】频道历史收款账号在全组织共享。组织内具备支付单新建/编辑业务资格的账号，可按当前网红频道检索并复用历史收款人；不得借此浏览全量目录、来源支付单或其他频道。记录创建人退组/离开组织不影响复用；新增版本、覆盖、停用和删除治理留作 TODO。
- 【UI交互】【UI反馈】支付 Owner 不能主动转交。其退出支付单所属组时，支付单留在原组并进入统一数据移交任务，由一个同组 `ACTIVE` 接收人承接；原 Owner 不保留历史 Owner 权限。项目迁组流程可以在 Owner 同时加入目标组时保持 Owner 不变，但不能绕过 ACL 禁用/恢复与资金历史不改写规则。移交任务需要可查看待处理项、接收人、进度、失败原因和完成摘要。

验收护栏：

- 所有支付对象权限按对象稳定 `groupId` 计算，切换当前组或 Owner 改组不会改变对象范围。
- 草稿仅 Owner 和有效 Collaborator 可见；正式支付单对同组 `ACTIVE` 成员固定只读，跨组成员不能因组织身份或 Admin 管理范围打开明细。组长默认协作开关开启时，同组 T2 另以系统 Collaborator 来源获得常规业务读写，但仍无支付执行权。
- `同组成员可查看支付敏感信息` 关闭时，同组只读范围看到脱敏信息且不能下载回执；开启后可读完整信息和回执，但仍无写权限。
- 没有 `can_execute_payment` 的 Collaborator 可以保存草稿但不能创建正式支付单；服务端必须拒绝其直接调用提交、手动放行、改预约、转立即、取消或作废接口。
- Owner 或获得 `can_execute_payment` 的 Collaborator 执行支付时，占用仍记在提交时 Owner 的 `fundingUid + fundingGroupId`；审批、放行和系统执行均不能改写。
- 草稿转正式单不丢 Owner、Collaborator 或附加能力；退组移交、项目迁组、对象授权禁用恢复和组织移出均复用统一状态机，不由支付模块单独实现。
- 存量正式单和草稿必须分别统计 `creatorUid/uid` 缺失量并制定 Owner 兜底；无法稳定回填的对象不得静默指定 Owner。组级追加分配、账号上限、资金归属和受控冲正均为净新增能力，需新增支付账本的原子性、幂等及退款回补验收。
- 存量迁移时，正式支付单和全部组织成员进入同一默认组，因此原全组织读取范围保持不变；存量草稿以 `uid` 初始化 Owner 且不生成 Collaborator，继续只有创建人可见。正式单以 `creatorUid` 初始化 Owner 且不生成 Collaborator；当前服务端“同组织任意成员可写”按鉴权缺口收紧，不迁成历史授权。

<details>
<summary>历史废案：基于 T1 隐式权限与 Owner 当前分组的支付规则（不生效）</summary>

> 以下内容保留讨论轨迹。其中 T1 隐式业务权限、按 Owner 当前分组生成 Viewer、隐藏分组例外、T1 天然执行支付和“数据跟随本人”均已被上方生效口径替代；不得用于生成 spec、研发任务或验收用例。

现状事实：

- 当前支付中心展示组织钱包的 USD 总余额、已支付和支付中金额；前端没有账号级支付模块开关、账号支付额度或资金占用台账。
- 支付单与草稿已有稳定 `orderId` 和“我创建的”筛选；草稿保存、正式提交、手动触发、预约调整、转立即支付、取消/作废分别调用不同接口，当前只由后端 `editFlag` 等零散结果控制部分按钮。
- 新建支付单弹窗已有按 `channelId + platform` 查询历史收款人记录的接口和选择能力，但当前后端返回范围、归属和历史记录管理权限尚未形成组织级产品口径。

已确认落地口径：

- `跨境支付` 加入账号顶级模块准入和正式分组模块上限；每个账号明确配置 `启用 / 禁用`。账号未启用时，列表、草稿、详情、创建和支付单协作授权均不能绕过该硬限制。
- 支付单和草稿作为同一业务对象生命周期接入 Owner / Editor / Viewer；创建草稿时生成对象 Owner 和 ACL，草稿提交为正式支付单后沿用同一 `orderId`、Owner 和协作者，不重新授权。
- 跨境支付接入 D1 的 T1 隐式最高协作策略；具体 T1 仍可被显式选为 Viewer/Editor，多重授权取最高。
- 新增跨境支付组织策略 `同组成员默认可查看支付单`，只在 T1 管理侧统一配置，不下放给 T2，也不支持逐组差异化设置；修改权沿用组织策略规则，由组织所有者修改，其他 T1 只读。
- 开关开启后，支付单 Owner 所在正式分组内、已启用跨境支付模块的成员动态获得当前支付单 Viewer；该范围授权不向每张支付单 ACL 批量写入组员，也不展示为显式协作者。
- 在 `同组成员默认可查看支付单` 下级联增加组织策略 `同组 Viewer 可查看敏感信息`。只有父开关开启时才展示并允许修改；关闭父开关时同步关闭子开关，重新开启父开关后子开关仍保持关闭，必须再次明确开启。
- 父开关开启、子开关关闭时，同组动态 Viewer 只能查看支付金额、币种、网红频道、关联任务、Owner、支付状态、预约时间和流程记录；完整收款账户信息脱敏，不允许下载支付回执。
- 父子开关同时开启时，同组动态 Viewer 额外获得 `can_view_sensitive_payment_info`，可以查看完整收款账户信息和下载支付回执，但仍不能编辑、执行支付、管理协作者或查看组织钱包及全组织支付汇总。
- 显式 Viewer 是 Owner/T1 对具体支付单的明确授权，默认获得 `can_view_sensitive_payment_info`，不受同组敏感信息子开关影响；Owner、Editor 和命中隐式策略的 T1 同样天然拥有该敏感读取能力。
- 两个开关均由组织所有者在 T1 管理侧配置，其他 T1 只读、T2 不可修改；新组织父子开关均默认关闭。修改需记录操作人、修改前后值、预计影响对象范围和时间。
- 同组 Viewer 范围随 Owner 当前正式分组动态计算：Owner 转组或转交后立即按新 Owner 的分组重算。Owner 为 T1 或隐藏分组成员时不产生同组 Viewer；隐藏分组成员之间不因同属隐藏分组而互相可见。
- 同组 Viewer 只增加支付单/草稿对象读取权限，不授予组织钱包余额、全组织支付汇总或其他分组支付单的查看权限；普通成员不能通过显式 Viewer/Editor 查看其他主分组的支付单，T2 命中本组 Editor 等更高权限时继续按最高权限生效。
- 新组织默认关闭该策略。存量组织不得直接套用关闭值；进入 spec 前先由后端确认当前支付单“全部 / 我创建的”真实可见范围，再制定不静默收窄既有有效访问的初始化规则。
- 频道历史收款账号属于组织共享主数据，不归属于创建该记录的个人或某张支付单。组织内已启用跨境支付且有权新建/编辑支付单的账号，可在付款表单中按网红频道账号快速选择全组织历史收款人记录。
- 历史收款账号的组织共享只开放“按当前频道检索和复用”：不得因此查看创建该记录的来源支付单、来源 Owner、其他频道记录或全量收款人目录；不同组织之间严格隔离。
- 创建人转组、离组或离开组织后，已产生的频道历史收款账号仍作为组织数据保留并可复用。选择历史记录只填充当前支付单收款信息，不转移来源支付单权限，也不建立两张支付单之间的 ACL 关系。
- 本条只确认组织范围内的检索与复用；谁可以新增版本、覆盖、删除或停用历史收款账号属于敏感主数据治理，整体转入 TODO，不进入本期 spec 和验收，也不阻塞支付协作主线。后续启动时不能直接沿用支付单 Viewer/Editor 权限推导。
- 本期不开放账号支付额度配置。账号权限表单在跨境支付模块下只读展示资金模式：`不设账号个人上限，使用组织共享余额`，内部值固定为 `paymentFundMode=shared`，所有存量和新增账号均不可修改。
- `shared` 只表示账号层没有个人金额上限，不代表无限支付；组织钱包实际余额、合同/协议状态、账号状态、订单状态和其他支付业务门禁继续优先拦截。
- 支付资金限制使用独立领域模型，不复用数据配额的 `inherit / capped`、周期或批量加额度字段；后续单独立项增加账号支付额度限制、资金占用、释放、退款回补和对账。
- 本期为后续限制保留统一服务端资金校验入口；在账号层固定返回放行，但所有会触发或安排实际支付的接口仍必须经过该入口并继续执行组织钱包校验。
- 支付身份和责任分为四类：支付对象保存不可变的 `created_by` 和当前 `owner_uid`；每条操作事件分别保存 `actorType + actorUid`；每条资金承诺或支付尝试保存独立的 `fundingUid`。`actorUid` 和 `fundingUid` 不作为支付单主记录上的“最后操作人”反复覆盖。
- `fundingUid` 固定取资金承诺形成时的 `owner_uid` 快照，表示组织钱包占用及未来账号个人支付额度占用归属；提交人、审批放行人、手动触发人即使不同，也只分别记录为事件 `actorUid`，不承担该笔额度。
- 预约提交成功时即形成资金承诺：组织钱包进入待支付占用，未来启用账号个人支付额度后同步计入 `account_pending[fundingUid]`。本期 `paymentFundMode=shared` 下账号个人额度校验固定放行，不新增 `account_pending` 页面或可编辑限额，但资金归属口径不得另行变化。
- 支付资金执行独立使用对象级 `can_execute_payment`。当前有效执行能力统一计算为：当前 Owner，或命中跨境支付 T1 隐式最高协作策略的 T1，或当前对象上被授予 `can_execute_payment=1` 的显式 Editor；Owner/T1 无需保存显式授权值，T2 范围 Editor 和普通 Editor 不天然拥有。
- `can_execute_payment` 覆盖立即/预约提交、人工审批或放行、手动触发支付、修改预约时间、转为立即支付、取消或作废支付单；获得该能力的 Editor 执行时仍需通过模块准入、账号状态、支付状态、组织钱包和统一资金校验入口。系统到期自动执行沿用已经有效提交的预约指令，事件记录 `actorType=system`，不伪造用户操作人，也不改写 `fundingUid`。
- 取消、失败释放和退款回补均回到原资金记录的 `fundingUid`；Owner 后续变化不迁移既有占用。若需要由新 Owner 承担，必须取消原资金承诺并由新 Owner 重新提交，生成新的资金记录和 `fundingUid`，不得直接改写历史记录。
- `can_execute_payment` 不可传递：非 Owner/T1 的 Editor 即使已获授权，也不能为自己或他人授予/收回该能力；Viewer 永远不能获得。Editor 降为 Viewer、被移除或账号跨境支付模块停用时，该能力立即失效，其中降级/移除同时清除对象上的授权值。
- `can_execute_payment` 不包含删除草稿、转交 Owner 或管理协作者；支付草稿仅当前 Owner 和当前对象的显式 Editor 可以删除，T1 隐式权限、T2 范围 Editor 和其他范围写权限均不能据此删除，删除事件必须保留实际 `actorUid`。`can_execute_payment` 与 `can_manage_collaborators` 相互独立，任一能力都不能推导另一项。
- 跨境支付 Owner 不能主动转交支付单或草稿，只能消费独立“成员转组/离职数据移交”流程的接口结果：T1 操作成员转组时可选择数据跟随本人或移交给有效接收人；选择跟随时 `owner_uid` 不变并按新组重算范围，选择移交时更新 `owner_uid`；离职解绑一经提交即不可撤销并立即使原账号失去组织业务权限，Owner 移交可以在退出后续办。数据移交流程本身作为必需的独立议题另行确认，支付模块在本节仅假设该标准接口存在。

验收：

- 未启用跨境支付模块的账号即使被添加为支付单协作者或命中 T1 隐式策略，也不能访问或操作支付单。
- 组织策略开启时，同一正式分组内已启用模块的成员无需逐单授权即可获得 Viewer；关闭后不再命中该范围权限，但已有显式 Viewer/Editor 保留。
- T2 无法修改自己所在分组或其他分组的该策略；组织所有者一次修改后对所有正式分组统一生效。
- 只开启父开关时，同组动态 Viewer 看到脱敏收款信息且无法下载回执；再开启敏感信息子开关后可查看完整收款信息和回执，但所有写操作及组织钱包汇总仍不可见。
- 关闭父开关必须同步关闭敏感信息子开关；再次开启父开关时不得自动恢复此前的敏感信息授权。
- 显式 Viewer 始终可查看完整收款信息和回执，不受同组敏感信息子开关关闭影响；移除显式 Viewer 后，若该账号仍命中同组动态 Viewer，则按当前父子开关重新计算读取范围。
- T1 或隐藏分组成员担任 Owner 时，任何隐藏分组成员都不会因该策略获得 Viewer；组织钱包和全组织支付汇总也不会因对象 Viewer 被下发。
- 同一组织内具备支付单新建/编辑权限的账号，按同一网红频道查询时可以选择由其他成员历史保存的收款账号；查询结果不能暴露其他频道或来源支付单信息。
- 原收款账号创建人转组或离组后，组织历史记录仍可检索复用；跨组织账号使用相同频道时不得返回本组织记录。
- 草稿转正式支付单后 Owner、显式协作者和隐式策略结果保持连续，不产生一份新的孤立 ACL。
- 所有账号均显示只读的 `不设账号个人上限，使用组织共享余额`；系统不能将其展示或解释为真正“无限制”。
- 支付对象、操作事件和资金记录分别保存 `created_by / owner_uid`、`actorType + actorUid` 和 `fundingUid`；提交、审批、放行、手动触发、系统自动执行、Owner 移交和协作者变更均不能混写或覆盖这些历史身份。
- 普通 Editor 可以编辑允许修改的草稿/支付单字段，但不能提交、审批、放行、触发或改变支付时点；授予 `can_execute_payment` 后才出现并可调用对应资金动作，前后端使用同一判定。
- Owner 和命中跨境支付 T1 隐式策略的 T1 无需显式保存 `can_execute_payment=1` 即可执行；策略关闭或 T1 降级后，天然能力立即失效，但其对象上已有的显式 Editor 授权仍按当前有效身份判断。
- Viewer、同组动态 Viewer 和未获资金执行授权的 Editor 调用任一资金执行接口时，服务端均拒绝；按钮隐藏或禁用不能替代服务端鉴权。
- Editor 降级为 Viewer 或被移除后，`can_execute_payment` 不得残留；已获该能力的 Editor 也不能修改自己或他人的授权。
- Editor 即使拥有 `can_execute_payment` 也不承担支付额度；立即/预约提交均占用提交时 Owner 的资金池份额，后续审批或放行人不改变该归属。
- 支付草稿 Owner 和显式 Editor 均可删除；仅命中 T1 隐式权限、T2 范围编辑或其他范围写权限的账号不能删除。正式支付单不提供硬删除。
- 支付单在成员转组时能分别验收“数据跟随本人”和“移交给接收人”；离职解绑时没有“跟随本人”选项。移交后原 Owner 不因历史 Owner 身份保留任何权限，但其独立命中的当前角色范围或后续显式授权仍按统一权限合并器判断。
- 本期不新增可编辑金额、`limit / pending / used`、余额分配页面或退款回补台账。

</details>

#### D3. 消息中心单会话跨项目协作（Backlog，本版本不做）

原始诉求：

- 消息中心单个消息框支持添加协作者。
- 协作者可以跨项目跟进该会话。

后置原因：

- 当前消息会话依附于项目、频道和发送身份，没有独立会话协作者字段、授权接口或协作会话入口。
- 实现需要新增会话级 ACL，并逐项约束消息历史读取、发送身份、备注、合作状态、标签、物流、付款及来源项目数据，无法作为本期小幅扩展完成。
- 本版本不新增会话 ACL、跨项目发送授权或“协作会话”入口，也不通过扩大项目协作者权限变相实现。【UI建议】本项不新增入口，继续留在 Backlog。

Backlog 再启动时优先评估单一“跟进协作者”角色，只开放单会话查看、回复和已读状态；不得默认开放来源项目、CRM 数据或协作者管理权限。

#### D4. 搜索隐藏已联系/合作网红区分个人与团队（P1）

现状事实：

- 当前隐藏筛选已有“已联系、沟通中、合作中、已合作”等条件。
- “已联系”已经支持当前账号、团队其他成员和全团队；“沟通中”固定使用团队范围，“合作中 / 合作完成”只有状态，没有账号范围。

已确认落地口径：

- 【UI交互】保留“已联系”现有选项、参数和接口语义，不做重构。
- 【UI交互】为“沟通中 / 合作中 / 合作完成”分别增加 `我对接的 / 全团队对接的` 两档，不增加“本组”或指定成员。
- 新范围默认使用 `全团队对接的`，保持当前搜索结果不变。
- “我对接的”按 CRM `ownerUser` 判断；没有对接人的记录不计入当前账号范围。
- “全团队对接的”只用于排除搜索结果，不返回具体对接人、项目或 CRM 详情，不扩大业务数据读取权限。
- 搜索服务端根据状态和范围执行排除，前端不拉取团队 CRM 数据自行过滤。
- 多个状态可以分别选择不同范围。

验收：

- 选择“我对接的”时，只排除 `ownerUser` 为当前账号且命中对应状态的网红。
- 选择“全团队对接的”时，按组织全部账号的对应状态记录排除，但不向当前账号暴露记录详情。
- 同时选择“我沟通中的 + 全团队合作完成的”时，服务端能按各自范围正确组合过滤。

### 5.5 席位、续约和提示

#### E1. 席位满邀请与验证提示闭环（已实现 / 强制回归）

现状事实：

- `kol-next` 已有席位状态展示、添加成员按钮前置拦截、弹窗内按去重邮箱数量校验，以及无限席位和 `seatInfo` 缺失兼容。
- 待接受邀请已经计入席位占用；邀请成功、撤销、重试和删除成员后会刷新席位信息。
- `/ws/userRelation/batchInvite` 返回 `40026` 时，当前页面会保留弹窗和输入并展示席位已满提示。
- `/sub-relation` 接受邀请页已将 `40026` 映射为独立席位上限提示；仓库已有 `XXL0506` 对应测试用例，说明原始反馈主体已完成但需求状态未同步。

关闭口径：

- 【UI建议】不再作为本版本新增研发功能，不重复建设邀请前置拦截或验证页错误码分支。
- 【UI反馈】作为新邀请流程的强制回归项：邀请者填写邮箱、分组、账号权限和配额后，最终提交仍必须复用现有席位校验。
- T2 邀请开启时与 Owner/Admin 使用相同席位规则，不因邀请角色或目标分组不同而绕过。
- 【UI反馈】前端校验只用于提前提示；邀请提交和接受邀请时均由服务端再次原子校验，处理席位变化和并发竞争。
- 接受邀请时席位已满，继续展示明确原因和动作建议，不回退为“注册失败，请联系客户经理”等通用错误。

强制回归验收：

- 剩余席位为 `0` 时不打开邀请弹窗；批量邮箱数超过剩余席位时不提交，重复邮箱不重复占位。
- 新“权限与配额”邀请表单在最终确认时仍按去重邮箱数校验，不因多步骤流程绕过。
- 邀请成功后待接受邀请立即占位；撤销邀请或删除成员后释放席位并刷新展示。
- Owner、Admin 与已获授权的 T2 均不能发出超过组织剩余席位的邀请。
- 前端席位信息缺失或已过期时，后端 `40026` 仍能阻止邀请或接受；邀请页面保留输入，接受页明确提示“邀请方团队成员席位已满，请联系邀请人释放席位或升级团队套餐后重新邀请”。
- 无限席位组织不被有限席位逻辑误拦截。

#### E2. 降级续约后的子账号限制（TODO / 商业权益专项）

对应反馈：行 33，原表优先级为低。该问题会影响套餐、登录和核心能力拦截，不作为本版本的顺手改动。

需求：

- 续约套餐降低子账号席位后，系统需识别超出席位的既有子账号。
- 超出席位账号不能继续绕过套餐限制使用核心能力。
- 管理员进入成员页时提示需解绑或升级。

待确认：

- 超额子账号是立即冻结、到期后冻结，还是保留登录但限制关键能力。

### 5.6 TODO：无权限筛选项前置说明（商业版本权益）

对应反馈：行 39。搜索高级筛选已通过 `/ws/quota` 预检权限，明确无权限才弹升级；但用户反馈仍认为「能选但不能用」体验差。该项与主子账号协作关联度低，进入配额/版本权益 TODO，不进入本版本。

需求：

- 对无权限筛选项展示锁定/禁用态。
- hover 或点击说明该筛选项所属版本/套餐。
- 提供升级入口。
- 不允许用户选择后才在搜索时泛化弹升级。

验收：

- 企业版不可用的高级筛选项在筛选面板中有明确禁用态。
- 用户不能构造无权限筛选条件发起搜索。

## 6. TODO / 不进入本轮范围

以下 16 条反馈的原始「具体模块」均为「数据导出」。这些问题有价值，但不是「主子账号和权限」主线，本轮先完整保留为 TODO，不进入 spec 主范围，也不占用本轮优先级：

| Excel 行 | TODO |
| ---: | --- |
| 18 | 收藏夹导出前批量刷新频道数据，并解决导出值与详情页不一致 |
| 19 | 导出报表标注哪些邮箱历史已导出，减少线下去重 |
| 20 | 收藏夹支持跨社媒平台导出 |
| 21 | 基础数据导出排除历史已导出网红，并补互动量字段 |
| 22 | 邮件项目一次性导出全部收件人，不受当前 500 条限制 |
| 23 | 合作内容与合作价格拆列导出 |
| 24 | 单日导出超限提示改为“次日再试”，不误写成月度上限 |
| 26 | 基础数据导出增加次数提醒；原表已标记为重复需求 |
| 28 | 基础数据导出支持指定序号范围 |
| 29 | 数据用量中区分收藏夹基础数据导出与深度数据导出 |
| 30 | 导出字段口径与线上展示一致，例如 TikTok 最近 20/10 个视频口径 |
| 31 | 邮箱导出增加网红社媒链接 |
| 32 | 搜索结果与详情页互动率一致性；虽被原表归到数据导出，实际更适合进入数据口径专项 |
| 36 | 数据用量导出增加网红 ID 和社媒链接 |
| 37 | WhatsApp 批量解锁和导出 |
| 38 | 邮箱下载记录增加 Instagram 频道 ID/名称 |

后续建议单独开「数据导出与用量核对」输入，不和账号权限混在同一 spec 里。

### 6.1 TODO：频道历史收款账号治理

已确认本期只做“按网红频道账号检索并复用全组织历史收款人记录”。以下治理能力暂不设计、不进入本期 spec 和验收：

- 历史收款账号的新增版本、覆盖、停用、恢复和删除权限。
- 错误或过期记录的处理方式、影响提示和审计要求。
- 当前删除按钮是否改为停用，以及 Owner、Admin、T2、T3 的管理边界。

该 TODO 不影响组织共享检索与复用能力按已确认口径进入主线。

### 6.2 待确认：组合并是否进入本版本

本版本仅在账号加入目标组流程中，支持把该账号作为 Owner、位于某一来源组的全部项目型对象整批迁移到目标组；作用域严格为 `ownerUid + sourceGroupId -> targetGroupId`，不得触及来源组内其他 Owner 的对象。未来需要将一个组整体并入另一个组时，仍以独立「合并组」流程统一处理源组全部业务对象 `groupId`、Owner、ACL、组成员关系、模块与配额配置、统计口径和历史审计，不能复用单账号名下项目迁移模拟。

当前方案不再彻底删除分组：不需要继续开展业务的组可以带着遗留对象、后台任务、资金承诺和 `REMOVING` 成员关系进入冻结归档，原 `groupId`、数据、责任快照、账本和审计继续保留。归档只能停止新增业务和新的有效成员关系，不能用来取消已形成的资金承诺或抹除历史。

会议新增的问题是：如果客户不是要“封存旧部门”，而是要“把旧部门业务继续并入新部门”，冻结归档不能替代组合并。需在进入生命周期 Spec 前确认本版本是否只支持归档，还是同时加入最小组合并；按项目多选迁移仍属于后续能力。

### 6.3 TODO：支付单组长审核放行（后续版本）

本需求不进入当前版本 spec 和验收；后续版本在现有系统审核、立即/预约/手动执行流程上增加支付领域专用的组级策略：

- 每个组独立保存 `requireT2PaymentRelease: boolean`，新组和存量组默认关闭；不设置组织默认值、继承或覆盖关系。
- 策略实时作用于该组尚未开始实际转账的支付单，不保存订单级策略快照。已进入支付中、成功、失败、退款或终止的支付单不回退。
- 立即执行：系统审核通过后进入待组长放行，任一同组 `ACTIVE T2` 点击后立即开始转账。
- 定时执行：系统审核通过后、预约时间到达前由 T2 完成预审核；预约时点只有在系统审核和 T2 审核都完成时才自动执行。任一条件未完成均进入预约超时，必须重新预约、转立即或作废，逾期补审核不得突然恢复自动执行。重新预约或修改金额、币种、收款人、预约时间等关键内容后，原审核失效并需重新审核。
- 手动放行：支付者点击手动放行后进入待组长放行，T2 点击后立即开始转账，不再要求第二次普通手动触发。
- 同组存在多个 `ACTIVE T2` 时任意一人处理即可，首个成功放行生效；并发操作必须幂等，其他人收到“已处理”结果。
- 若把草稿提交为正式支付单的实际 `actorUid` 在支付单到达组长闸门时是所属组 `ACTIVE T2`，则无论组内有多少 T2 都跳过审核；只判断闸门当下身份，不要求其提交时已经是 T2。提交后升为 T2 可命中豁免，降为 T3 或进入 `REMOVING` 则必须由其他 `ACTIVE T2` 放行。该豁免不授予提交权限，提交人仍须是 Owner 或拥有 `can_execute_payment` 的 Collaborator。
- 支付列表在当前组提供 `待我放行` 快捷筛选、待办数量、支付者/金额/执行方式/预约时间筛选和只读审核详情；通知中心跨组汇集账号作为 T2 的全部待办，通知显示组名，点击后切换到对应组。本期不建设全组织跨组审批工作台。
- 立即、定时和手动待办创建、临近预约提醒、审核超时、放行成功均发送幂等系统通知；任一 T2 处理后从其他 T2 待办中同步移除。组长审核是独立业务动作，不把 T2 写成 Collaborator，也不授予一般 `can_execute_payment`。
- 关闭组策略会实时解除未执行支付单的组长闸门；涉及待放行订单时必须在后续 spec 中明确影响预览、总笔数/总金额、二次确认及立即单批量继续执行的安全边界。

## 7. 本版本优先级与逐项评审顺序

### 7.1 优先级定义

- `P0`：本版本目标不可缺少。逐项评审确认后必须进入 spec 和版本验收。
- `P1`：同一版本的候选项。只有在用户价值明确、接口能力可复用且整体工作量允许时进入；可裁剪而不破坏版本主目标。
- `TODO`：本版本不做。保留原始证据和后续归属，不进入本版本 spec、开发和验收。

排序不是直接照抄原表的“高/中/低”，而是综合四项判断：原始反馈强度、与主子账号主线的相关性、聚星现有实现基础、行业权限方案提示的风险和边界。

### 7.2 逐项评审方法

每次只讨论一项，固定带齐以下信息：

1. 原始需求描述、反馈次数、优先级、客户等级/紧急程度和原备注。
2. `kol-next` 当前已经具备什么、缺什么。
3. 行业成熟 SaaS 的通用做法及对聚星的约束，不直接照搬功能全集。
4. 2-3 个落地方案、推荐方案、明确不做的边界。
5. 最终确认：优先级、页面入口、角色/数据范围、接口依赖、验收标准。

### 7.3 评审清单

| 顺序 | 优先级 | 议题 | 原始反馈证据 | 行业/现状判断 | 建议落地边界 | 状态 |
| ---: | --- | --- | --- | --- | --- | --- |
| 1 | P0 | 组织身份、组内身份与数据范围 | 行 11、12、14、40；行 40 为 `3+` 次，行 11/14 中高或高；行 12 虽标高但备注“低优” | 成熟 SaaS 普遍拆分组织管理身份、团队关系与对象权限；现有 `adminStatus` 需拆义迁移 | 唯一 Owner、`0..N` Admin；账号可有 `1..N` GroupMembership，每组 `0..N T2`；Admin 管理范围不产生业务权限 | 已确认 |
| 2 | P0 | 成员与协作人搜索 | 行 3；高优、已确认；客户有 27 个子账号 | 成员页无搜索，公共协作人选择器未开启搜索；属于低成本高频操作优化 | 成员页支持昵称/邮箱搜索；P0 对象协作人选择器复用同一搜索，且不扩大原有可选账号范围 | 已确认 |
| 3 | P0 | 管理视角与 GroupMembership 配额配置一期 | 行 14、40、41；行 40 为 `3+` 次 | 当前已有部分子账号上限但没有组级约束；Scope 类型不同，不能用配额模拟全部模块开关 | Owner/Admin 只为可分配型 Scope 配置组与 `uid+groupId` 上限；不可分配 Scope 随组织权益；T2 按组织开关受托管理当前组；邀请时显式确认首组和配置 | 已确认 |
| 4 | P0 | 消息中心自定义标签按创建来源筛选 | 行 5；`2+` 次、3.13 加急、已确认 | 原始痛点是团队标签太多、难找，不需要升级为私有标签权限 | 服务端补 `creatorUid+createdGroupId`；按 `我创建的 / 当前组成员创建的 / 全部` 筛选；存量来源归默认组 | 已确认 |
| 5 | P0 | 组长默认协作策略与对象级授权 | 行 8；3.16 加急；行 40 再次提到重复添加协作人；CRM/跨境支付为评审中确认的范围补充 | 邮件现有强制写入具体管理员会产生同步和越权风险；线上协作者没有通用 Viewer/Editor 等级 | 组织级开关默认关闭；开启后 T2 以锁定系统来源成为本组项目普通 Collaborator，替代旧 Admin/T1 强制协作；只读需求使用查看范围/显式查看授权；邮件/资源夹/内容监控/CRM/支付 P0 | 已确认 |
| 6 | P0 | CRM 标签删除权限 | 行 2；已确认大型需求 | Salesforce 等区分“能否执行删除动作”和“能看到哪些数据”；现有数据管理页可作为入口 | 新增独立标签删除动作权限及影响提示；CRM 普通写范围或 Collaborator 不能自动获得删除权限 | 已确认 |
| 7 | P0 | CRM 记录统一协作与线上权限迁移 | 行 11、13、14、40；行 13 中高、近期解决 | CRM 已有 `ownerUser` 和四项写范围；新根模型要求记录稳定归组且禁止跨组协作，但 CRM 不是强制 Owner 的项目型对象 | `ownerUser` 映射可空 `assigneeUid`；Assignee 天然治理协作；已有 Assignee 时，当前 Assignee 与同组 `ACTIVE T2` 都可指定新的同组 Assignee，未分配时仅 T2 可分配，日常不能主动清空；普通 Collaborator 和 Owner/Admin 均不能日常改派；退组/组织移出可按组批量改派，未选则置为未分配；四项旧范围留到 spec 评审确认 | 已确认目标模型；迁移方案待定 |
| 8 | P0 | 跨境支付模块、支付单协作与资金限制 | 评审中新增；现状已有支付单、草稿、频道历史收款人和组织钱包，但无 GroupMembership 准入/对象授权/账号资金限制 | 支付权限需把对象协作、正式单同组只读、敏感读取、执行权、共享收款主数据与资金限制分层 | 草稿仅 Owner/Collaborator 可见；正式单同组固定只读；Owner/获 `can_execute_payment` 的 Collaborator 执行；资金承诺冻结 `fundingUid+fundingGroupId`；历史收款账号组织共享 | 已确认 |
| 9 | P0 | 类型化 Scope、团队总额度与个人额度隔离 | 行 10、15；行 15 为加急且要求尽快解决 | Scope 包含消耗、解锁、容量、窗口、频率和门禁；只有可分配型 Scope 适合三级上限；汇总管理不等于项目明细 | 仅可分配型 Scope 增加组/成员 `inherit / capped`；不可分配 Scope 随组织权益；额度查看按 Owner/Admin/T2/T3 范围由服务端裁剪 | 已确认 |
| 10 | P0 | 批量增加组成员额度 | 行 25；中高、5 星客户 | 当前已有批量设置固定上限 | 仅对可分配型 Scope 的 `capped` GroupMembership 增加；`inherit` 和不可分配 Scope 跳过；提交前预览、操作后摘要 | 已确认 |
| 11 | 回归 | 席位满邀请与验证提示闭环 | 行 16、34；行 16 中高、5 星、尽快解决 | 当前代码、错误码映射和测试表明主体已实现 | 不新增席位功能；新的“首组+权限+配额”邀请表单以及可选 T2 邀请均复用前置、提交、接受三段校验 | 已实现，关闭；强制回归 |
| 12 | P1 | 搜索隐藏已联系/合作网红的个人/团队范围 | 行 9；高优、已确认 | 当前“已联系”已有账号范围基础；其他三个状态只缺范围参数，适合增量扩展 | 保留“已联系”现状；为沟通中、合作中、合作完成增加 `我对接的 / 全团队对接的`，默认团队，不增加本组或指定成员 | 已确认纳入 |
| 13 | Backlog | 消息中心单会话协作者 | 行 7；高优、5 星客户 | 需要独立会话 ACL、跨项目列表入口和发送身份校验，无法作为小幅扩展完成 | 本版本不做；后续优先评估单一“跟进协作者”，不得扩大来源项目或 CRM 权限 | 已移入 Backlog |
| 14 | Backlog | 任务列表默认协作 | 行 40；`3+` 次中的组成诉求 | 原反馈更可能指代码仓外的旧版 `/brand/campaigns` | 本版本不做；未来确认其根对象和 `groupId` 后，再决定是否接入组长默认协作策略 | 已移入 Backlog |
| 15 | P1 | 配额周期明显展示 | 行 17；`10+` 次、高优、尽快解决 | 与权限主线关联较低，但证据最强且现有页面已有起止时间，属于低成本解释优化 | 纳入本版本；仅在 `/brand/sub-account/quota` 当期使用首屏调整位置和文案，不修改周期规则 | 已确认纳入 |
| 16 | TODO | 主账号编辑/删除子账号业务对象 | 行 14、42；行 14 高优，行 42 备注“刚需待确定、杠杆不高” | Atlassian 等明确管理员不自动拥有应用内容；直接全开风险高 | 等对象级 ACL 明确后逐对象评估，本版本不做无差别编辑/删除 | 不进本版本 |
| 17 | 待确认 | 月度配额、月度用量和更新标识 | 行 4、6、27；中到中高；2026-08-20 会议追加年付月发和年度额度按月下分场景 | 属于配额周期和计费规则，但会影响组/GroupMembership 配额契约 | 拆分组织发放周期与下级控制周期后决定是否进入本版本 | 待确认 |
| 18 | TODO | 组织套餐无限额度与所有版本查看自身剩余量 | 行 35、43；一条中高紧急、一条明确低优 | 属于套餐权益展示一致性；账号 `inherit` 已纳入 P0，不属于真正无限额度 | 独立作为配额展示优化，不占本版本范围 | 不进本版本 |
| 19 | TODO | 无权限高级筛选项前置提示 | 行 39；2 次、中低 | 属于商业版本 Entitlement，不是主子账号协作 | 进入搜索/版本权益体验专项 | 不进本版本 |
| 20 | TODO | 降级续约后的超额子账号 | 行 33；低优 | 涉及套餐、登录和能力拦截，风险远高于页面提示 | 进入商业权益专项 | 不进本版本 |
| 21 | TODO | 数据导出 | 16 条，详见第 6 节 | 与本版本主线无关 | 保留完整行号，单独立项 | 不进本版本 |
| 22 | P0 | 退组/离职数据移交 | 评审中从支付 Owner 变更、成员退组和离职场景补充 | Owner 变更、ACL 清理、接收人补权和关系状态必须由统一任务协调 | 组织成员与 GroupMembership 均有离场状态；`REMOVING` 即失权；支持按组处理，也支持选择一个已有或新邀账号整体替换；Owner、Assignee 及有效显式对象关系按组原子移交；组织移出不可撤销；有摘要页和通知 | 已确认 |
| 23 | P1 | 内容监控/视频监控标签定义管理限制 | 2026-07-22 新增；要求限制 T3 增删改标签，管理身份/T2 保留权限 | 共享标签定义与对象标签应用需拆动作鉴权 | Owner/Admin 可改组织级开关；任一有效 T2 可管理共享定义但不获得跨组项目权限；只限制定义，不影响按对象应用已有标签 | 已确认纳入 |
| 24 | P0 | 全局组身份切换 | 新根模型必需能力 | 多组账号若没有明确业务上下文，会造成项目归属和配额扣减歧义 | 全局持久化 `currentGroupId`；创建、候选人、筛选、配额均使用当前组；非 `ACTIVE` 组不可切换 | 已确认 |
| 25 | P0 | 默认组无感初始化 | 存量组织迁移必需能力 | 线上无统一业务组，不能要求客户先配置后继续工作 | 组织级原子创建真实默认组；全体成员与对象归组；组织 Owner 初始化为 T2；项目 Owner、CRM Assignee、协作者、附加能力、配额和 CRM 普通写结果按迁移真值保持 | 已确认；需迁移真值验证 |
| 26 | P0 | Owner 名下项目整批迁组与对象授权禁用恢复 | 多组成员和项目固定归组的必需流程 | 加入新组不能自动搬运他人项目，也不能静默丢跨组对象授权 | 仅迁 `ownerUid+sourceGroupId`；逐对象原子、失败可重试；跨组协作者、显式查看授权和附加能力完整禁用，成员入组后自动恢复，显式删除后不再恢复 | 已确认 |

### 7.4 历史逐条评审记录（废案，不生效）

<details>
<summary>展开旧 T1-T2-T3、唯一主组、隐藏分组与 T1 隐式协作方案</summary>

> 本节至第 7.13 节是根模型重开前的讨论轨迹。原始反馈、行业护栏和问题拆分仍可追溯，但其中任何“已确认”“验收护栏”均已被当前方案替代，不得进入 spec、研发或验收。当前生效范围见第 5 节、第 7.3 节和第 9.3 节。

#### 历史 7.4：T2 数据范围与业务动作

#### 原始反馈

- 行 11：细化组长在邮件开发、数据看板、CRM 等模块的分层管理。原表中高优、5 星客户、状态待确定。
- 行 12：增加“超级管理员”，拥有主账号一样的权限。原表高优、已确认大型需求，但备注为“可以支持，但低优”。
- 行 14：主账号查看、编辑子账号所有数据。原表高优、要求尽快解决；备注建议通过新增角色分配。
- 行 40：主账号查看子账号全部动作、分配额度、设置不同功能权限，并减少逐项目添加协作者。反馈 `3+` 次、中高优、4 星客户。

这四条反馈把三类问题混在了一起：

1. 账号在组织里的身份：主账号、管理员、组长、成员。
2. 可以执行什么管理动作：管理成员、分配额度、设置默认协作策略。
3. 可以看到和操作哪些业务数据：自己、本组、全团队、指定协作对象。

#### 聚星现状

- 前端角色值只有管理员 `adminStatus=1`、成员 `0`、组长 `2`；主账号通过账号关系识别，没有独立“超级管理员”值。
- 子账号成员页使用 `Boolean(adminStatus)` 判断管理员能力，邮件项目则明确只有 `adminStatus=1` 算管理员，说明组长能力在不同入口存在口径风险。
- 数据管理页已有 CRM 角色范围和邮件“强制添加管理员协作人”的配置雏形，可以在现有结构上增量统一。

#### 行业护栏

- HubSpot 常用 `自己 / 本组 / 全部` 作为记录访问范围，角色和数据范围不是同一个字段。
- Google Workspace 的管理员角色可以限制在组织单元范围内，适合映射聚星组长。
- Atlassian 区分组织管理员和应用内容访问，管理员身份不自动等于拥有所有业务内容。
- GitHub 区分组织级角色与具体仓库/对象角色，说明账号管理权和项目协作权应分层。

#### 已确认落地口径

1. T2 是账号管理等级和本组数据范围，不聚合模块可用性或配额；每个 T2 账号仍需按 `uid` 直接启用具体模块。
2. T2 账号未启用某模块时为无权限；模块已启用时，T2 获得本组汇总数据、成员维度数据和具体业务对象范围。
3. 模块已启用后的 T2 常规业务行为由组织模块策略统一设置为 `查看 / 编辑`，所有分组使用同一套策略；系统针对每个项目，根据其 Owner 当前所属分组判断 T2 是否命中本组范围，不生成模块级或批量项目协作者记录。
4. “编辑”只覆盖常规创建和修改动作，不自动包含删除、负责人转交、协作者管理等高风险动作。
5. 删除、负责人转交、协作者管理采用固定角色/对象权限规则；协作者管理的非传递授权已在 7.7 节确认，其余高风险动作继续逐项确认。

#### 验收护栏

- 同一模块中，已启用该模块的 T2 对本组列表、Dashboard 汇总和对象详情的查看范围保持一致。
- 模块未向该 T2 账号启用时，列表、Dashboard、详情和对象显式授权均不能绕过账号模块硬限制。
- T2 没有编辑权限时，前端不展示或禁用写操作，后端仍必须执行相同的权限校验。
- T2 不能通过对象协作者身份获得其他主分组对象的权限；对象授权选择器和后端写接口均必须执行同组校验。
- 配额不足、套餐无权益或账号停用仍可阻断操作，不能被 T2 角色或对象授权绕过。

#### 历史 7.5：T1 主账号与超级管理员

#### 原始反馈与现状

- 行 12 要求增加与主账号权限相近的超级管理员；行 14、40 要求主账号能够管理子账号业务数据、功能权限和配额。
- 聚星已有唯一主账号关系和 `adminStatus=1` 管理员，不需要为超级管理员新增一套重复角色值。

#### 行业护栏

- GitHub、Atlassian 等产品允许设置多名高级管理员，避免组织日常管理依赖唯一账号。
- 所有者身份与高级管理员可以处于同一管理层级，但所有权转让、账单和根级角色任免应保留为所有者专属动作。

#### 已确认落地口径

1. 每个客户组织有且仅有一名主账号，并允许设置 `0..N` 名超级管理员；二者同属 T1。
2. 主账号继续通过现有组织/主子账号关系识别；超级管理员直接复用现有 `adminStatus=1`，不新增角色枚举。
3. 主账号和超级管理员均可管理成员、分组和 T2/T3 账号等级，并为正式分组配置模块及配额上限；T1 保留直接修改任意子账号模块和配额的能力。无 T2 的正式组由 T1 直管，任命 T2 后再按组织委派开关开放日常组内配置。项目业务数据权限先受组/账号模块上限约束，再针对当前项目按组织模块策略、Owner 所属范围和项目显式授权计算。
4. 只有主账号可以执行主账号转让、访问账单/合同/支付设置，以及任免超级管理员。
5. 超级管理员不能移除主账号，也不能赋予自己或他人所有者专属权限。
6. 除“T2 能否管理本组账号权限”和“T2 能否邀请本组成员”两个开关外，只有主账号可以修改组织权限策略；这两个开关允许主账号和超级管理员修改，其他策略对超级管理员只读。

#### 验收护栏

- 组织内始终只能存在一名主账号，主账号转让完成前原主账号身份保持不变。
- 超级管理员数量可以为零，不影响主账号直接管理组织。
- 现有管理员迁移后统一显示为“超级管理员”，已有普通管理权限不丢失。
- 所有者专属入口必须同时由前端隐藏和后端鉴权拦截。

#### 历史 7.6：唯一组管理员与分组委派边界

#### 原始反馈与现状

- 行 11 要求组长分层管理邮件开发、Dashboard、CRM 等模块；行 40 要求按角色控制功能和业务范围。
- 聚星已有分组和 `adminStatus=2` 组长，但尚未统一定义唯一组管理员、未分组成员和分组权限/配额上限。

#### 行业护栏

- Google Workspace 中每个用户归属一个 Organizational Unit，适合映射唯一主分组和确定的管理范围。
- 行业产品可以支持多名团队维护者，但聚星本版本选择每组最多一名 T2；是否任命 T2 由 T1 决定，无 T2 时不启用组内委派，仍不引入多团队归属或嵌套分组。

#### 已确认落地口径

1. T1 主账号和超级管理员不要求归属分组。
2. 每个 T2/T3 账号有且仅有一个主分组，分组之间成员互斥。
3. 每个正式分组允许 `0..1` 名 T2。T1 可以先建立空组、配置组模块和配额上限，再向组内加入 T3；空组或无 T2 的非空组均由 T1 直管。
4. T1 为每个正式分组配置允许的顶级模块集合和分组配额上限；这是 T2 配置自己和本组 T3 时不可突破的委派边界。
5. 组内存在 T2 时，全局“T2 能否管理本组账号权限”开关关闭则 T2 只能查看组上限和成员配置；开启后 T2 可以在组上限内修改自己及本组 T3 的模块和配额。组内无 T2 时，该开关对该组无实际作用。
6. T1 保留直接修改任意 T2/T3 账号配置的能力，但正式组的日常流程以“T1 配置组上限、T2 配置组内账号”为主。
7. 系统维护一个不可删除、不可设置 T2、对普通分组管理界面隐藏的隐藏分组。组织没有正式分组时，所有 T3 自动归入隐藏分组；存在正式分组时，未归组 T3 也归入隐藏分组。
8. 隐藏分组的模块和配额上限直接继承组织上限，不再叠加人工配置的组级限制；其成员由 T1 直接配置，委派开关对隐藏分组不生效。
9. 所有邀请账号初始均为 T3，不支持直接邀请为 T2。T1 邀请时可以选择正式分组，未选择时进入隐藏分组；成员加入组织后，T1 可再将正式组内成员任命为 T2。
10. 同时开启“T2 能否管理本组账号权限”和“T2 能否邀请本组成员”后，T2 可以邀请 T3 到自己的正式分组；T2 始终不能清退、换组或修改成员账号等级，上述动作仅 T1 可执行。
11. 普通成员不允许跨主分组成为 Viewer/Editor 或接收 Owner；该规则为系统不变量，不提供“允许跨组协作”组织开关。T1 是组织级账号，不归属某个分组，仍可作为具体对象的显式协作者或数据接收人。

#### 验收护栏

- 同一个 T2/T3 账号不能同时出现在多个主分组。
- 设为 T2 前必须先选择正式分组；隐藏分组中不能存在 T2。
- 正式分组最多一名 T2。T1 可以移除或降级 T2，使该组回到无 T2、由 T1 直管的状态；更换 T2 时旧 T2 降级与新 T2 任命必须在同一事务完成，不能短暂出现两名 T2。
- T2 修改自己或本组 T3 时，后端必须同时校验目标账号归属、组模块集合和组配额上限，前端禁用不能授予的选项。
- 换组后立即按新分组重新计算角色范围；由该账号负责的项目随 Owner 进入新组范围，仍与 Owner 同组或属于 T1 的 Viewer/Editor 保留，因换组变成跨组的普通成员 ACL 必须清除。
- 隐藏分组不可删除、不可改名、不可设置 T2，不作为正式分组出现在分组配置列表中；成员列表仍需能识别账号当前未归入正式分组。

#### 历史 7.7：协作者等级与权限优先级

#### 原始反馈与现状

- 行 13 要求 CRM 协作人只读；行 7、8、40 要求消息、邮件项目、资源夹等对象支持协作，并减少重复添加协作者。
- 聚星现有协作人组件已经具备普通协作者和管理权限的选择能力，但不同对象尚未形成统一权限等级和冲突计算规则。

#### 行业护栏

- GitHub、Notion 等产品把具体资源权限拆成查看、编辑和管理等级，并允许对象授权独立于组织角色存在。
- 对象授权通常用于增加具体资源权限，不能降低用户通过更高层级角色已经获得的权限，也不能绕过账号、套餐或安全硬限制。

#### 已确认落地口径

1. 需要协作权限的项目型对象统一采用三种项目级对象身份：负责人 Owner、编辑协作者 Editor、查看协作者 Viewer。Owner/Editor/Viewer 必须绑定具体项目，不设置模块级协作者名单。
2. Owner 可以查看、编辑、管理协作者并发起负责人转交；跨境支付 Owner 不能主动转交，支付对象只接受成员转组/离职数据移交流程产生的 Owner 变更。
3. Editor 可以查看和执行常规编辑，默认不能管理协作者、删除对象或转交负责人；跨境支付草稿允许当前对象的显式 Editor 删除，是 D2 已确认的对象类型例外，不扩大其他对象或范围 Editor 的删除权限。
4. 组织所有者开启“允许 Editor 管理协作者”策略后，Owner 和 T1 可以为 Editor 单独授予或收回 `can_manage_collaborators`；邮件项目现有 `canManageMembers` 直接映射为该权限。
5. 获得 `can_manage_collaborators` 的 Editor 可以添加/移除协作者，并在 Viewer、Editor 之间调整协作等级，但不能向其他人授予或收回 `can_manage_collaborators`。
6. Viewer 只能查看对象，任何组织策略下都不能获得 `can_manage_collaborators`，也不能执行编辑或其他高风险动作；CRM 只读协作人直接映射为 Viewer。
7. 针对当前项目，最终普通业务权限取“角色范围权限”和“当前项目对象授权”中的较高者；对象 Viewer 不会降低 T1/T2 对该项目已有的范围权限。
8. T2 只有本组查看权限时，可以通过明确的 Editor 授权编辑某个本组对象；T2/T3 均不能被授权为其他主分组对象的 Viewer/Editor。
9. `模块无权限`、套餐无权益、账号停用等属于硬限制，优先于对象授权；这些用户不能通过成为协作者绕过限制。
10. 删除和负责人转交继续作为独立高风险动作判断，不包含在通用 Editor、`can_manage_collaborators` 或普通模块编辑权限中；支付草稿的显式 Editor 删除例外单独按对象类型判断。
11. 跨境支付的 Editor 默认只能普通编辑；Owner/T1 可额外授予非传递的 `can_execute_payment`。该能力只覆盖已确认的资金执行动作，不包含删除草稿、负责人转交或协作者管理，也不构成账号级模块动作矩阵。

#### 验收护栏

- 同一用户通过多个路径获得权限时，按有效权限中的最高等级执行，不因被设置为 Viewer 而降级。
- 协作者选择器只展示 Owner 同一主分组内、账号和模块状态有效的 T2/T3，以及组织级 T1；后端拒绝写入跨主分组普通成员 ACL。
- T1 无需成为对象协作者即可授予或收回 `can_manage_collaborators`；Owner 天然拥有同样能力。
- 非 Owner/T1 即使已有 `can_manage_collaborators`，也不能修改任何人的该项权限，前端不展示对应开关，后端拒绝越权请求；该非传递规则属于系统不变量。
- Editor 降级为 Viewer 或被移除时，自动清除 `can_manage_collaborators`。
- 支付单 Editor 降级为 Viewer 或被移除时，同时清除 `can_execute_payment`；Viewer 永远不能持有该能力，已有该能力的 Editor 也不能继续委派。
- `can_manage_collaborators` 与 `can_execute_payment` 独立计算：能管理协作者不代表能执行支付，能执行支付也不代表能修改协作者。
- 历史邮件项目中已有 `canManageMembers=1` 的协作者继续保留管理协作者能力，但升级后不能继续委派该权限。
- 无模块权益或账号停用的用户不能被选为有效协作者；已有授权在状态失效后不再生效。
- 前端隐藏或禁用无权动作，后端对查看、编辑和高风险动作分别鉴权。
- 通用对象身份是后续 spec 的项目级接口契约，不代表所有业务对象都在本版本一次性接入，也不得据此抽象出模块级协作者。

#### 历史 7.8：负责人产生、转交与分组范围

#### 需求来源与现状

- 用户目标模型要求每个项目型对象有明确负责人，通常由创建者担任，并允许后续转交。
- 原始反馈行 7、8、13、40 虽未完整描述负责人生命周期，但协作、管理视角和成员清退都依赖一个稳定的负责人规则。
- 聚星现有部分项目已有创建人或协作者字段，但未形成跨模块统一的 Owner、换组和清退处理口径。

#### 行业护栏

- HubSpot 等 CRM 通常为业务记录设置唯一 Owner，并基于 Owner 及其团队计算记录范围。
- Salesforce 的 Owner 转交要求新负责人具备相应对象权限，并允许 Owner、上级管理角色或管理员在权限范围内执行转交。

#### 已确认落地口径

1. 每个接入协作模型的项目型对象有且仅有一名 Owner，创建者默认成为 Owner；`created_by` 永久记录最初创建人，`owner_uid` 表示可转交的当前负责人。
2. 项目不保存独立 `group_id`；项目当前所属管理范围由 `owner_uid` 对应账号的当前主分组动态派生。
3. 除跨境支付外，Owner 可以将负责人转交给同组、账号有效且拥有该模块基础权限的成员。
4. 组织所有者开启“T2 可转交本组负责人”策略后，拥有该模块编辑权限的 T2 才可以转交本组项目负责人；Editor、Viewer 不能执行负责人转交，跨境支付也不开放 T2 转交。
5. 除跨境支付外，T1 可以操作同一主分组内的负责人转交，但不能把 A 组 Owner 的对象直接转给 B 组普通成员；T1 自身作为组织级账号可担任 Owner 或数据接收人，不视为跨组转交。跨境支付只能由 T1 通过成员转组/离职数据移交流程触发 Owner 变化。
6. Owner 本人换组时，普通项目默认随本人进入新组范围；成员转组流程选择“全部数据跟随本人”时 Owner 不变，不属于跨组转交。选择“全部数据移交”或执行离职移交时，普通接收人必须与原 Owner 当前主分组相同，也可选择组织级 T1；因 Owner 换组变成跨组的普通成员 ACL 必须清除。
7. T1 或隐藏分组成员担任 Owner 时，项目没有 T2 管理范围；Owner、同属隐藏分组且被明确授权的 Viewer/Editor，以及命中该模块 T1 隐式权限策略或被显式授权的 T1 可以访问。隐藏分组不产生自动同组 Viewer。
8. 清退 Owner 前必须将其负责对象转交给其他有效成员，支持 T1 批量转交，不允许产生无 Owner 对象。
9. 成员换组或批量转交前，展示受影响项目数量、接收范围和将清除的协作者权限，并要求确认。
10. 当前 Dashboard 按 Owner 当前分组汇总；如后续需要还原历史组别业绩，在业务事件中记录“发生时所属组”快照，不给项目增加固定分组字段。
11. 非 Owner 账号通过角色范围或项目 Editor 获得写权限后，修改的是同一个项目；普通编辑和业务执行均不自动改变 Owner、项目归属或 Dashboard 归属。
12. 创建人不因历史创建关系永久保留权限；Owner 转交后，原创建人只有在仍命中角色范围或项目显式授权时才能继续访问。
13. “成员转组/离职数据移交”是本版本必需但独立评审的 P0 议题；本节先锁定支付模块的接口消费口径，不在支付对象内部另建一套成员移交流程。

#### 验收护栏

- 项目范围始终可以通过当前 Owner 唯一计算，不维护第二套项目分组状态。
- 同组转交后 T2 范围不变；Owner 本人换组后，新旧组权限立即按 Owner 的新主分组重算。
- 普通成员不能保留或新增跨主分组 Viewer/Editor；Owner 换组导致的跨组 ACL 在同一事务中清除，其附带的 `can_manage_collaborators`、`can_execute_payment` 同时清除。
- 新 Owner 必须是组织内有效账号并拥有模块基础权限；停用、待接受邀请或无模块权益的账号不可成为 Owner。
- 成员清退接口在仍有负责对象时必须阻断，并返回待转交对象数量。
- 支付 Owner 不能从支付详情主动转交；转组选择“跟随本人”时 `owner_uid` 不变，选择“移交”或离职解绑时只能由标准数据移交接口原子更新。

#### 历史 7.9：策略、不变量与 T1 隐式协作

#### 已确认落地口径

1. 每条权限规则必须标记为系统不变量、分组级上限配置、账号级直接配置、组织所有者策略、对象级人工授权或套餐/系统约束，不默认把所有规则做成开关。
2. 系统不变量保证角色、对象身份、权限合并和安全底线可以稳定解释，组织所有者不能修改。
3. 除“T2 能否管理本组账号权限”和“T2 能否邀请本组成员”两个开关外，组织所有者是组织策略的唯一修改人；这两个委派开关允许所有 T1 修改，其他策略对超级管理员只读。
4. 组织策略按功能模块保存，所有分组共用，不在本版本支持逐分组差异化策略；策略保存粒度不等于协作授权粒度。跨境支付 `同组成员默认可查看支付单` 及其级联的 `同组 Viewer 可查看敏感信息` 只在 T1 管理侧统一设置，不开放 T2 逐组配置。
5. T1 隐式最高协作权限是组织所有者策略：账号已启用该模块时，开启策略后 T1 无需进入协作者列表，系统在访问每个具体项目、CRM 记录或支付单/草稿时实时授予查看、编辑和协作者管理权限；关闭后仅保留该对象的显式授权。
6. 具体 T1 账号始终可以被选为 Viewer/Editor；同时命中隐式和显式授权时按最高权限生效，降级后隐式权限失效但显式授权保留。
7. T1 隐式权限通过对象接口实时计算，不向模块或每个对象写入具体 T1 协作者账号，避免新增、降级 T1 时全量同步对象 ACL。
8. 修改组织策略必须展示影响模块和已有对象范围，二次确认并记录操作人、修改前后值和时间。
9. T1 数量上限属于套餐/系统约束，不由组织所有者自行配置具体数值。

#### T1 隐式权限说明文案

`根据组织权限设置，主账号和超级管理员无需加入协作者，也拥有该对象的查看、编辑及协作者管理权限。`

#### 验收护栏

- 同一对象上的隐式策略和显式协作不是两套互相覆盖的状态，最终统一进入权限合并器并取最高有效权限；账号模块未启用时两者均不生效。
- 组织策略关闭后不得继续通过 T1 角色兜底读取对象；对象列表、详情、编辑和 Dashboard 使用同一权限口径。
- 超级管理员尝试修改策略时，前端不可操作且后端返回无权限。
- 组织策略不能改变 Viewer/Editor/Owner 定义、多重授权取最高、硬限制优先等系统不变量。

#### 历史 7.10：对象接入范围与默认协作策略

#### 协作授权最小粒度

1. 模块级只保存账号准入和组织统一策略，不保存 Viewer/Editor 协作者名单，也不产生“可协作整个模块”的人工授权。
2. 邮件项目、网红资源夹/收藏夹和内容效果监控的显式协作授权绑定到具体项目；CRM 显式授权绑定具体记录；跨境支付显式授权绑定由稳定 `orderId` 标识的草稿/支付单生命周期。选择某个账号为协作者，只增加该账号对当前对象的权限。
3. T1/T2 的角色范围权限可以覆盖一批对象，但不是批量写入对象 ACL：系统访问每个对象时，根据当前 Owner、Owner 所属分组、账号等级和组织模块策略动态判断该账号是否命中角色范围。
4. 同一对象同时命中角色范围和显式 Viewer/Editor 时取最高有效权限；Owner 只能管理当前对象的显式协作者，不能通过协作者列表撤销 T1/T2 已经命中的角色范围权限。
5. CRM 的线上四项范围写权限迁入统一权限合并器：管理员项映射通用 T1 策略，T2/同组成员/全组织三项保留为 CRM 模块范围策略；显式 Viewer/Editor 仍只作用于当前记录。
6. 支付单与草稿共用一份对象 ACL，草稿转正式支付单不重新生成 Owner 或协作者；组织所有者可统一开启“同组成员默认 Viewer”，并通过级联子开关决定该范围 Viewer 是否获得 `can_view_sensitive_payment_info`；显式 Viewer 默认拥有敏感读取；频道历史收款账号作为组织共享主数据按频道检索，不继承来源支付单 ACL；支付资金模式和 `fundingUid` 按 D2 独立于对象协作权限处理。
7. 列表、详情、Dashboard 和写接口必须使用同一套逐对象鉴权口径，不得因账号已启用模块就默认读取模块内全部对象数据。

| 对象 | 优先级 | 本版本对象角色 | T1 组织策略 | 特殊边界 |
| --- | --- | --- | --- | --- |
| 邮件项目 | P0 | Owner / Editor / Viewer | 接入通用“T1 隐式最高协作权限”开关 | 现有 `email[12]` 迁移为实时策略，不再强制写入管理员账号 |
| 网红资源夹/收藏夹 | P0 | Owner / Editor / Viewer | 接入通用开关 | 项目范围随 Owner 当前主分组动态派生 |
| 内容效果监控 | P0 | Owner / Editor / Viewer | 接入通用开关 | 本版本需补齐与邮件项目一致的协作者管理与权限验收 |
| CRM 记录 | P0 | Owner / Editor / Viewer | 接入通用开关 | 线上管理员项迁为 T1 策略，其余三项迁为 CRM 范围策略；普通写权限真值等价；标签删除独立判断 |
| 跨境支付单/草稿 | P0 | Owner / Editor / Viewer；Editor 可附加 `can_execute_payment` | 接入通用开关 | 显式 Viewer 默认可读敏感信息；同组动态 Viewer 由级联开关决定敏感读取；历史收款账号全组织复用但不开放来源支付单；资金执行独立授权；资金模式固定 `shared` |
| 旧任务列表 | Backlog | 实现位于当前代码仓外，待单独确认 | 后续若启动再评估接入通用开关 | 新版智能营销计划不因已有 `memberUidList` 而搭车进入 |
| 消息中心单会话 | Backlog | 后续优先评估单一“跟进协作者” | 不接入默认管理员开关 | 本版本不新增会话 ACL、协作会话入口或跨项目发送授权 |

统一规则：邮件、资源夹、内容监控按项目，CRM 按记录，跨境支付按草稿/正式单贯通的 `orderId` 生命周期保存 Owner / Editor / Viewer。显式 ACL、T1/T2 范围策略和 CRM 迁移后的范围授权均进入同一权限合并器；模块级不保存人工协作者名单。

#### 共同操作与责任归属

1. 业务对象采用“唯一 Owner 负责制 + 有效写权限账号直接协作”，不设置共同 Owner，也不要求 Editor 的修改先交由 Owner 审批。
2. 权限来源不改变普通编辑语义：针对同一对象，通过 T1/T2 角色范围或对象 Editor 获得有效写权限的账号，执行同一普通编辑动作时使用同一套鉴权和保存流程。
3. 对象动作统一分为四类，具体模块动作清单在 spec 中展开：
   - 普通编辑：修改项目、记录、草稿或支付单的可编辑字段；Owner 和拥有有效写权限的账号可以执行。
   - 普通业务执行：发送邮件、启动监控等对外生效或消耗数据配额的动作；Owner 和拥有有效写权限的账号可以执行，但仍需校验操作者账号状态、模块、额度和业务前置条件。
   - 资金执行：立即/预约提交、人工审批或放行、手动触发、修改预约、转立即支付、取消/作废；Owner 和命中跨境支付 T1 隐式策略的 T1 天然可执行，Editor 仅在当前对象被授予 `can_execute_payment` 后可执行。系统到期自动执行消费已有效提交的预约指令，不视为某个用户在执行。
   - 对象治理：删除对象、转交 Owner、管理协作者；继续按已确认的独立高风险动作规则鉴权，不随普通写权限自动获得。支付草稿允许显式 Editor 删除，支付 Owner 转交仅来自标准数据移交流程，均为对象类型例外。
4. 普通编辑和业务执行不改变 `owner_uid`；对象归属、当前分组范围和 Dashboard 汇总继续跟随当前 Owner。
5. 每次写操作至少记录对象、当前 Owner、`actorType + actorUid`、动作和时间；数据配额消耗归实际操作人，支付 `fundingUid` 固定取资金承诺形成时的 Owner 快照。提交、审批、放行和手动触发的实际操作人不承担该笔支付额度；Owner 转交、协作者变化和系统自动执行也不改写既有资金归属。`can_execute_payment` 只决定能否发起动作，不决定额度记在谁名下。
6. 对象协作者列表只展示当前对象的显式 Viewer/Editor；因 T1/T2 范围策略获得访问的账号不自动进入列表，并通过权限来源说明解释。Owner 只能调整显式对象授权，不能撤销角色范围权限。
7. 本版本不新增共同 Owner、修改审批、项目内任务/子资源负责人、实时光标或在线状态；多人同时保存时沿用各模块当前冲突处理方式，spec 需逐模块核对但不得借机扩大为实时协作文档能力。

#### 历史 7.11：账号等级与账号直配权限分离

#### 已确认落地口径

1. 本版本不设置“CRM 运营”“邮件专员”等横向角色，不建设 Permission Set 或岗位权限模板。
2. `T1 / T2 / T3` 仅表达账号管理等级、管理范围和少数受保护管理动作，不作为功能模块和配额的权限聚合体。
3. 每个子账号按 `uid` 直接保存顶级功能模块的启用状态和账号数据配额；跨境支付另保存只读资金模式。修改账号等级不会自动替换这些配置，但正式组账号的模块和数据配额不得超过所属组上限。
4. 账号直配权限只做到顶级模块 `启用 / 禁用` 和数据配额数量，不做到账号级的模块内 `查看 / 编辑 / 删除` 动作矩阵；跨境支付的只读资金模式不是动作权限矩阵，支付单级 `can_execute_payment` 是对象协作附加能力，也不得提升为账号级动作配置。
5. 模块已启用后，系统必须针对当前项目、CRM 记录或支付单/草稿，继续合并账号等级、组织模块策略及该对象的 Owner/Editor/Viewer；不存在仅因加入模块协作者名单而获得模块内全部对象权限的路径。
6. 当前对象的有效业务权限按以下顺序判断：账号有效、企业套餐包含模块、所属组允许模块、账号已启用模块，之后再合并针对当前对象命中的等级/组织策略与显式对象授权；前四项硬限制不能被协作者身份绕过。隐藏分组的“所属组允许模块”直接继承组织上限。
7. 数据配额和支付资金限制均独立于模块可用性：数据配额为 `0` 只阻断需要消耗额度的动作，不隐藏模块或已有数据；支付 `shared` 仍受组织钱包余额约束；模块禁用则阻断列表、Dashboard、详情和对象授权访问。
8. T2 的“无权限”由账号模块未启用表达；模块已启用后，组织模块策略只负责本组 `查看 / 编辑`，不再维护第二个模块禁用开关。
9. CRM 线上四项写权限迁入统一权限模型并以组合真值表保证普通写权限结果等价；跨境支付加入账号模块准入、组织所有者统一控制的同组 Viewer 及级联敏感读取策略、支付单级 `can_execute_payment`、按频道检索的组织共享历史收款账号，并固定返回 `paymentFundMode=shared`。账号对应模块未启用时，CRM 范围授权、显式 ACL、T1 隐式权限、同组 Viewer、敏感读取、支付单协作、历史收款账号查询及资金执行授权均不生效。
10. 新增全局委派开关“T2 能否管理本组账号权限”，默认关闭；主账号和超级管理员均可修改，修改后立即对全组织所有分组生效。
11. 委派开关的修改必须记录操作人、T1 身份、修改前后值和时间；该例外不扩大超级管理员对其他组织策略的修改权限。
12. 每个正式分组允许 `0..1` 名 T2。无 T2 时由 T1 直管；组内存在 T2 且委派开关开启后，T2 可以修改自己和本组 T3 的账号模块与配额，但不能突破 T1 设置的组模块集合和组配额上限。
13. T1 的主流程是配置正式分组上限，而不是逐个维护正式组成员；T1 仍保留直接修改任何子账号的兜底和纠错能力。
14. 隐藏分组没有 T2，模块和配额上限继承组织上限，成员账号始终由 T1 直接管理。
15. 本版本配额采用逐层实际使用上限：`组织 limit/used -> 正式分组 limit/used -> 账号 limit/used`；隐藏分组不增加人工组上限，账号直接受组织上限约束。
16. 配置时只要求单个子级上限不超过父级上限，允许同层子级上限之和超过父级；实际消耗时逐层原子校验，任一层耗尽即阻断。
17. 账号可用额度展示为账号、分组、组织三层剩余的最小值，并可解释当前由哪一层形成限制；隐藏分组账号只取账号和组织两层。
18. 如未来切换为配额池，改为校验上限增加量不超过父级未分配余额，并另行制定存量超配配置的迁移规则。
19. 账号数据配额支持 `inherit / capped(limit)`：`inherit` 表示不设个人上限并继承父级共享额度，不代表绕过分组或组织上限；`capped` 表示增加账号个人上限。跨境支付资金模式不复用该枚举。
20. 第一版账号权限表单对数据配额采用账号级二选一：共享所属层级额度时全部数据配额项设为 `inherit`，设置个人上限时显式填写各项额度；跨境支付只读展示“不设账号个人上限，使用组织共享余额”，不能展示为真正“无限制”。
21. 引入新成员时必须显式填写并确认账号模块与数据配额；初始表单默认模块全关闭、数据配额为 `0`，不新增分组默认配置模板。跨境支付一旦启用，资金模式自动显示并锁定为 `shared`。
22. 所有邀请账号初始均为 T3。T1 可选择正式分组或不选组进入隐藏分组；T2 只能邀请 T3 到自己的正式分组。
23. 新增独立组织开关“T2 能否邀请本组成员”，默认关闭且允许所有 T1 修改；只有“T2 能否管理本组账号权限”已开启时才允许开启。
24. 关闭“T2 能否管理本组账号权限”时，同步关闭 T2 邀请开关；T2 邀请仍受组织席位和待接受邀请占位规则约束。
25. 批量邀请第一版使用同一份权限与配额配置应用到全部邮箱，提交前展示目标分组、账号数量和配置摘要，不支持逐行差异化配置。
26. 非邀请方式引入组织成员时也必须调用同一账号权限初始化契约，不允许绕过模块和配额初始化。
27. 新增组织所有者策略“成员可查看团队总体额度”：存量组织初始化为开启，新组织初始化为关闭；只有组织所有者可以修改，超级管理员只读。
28. 团队额度查看开关关闭时，T1 只接收组织范围汇总和明细，正式组 T2 只接收本组范围，T3 和隐藏组 T3 只接收自己；范围裁剪必须由配额接口服务端执行。
29. 团队额度查看开关不控制配额修改权限；T2 是否可修改自己和本组 T3 仍只由“T2 能否管理本组账号权限”决定。
30. 配额消耗提醒始终返回当前账号的有效剩余量和实际限制层级；共享额度只表达当前时点可用量，不承诺为当前账号保留。
31. 批量额度操作在现有固定上限流程之外独立增加“按当前个人上限增加”；只调整 `capped` 账号，跳过 `inherit` 账号，整批通过父级上限校验后原子提交，并同时提供提交前预览和操作后结果摘要。
32. 席位满邀请与验证提示已由现状实现，本版本不重复开发；但新的权限/配额邀请表单和 T2 邀请必须回归验证邀请前、提交时、接受时三段服务端席位校验，以及待接受邀请占位、撤销释放和 `40026` 明确提示。
33. 搜索隐藏筛选保留“已联系”现状，并为沟通中、合作中、合作完成分别增加 `我对接的 / 全团队对接的`；默认团队范围，不增加本组或指定成员，且团队范围只用于服务端排除结果，不返回 CRM 记录详情。
34. 配额页只在“当期使用”首屏、切换控件下方和汇总卡片上方突出展示后端实际返回的本期起止时间；不新增页面、周期推导、重置规则、历史月份或逐配额项周期能力。

#### 不进入本版本

- 不做可复用权限模板、权限集继承或模板变更后自动同步账号。
- 不做每个账号、每个模块、每个动作的完整权限矩阵。
- 不用“额度为 0”代替模块禁用，也不用模块开关代替额度分配；不把支付 `shared` 解释为账号无限支付。

#### 历史 7.12：存量账号无损迁移

> 状态说明：本节中的隐藏分组、唯一 T2 等旧初始化规则仍待按第 9.3 节统一重写；当前已确认的无感默认组初始化、原 ACL 保留和 Owner 名下项目迁移规则以第 9.3 节为准。

1. 存量账号不套用新成员“模块全关闭、配额为 0”的默认值；迁移目标是不收紧上线前的有效访问和可用额度。
2. 按迁移时每个账号的套餐、账号状态、现有主子账号限制和业务门禁计算当前有效模块快照，并写入首份账号模块配置；不能仅按组织套餐粗暴全开，也不能因新字段缺失默认全关。
3. 当前共享团队额度的账号迁移为 `inherit`；已有数值上限的账号迁移为 `capped(原上限)`；当前 `used`、周期和历史累计用量保持不变。
4. 正式分组初始模块上限设为组内成员当前有效模块的并集且不超过组织上限；初始组配额上限设为组织对应上限，保证新增组级边界不收紧现有账号。
5. 未归入正式分组的 T3 迁入隐藏分组；隐藏分组继续继承组织模块和配额上限。
6. 保留现有 `adminStatus=2` 作为分组 T2。无 T2 是允许状态；上线前由后端只核查同一正式分组存在多名 T2 的异常情况。系统不得自动猜测、晋升或降级账号，异常组织完成 T1 人工确认后再启用新委派流程。
7. 上线前已发出但尚未接受的邀请不视为存量账号；接受前必须由有权 T1/T2 补齐显式权限与配额配置。
8. CRM 四项写权限按 C3 的一对一关系迁入统一权限模型；迁移前必须生成组合真值表，失败时继续使用旧鉴权分支，不允许新旧分支同时生效或产生半迁移组织。
9. 存量账号按当前有效支付访问能力初始化跨境支付模块开关；资金模式统一写入 `paymentFundMode=shared`，不生成虚假的个人 `limit / pending / used` 历史。后端确认当前支付单真实可见范围后，再初始化同组 Viewer 策略；不得仅因新组织默认关闭而收窄存量有效访问。
10. 整体迁移按组织事务执行并记录迁移版本、账号数、模块快照、CRM 策略和配额映射结果；失败时不启用新权限计算，继续沿用旧口径，不产生半迁移组织。

#### 历史 7.13：成员转组/离职数据移交

> 状态说明：本节形成于旧账号根模型，其中 T1、唯一主分组、数据跟随本人和单一接收人的表述仍待按第 9.3 节统一重写；本轮新确认的退组状态机、权限失效时点和异步移交事务边界以第 9.3 节为准。

#### 已确认：全量统一处理

1. 成员转组和离职解绑的数据归属处理只允许 T1 操作，T2/T3 不能发起。
2. T1 操作成员转组时，只能在以下两种全局结果中二选一：
   - `全部数据跟随本人`：该成员负责的所有已接入 Owner 模型的业务对象保持原 `owner_uid`，并随成员新分组重算范围。
   - `全部数据移交`：该成员负责的所有已接入 Owner 模型的业务对象统一移交给同一个接收人。
3. 不按模块分别选择跟随或移交，也不支持逐对象选择；邮件项目、资源夹、内容监控、CRM 记录、跨境支付单/草稿等已接入对象使用同一次全局选择。
4. 离职解绑没有“数据跟随本人”选项；移出组织一经提交即不可撤销并立即使组织关系失效，全部归属对象仍必须统一移交给有效接收人，但允许在账号已失去组织身份后继续完成。
5. 跨境支付等模块只消费标准数据移交接口产生的 Owner 变更结果，不在模块内部提供主动转交入口。

已否决方案：按模块分别选择接收人，以及逐项目/逐记录选择接收人。本版本优先保证操作直接、结果统一，不建设离职资产盘点工作台。

#### 已确认：接收人资格与快捷补权

1. 单一接收人必须是当前组织内状态正常的已生效账号；待接受邀请、已冻结、正在离职解绑或已经解除组织关系的账号不能作为接收人。
2. 系统在提交前按待移交对象覆盖的模块预检查接收人：接收人账号必须启用全部相关模块，正式分组成员还必须满足所属组的模块上限；隐藏分组成员直接受组织模块上限约束。
3. 接收人缺少必要模块时，不直接判定移交失败，也不静默补权。系统必须列出缺失模块和将发生的权限变更，显式询问 T1 是否“开通缺失模块并继续”；T1 也可以返回更换接收人。
4. 若正式分组的模块上限已经包含该模块，只快捷开通接收人账号权限；若分组上限也缺失，则在同一次确认中明确提示并同时开通“分组模块上限 + 接收人账号模块权限”。提高分组上限只放宽组内可配置范围，不自动为其他组员开通账号权限。
5. 快捷开通不得突破组织套餐或组织模块上限；组织当前不具备的模块仍会阻断该接收人成为全量接收人，T1 需先升级套餐、调整组织能力或更换接收人。
6. 接收已有对象不要求接收人仍有新增数据配额，也不消耗一次新增额度；快捷流程不自动提高任何数据配额。移交完成后的新增、编辑、执行和额度消耗继续按各模块正常规则校验。

#### 已确认：移交对象覆盖范围

1. 标准数据移交只处理已接入 Owner 模型、且当前 `owner_uid` 为目标成员的业务对象：邮件项目、网红资源夹/收藏夹、内容效果监控项目、CRM 记录、跨境支付单/草稿。
2. 覆盖进行中、已完成、已暂停、已归档以及仍可恢复的软删除对象；永久删除且不可恢复的对象不参与移交。对象状态不能成为永久遗留待移交 Owner 的理由；`REMOVING` 期间允许暂存，但必须进入统一任务清单并阻塞关系进入 `REMOVED`。
3. 只更新根业务对象的 `owner_uid`。监控结果、CRM 跟进记录、支付明细等从属数据和关联关系继续挂在原业务对象下，随根对象获得新的访问范围，不逐条改写为接收人创建或操作。
4. 非 Owner 型组织共享数据不参与移交，包括组织与分组配置、账号模块与配额配置、共享标签及其创建来源快照、频道历史收款账号、组织汇总数据等；创建者离组或离开组织后仍按各自已确认的组织保留规则存在。
5. 历史事实字段和台账不得因 Owner 移交而改写，包括 `created_by`、`actorType + actorUid`、`fundingUid`、标签 `createdGroupId`、额度消耗记录、审计事件和资金记录。
6. CRM 自定义视图等仅有创建人/分享关系、尚未接入统一 Owner 模型的数据不混入本期标准移交；未来某类对象接入 Owner 模型时，必须显式注册到标准移交接口并补充模块级验收，不能因存在创建人字段自动纳入。

#### 已确认：Owner 变化后的 ACL 处理

1. 接收人统一成为每个移交对象的新 Owner；接收人若原本是该对象的显式 Viewer/Editor，移交时删除其旧 ACL 记录，以 Owner 身份提供权限，不允许同一账号同时保存 Owner 和协作者身份。
2. 原 Owner 不自动降级为 Editor，也不因曾经负责对象而保留显式 ACL；移交后只可能通过当前角色范围或后续重新获得的对象授权访问。离职解绑后账号硬限制继续使全部业务授权失效。
3. 除原 Owner 和新 Owner 外，账号状态与模块权限仍有效的显式 Viewer/Editor 默认保留，避免邮件、监控、CRM 和支付协作因 Owner 变化中断。
4. 被保留 Editor 已有的 `can_manage_collaborators`、`can_execute_payment` 随其对象 ACL 一并保留；这些能力是此前针对具体账号和对象的显式授权，不从原 Owner 继承，也不会因换 Owner 自动扩大或继续传递。
5. 最终提交摘要必须按模块展示保留的 Viewer/Editor 数量，并单独突出仍持有 `can_manage_collaborators`、`can_execute_payment` 的账号和对象数量；T1 的最终确认同时表示确认保留这些高风险授权。
6. T1/T2 角色范围、CRM 范围授权及支付同组 Viewer 等动态权限不写入或搬迁对象 ACL；Owner 变化后按新 Owner、其当前分组和最新组织策略实时重新计算。
7. 因新 Owner 或分组变化产生的跨主分组普通成员 ACL 不允许保留；具体清理规则按下节执行。

#### 已确认：不允许跨组协作和跨组转交

1. 普通成员只能成为同一主分组 Owner 所负责对象的显式 Viewer/Editor，也只能在同一主分组内接收 Owner；本版本不提供跨组协作或跨组转交能力，也不设置对应组织开关。
2. 正式分组以相同正式组 ID 判断同组；隐藏分组成员之间允许显式协作和 Owner 转交，但仍不产生 T2 管理范围、Dashboard 组范围或支付同组自动 Viewer。T1 是组织级账号，不归属某个分组，可以作为任一对象的显式协作者、Owner 或标准数据移交接收人。
3. 协作者选择器和 Owner 接收人选择器必须按上述范围过滤，后端使用同一规则拒绝跨组写入；T1 作为操作者也不能越过该规则把 A 组对象直接授权或转交给 B 组普通成员。
4. 成员转组选择“全部数据跟随本人”时，`owner_uid` 不变并随本人进入新组，不视为跨组转交；原显式协作者中属于 T1 或恰好仍与 Owner 同组的账号保留，其余普通成员 ACL 及附带的 `can_manage_collaborators`、`can_execute_payment` 在同一事务中清除。
5. 成员转组选择“全部数据移交”或执行离职解绑时，普通接收人必须与目标成员转组前/离职前的主分组相同，也可选择 T1；不能直接选择目标新分组或其他分组的普通成员。
6. 预检查和最终确认摘要必须展示因换组将被清除的 Viewer/Editor、附加能力及对象数量；T1 不接受清理结果时只能取消转组或改选“全部数据移交”及合法接收人。
7. 存量初始化时全部成员与项目先归入同一默认组，原 ACL 因而不构成跨组授权。后续执行 Owner 名下项目迁移时，协作者不属于目标组的 ACL 按第 9.3 节保留为禁用状态，不再采用直接清除的旧口径；账号被移出组织时仍永久清理其 ACL，不保留可因重新邀请而恢复的授权。

#### 已确认：执行完整性、摘要页与系统通知

现状补充：子账号页现有“操作记录”主要承载邀请记录，不是通用后台任务列表；聚星已有 `/notifications` 系统通知列表、未读状态和按消息类型跳转能力，但数据移交需要新增独立通知类型和目标页面。

1. 提交前先执行完整预检查，展示待处理对象总数及分模块数量、已选或待指定的接收人、快捷补开的模块权限、将清除的 ACL/附加能力和风险项。尚未指定接收人或仍有 Owner 型对象不阻止退组关系进入 `REMOVING`，但会阻止任务完成和关系进入 `REMOVED`。
2. 退组提交后创建唯一 `transferTaskId`，同一次操作只允许存在一个有效任务；任务期间锁定重复退组和相关对象 Owner 并发变更，重复提交必须返回已有任务。仅退组且组织关系仍有效时，恢复该组身份必须使用任务内的“撤销退组”，不能另建一条 GroupMembership 绕过状态机。
3. `ACTIVE -> REMOVING` 原子完成成员状态变化、组身份权限失效和任务创建。`REMOVING` 期间只允许预检查、盘点待处理对象、指定或更换接收人以及补齐接收条件，不改写任何对象 `ownerUid`，不永久删除 ACL、附加能力、模块配置或配额。
4. 仅退出当前组、账号仍保留有效组织关系且未进入组织移出流程时，原退组操作者权限范围内的 Owner/Admin 可以撤销。撤销原子完成 `REMOVING -> ACTIVE` 并将任务置为 `CANCELLED`；原有角色、模块配置、配额和 ACL 重新按撤销时的组织 Entitlement、组上限及其他当前规则计算生效，不承诺恢复已经被其他独立管理动作合法修改的配置。
5. 移出组织一经提交即不可撤销。直接移出组织时，账号立即失去组织身份及全部组内业务权限，并为其全部有效 GroupMembership 建立不可撤销的待移交任务；若某个 GroupMembership 已处于可撤销 `REMOVING`，则将该任务改为不可撤销并继续使用已有盘点结果，不先恢复为 `ACTIVE`。
6. 真正的 Owner 移交、ACL/附加能力与成员配置清理、`REMOVING -> REMOVED` 必须在最终完成事务中原子提交。任一对象或模块失败时回滚本次完成事务，关系继续停留在 `REMOVING`，全部对象 Owner 和待清理配置保持事务前状态，不保留部分移交结果。
7. 数据量和执行时间允许时可同步推进到 `REMOVED`；超过普通接口时限、尚未指定接收人或需要稍后处理时保留为后台任务。同步与异步只影响等待方式，不改变 `REMOVING` 已无组内权限、完成事务全量原子、幂等和审计规则。
8. 新增轻量数据移交摘要页，以稳定 `transferTaskId` 访问，不建设逐对象资产盘点工作台。页面展示成员关系状态、任务状态、是否可撤销、操作类型、目标成员、已选或待指定接收人、发起人、开始/完成时间、各模块待处理对象数量、补权结果和待清理 ACL 数量；待指定时提供“指定接收人”，条件齐备时提供“完成移交”，可撤销时提供“撤销退组”，执行失败时向仍有权的操作人提供“重试”。
9. 任务提交后直接进入该摘要页；后台执行期间页面可刷新状态。摘要页无需新增独立导航模块，完成或取消后可通过系统通知长期回到该页。
10. 移交任务至少区分 `WAITING_RECEIVER / READY_TO_COMPLETE / PROCESSING / ACTION_REQUIRED / CANCELLED / COMPLETED`。缺少接收人时进入 `WAITING_RECEIVER`；条件齐备且尚未提交最终事务时进入 `READY_TO_COMPLETE`；执行失败且已回滚时进入 `ACTION_REQUIRED`；撤销退组后进入 `CANCELLED`；只有最终事务成功并完成 `REMOVING -> REMOVED` 后才进入 `COMPLETED`。
11. 任务进入 `ACTION_REQUIRED`、`CANCELLED` 或 `COMPLETED` 时向发起人及当前仍有权处理该组的账号发送系统通知；通知必须包含目标成员、当前结果和更新时间，并通过 `transferTaskId` 深链到摘要页。同步完成的任务也发送通知，保证结果可追溯。
12. 同一执行轮次的同一状态只发送一次通知，以 `transferTaskId + attemptNo + status` 去重；失败后重试增加执行轮次，但仍在同一摘要页展示历史尝试和最新结果。
13. 每次预检查确认、任务创建、接收人变更、权限补开、撤销退组、组织移出锁定、Owner/ACL 变更、成员状态变更、完成事务回滚、重试和状态通知均记录操作人、任务 ID、前后值、时间和结果；摘要页是审计结果的用户可见摘要，不替代服务端审计记录。

</details>

## 8. 评审完成状态与验收规则

- 第 7.3 节已覆盖反馈池 23 项，并补入新根模型必需的 3 项 P0 基础能力；原始 42 条反馈仍保持“主子账号和权限 18 条、数据配额 8 条、数据导出 16 条”全量可追溯。
- 当前唯一根模型是组织 `Owner/Admin/Member` 与 `GroupMembership(T2/T3)` 解耦、账号可加入多组、项目固定归单组、全局组身份切换。第 9.1、9.2 及第 7.4-7.13 历史内容均为废案，不生成需求或验收。
- 协作授权最小粒度已确认：GroupMembership 只保存 T2/T3、可分配型 Scope 配置和关系状态，不保存独立模块启用开关；项目型根对象保存稳定 `groupId + ownerUid`，CRM 组属记录保存稳定 `groupId + nullable assigneeUid`，显式 Collaborator 和显式查看授权绑定具体对象；同组 T2 仅在组织策略开启时通过系统来源协作；组织 Owner/Admin 不天然获得对象明细权限。
- 对象共同操作规则已确认：项目型对象由唯一 Owner 负责，CRM 允许没有个人对接人；有效 Collaborator 执行模块常规业务读写，只读需求使用查看范围或显式查看授权，创建人只作历史记录；对象归属不随 Owner 或 Assignee 变化；数据配额按实际操作人和对象 `groupId` 归属。支付资金执行不从普通协作、T2 或组织管理身份推导。
- 每条规则归入系统不变量、组织/分组管理配置、GroupMembership 直接配置、组织策略、对象级人工授权或套餐/系统约束；这些类型的优先级为：套餐/账号/组关系等硬限制 > 对象与系统授权合并 > 组织管理与汇总视角。
- 已确认的 P0 和回归项构成当前版本不可裁剪范围；已确认纳入的 P1 是同一版本内的次优先候选，可在工作量不允许时裁剪，但必须显式记录原因和影响，后续 spec 不得静默删除或扩大任何已确认范围。
- Backlog 项不进入本版本 spec 和验收；重新启动时必须重新核对对象、接口和权限边界。
- `TODO` 不参与本版本验收，不因为研发“顺手能做”而自动进入。
- 频道历史收款账号的组织共享检索与复用属于已确认 P0；其新增版本、覆盖、停用和删除治理属于 TODO，两者不得捆绑阻塞。
- 成员退组/离职数据移交作为独立 P0：组关系与组织关系的失权状态、项目型 Owner 对象的同组单一接收人、CRM Assignee 独立影响清单与可选按组批量改派、ACL 清理作用域、可延后完成的摘要页和系统通知均为本版本验收范围；同时提供“整体移交给一个账号”快捷流程，支持组织内已有账号和新邀账号，并把原账号在受影响组内的 Owner、Assignee、有效显式 Collaborator、显式查看授权及附加能力统一替换给该接收人。每组未选择 CRM 接收人时，最终统一置为未分配。
- 最终验收用例只从第 5 节、第 7.3 节与第 9.3 节当前规则生成；不得从历史废案、TODO 或 Backlog 生成。

## 9. 当前方案、历史废案与待确认问题

1. **已确认事实**：现有后端没有满足目标字段的跨模块审计表或通用服务。本期不建设完整用户侧活动中心，但账号/组/权限/配额、支付分配与冲正、对象迁移和清退等高风险写动作必须新增最小统一审计事件。
2. 月度配额的「月」是自然月、会员周期月，还是合同锚点月？组织发放周期和组/成员分配控制周期是否允许不同？该问题属于 B2 待确认，不阻塞本版本 B1 周期字段展示，但需决定是否进入本版本配额契约。
3. 降级续约后超额子账号如何处理：立即冻结、到期冻结、限制核心能力，还是仅提醒？该问题属于 E2 TODO，不阻塞本版本。
4. **部分已确认，迁移待确认**：CRM 当前全组织可读，四项写权限真值已关闭；已确认 `ownerUser` 映射可空 `assigneeUid`，空值是合法未分配状态而非迁移错误；Assignee 天然治理记录协作。已有 Assignee 时，当前 Assignee 和同组 `ACTIVE T2` 都能指定新的同组 Assignee；未分配时仅同组 T2 可以分配，日常改派不能主动清空。普通 Collaborator 即使具备普通写或 `can_manage_collaborators` 也不能反向影响 Assignee，Owner/Admin 也不能凭组织身份或管理范围直接操作。无 `ACTIVE T2` 时必须先任命 T2。退组和组织移出中的按组批量改派或置为未分配属于独立生命周期清理例外。仍需选择权限 `1` 的组织管理员范围、权限 `2/3` 的旧 CRM 多分组、权限 `4` 的跨组范围如何迁移，并决定直接标签应用是否收敛到记录写权限。
5. **已确认**：草稿仅 Owner/Collaborator 可见，正式单对同组 `ACTIVE` 成员固定只读；默认组初始化保持存量正式单全组织读取和草稿创建人可见，当前正式单服务端全组织可写按鉴权缺口修复，不作为存量授权保留。
6. 邮件、资源夹和内容监控当前分别按实际操作人、项目 Owner 还是发送/执行账号扣减额度？目标规则已确认为由实际操作人承担账号额度，进入 spec 前需确认现状并记录兼容差异。
7. 是否单独开「数据导出与用量核对」专项 input？本文件已保留全部 16 条原始行号映射。
8. **待研发补充设计**：支付组级追加分配、账号上限、`fundingGroupId + fundingUid`、受控冲正和退款回补是问题包发出后新增的目标能力；进入 spec 前需补原子账本、幂等键、币种/手续费和退款事件契约。

### 9.1 历史废案 A：唯一所属组 + Admin 管理范围

状态：本方案在产品逻辑上成立，但未被选用。仅保留决策依据，不参与任何规则推导；当前方案见第 9.3 节。

#### 组织、账号与组织身份

1. 登录账号与组织成员关系分开建模。账号可以暂未加入组织；本期一个账号最多存在一个有效组织成员关系。
2. 一个组织拥有 `1..N` 个有效成员，并且任意时刻有且仅有一名组织所有者。
3. 组织身份分为 `Owner / Admin / Member`：Owner 恰好 `1` 名，Admin 为 `0..N` 名，其余为普通 Member。Owner 与 Admin 是不同身份，Owner 不需要重复占用 Admin 名额。
4. Owner 身份可以原子移交给另一名有效成员；移交前后均不得出现无 Owner 或多 Owner 状态。原 Owner 移交后的组织身份在操作时明确选择，默认建议降为 Admin。
5. 组织身份只决定组织管理能力，不直接授予具体业务对象的 Viewer、Editor、Owner 或高风险操作权限。

#### 唯一所属组与组内身份

1. 组织创建时自动创建一个默认组；组织始终至少保留一个组。
2. 所有有效成员，包括 Owner、Admin 和普通 Member，都有且仅有一个稳定的所属组 `homeGroupId`；本方案不保留未分组成员、隐藏分组或需要用户切换的「当前组」。
3. 分组允许先创建后分配成员，因此可以暂时没有成员。删除分组前必须先完成成员迁移；最后一个默认组不得删除。
4. T2/T3 仅表达成员在其所属组内的业务身份：T2 是组内负责人，T3 是组员。T2 只能管理自己的所属组，不能以 T2 身份跨组管理。
5. 每组允许 `0..1` 还是 `0..N` 名 T2 不由 A/B/C 管理场景倒推，留待按真实共同负责需求单独确认；无论最终数量为何，T2 都必须是该组成员。
6. 对象不单独保存项目组或「当前组」；对象的组归属继续由当前 Owner 的 `homeGroupId` 动态派生。Owner 转组时的数据跟随或移交仍走标准数据移交流程。

#### Admin 管理范围

1. Owner 的组织管理范围固定为全组织。Admin 在任命或编辑时必须配置管理范围，支持「指定一个或多个组」或「全部组」；多个 Admin 的管理范围允许重叠。
2. Admin 管理范围不改变其 `homeGroupId`、T2/T3 组内身份或对象归属，也不把 Admin 写入所管理分组的成员列表、负责人列表或对象 ACL。
3. Admin 是以组织授权身份管理非所属组，不是这些组的 T2。分组成员列表中的组内负责人和有权管理本组的 Owner/Admin 必须分开表达，避免把组织管理范围误解为组内身份。
4. 「全部组」应作为可持续覆盖未来新建组的范围类型保存，不能只展开为配置当时已有的 `groupId` 列表。

#### 汇总查看与业务权限边界

1. 查看组织或分组的聚合业绩、成员数量、用量和配额属于管理行为，不属于具体业务对象读取。
2. Owner 可以查看全组织总览及各组汇总；Admin 可以查看其管理范围内各组的分别汇总与合并汇总；T2 可以查看所属组汇总。
3. 汇总查看不得自动授予构成汇总的项目、CRM 记录、支付单或其他明细对象读取权限，也不得提供可绕过对象权限反查明细的入口。
4. Admin 在业务权限层面仍受账号状态、账号模块准入、所属组、T2/T3 组内身份、对象 Owner/Viewer/Editor ACL 和高风险动作规则共同限制。
5. Admin 管理范围只作为管理权限的作用范围，不自动产生 Viewer、Editor、Owner、`can_manage_collaborators` 或 `can_execute_payment`。
6. Admin 需要参与某个具体业务对象时，仍通过其所属组内的角色权限或合法的对象级显式协作获得权限；不能仅凭管理范围打开或编辑所辖组成员的全部业务明细。

#### 典型账号解释

| 账号 | 组织身份 | 所属组与组内身份 | Admin 管理范围 | 默认结果 |
| --- | --- | --- | --- | --- |
| A 营销负责人 | Admin | 默认组或营销管理组，T2/T3 | 营销一组、营销二组 | 查看两组分别/合并汇总，执行被授予的组管理动作；不自动读取两组具体业务对象 |
| B 公司老板 | Owner | 默认组，T2/T3 | 全组织固定范围 | 查看全组织及各组汇总并管理组织；具体业务对象仍按业务权限计算 |
| C 营销一组负责人 | Member | 营销一组，T2 | 无 Admin 范围 | 通过 T2 身份管理和查看所属组允许的业务范围 |
| D 营销一组执行成员 | Member | 营销一组，T3 | 无 | 使用账号模块权限、自身 Owner 权限和对象协作权限 |

#### 方案 A 后续仍需确认

1. Admin 管理范围内的固定管理动作清单：查看汇总、成员管理、组配额、组级设置和模块级治理分别如何授权。
2. 每组 T2 的数量是 `0..1` 还是 `0..N`，以及无 T2 时由谁承担组内日常管理。
3. Admin 是否允许查看全组织汇总但只管理部分组；默认建议汇总范围等于管理范围，特殊需求再独立授权。
4. 默认组在只有一个组的小团队中如何弱化展示，不让普通成员感知无必要的组织概念。
5. 与方案 B 在对象归属、跨组参与、权限解释、邀请/转组流程、存量迁移和实现成本上的差异。

### 9.2 历史废案 B：HubSpot 式主组 + 参与组 + Admin 管理范围

状态：本方案逻辑成立但已封存，不作为当前根模型、迁移目标或后续规则推导依据。仅当第 9.3 节当前方案因事实或实现约束无法成立、且团队明确重开根模型决策时，才重新启用本节讨论；当前选定方向见第 9.3 节。

方案说明：HubSpot `Main team + Extra teams` 的结构分工不引入嵌套组或需要用户持续切换的「当前组」。每个成员保留唯一稳定业务归属，同时可以参与多个组；组织管理范围继续与业务参与关系分开。

#### 三类独立关系

| 关系 | 基数 | 回答的问题 | 不承担的职责 |
| --- | --- | --- | --- |
| 所属组 `Main Group` | 每个有效成员恰好 `1` 个 | 账号及其 Owner 型业务归属于哪里 | 不表达跨组管理或额外协作 |
| 参与组 `Extra Groups` | 每个有效成员 `0..N` 个 | 账号还参与哪些团队的业务 | 不承担业绩、配额、路由和组内管理归属 |
| Admin 管理范围 | Owner 固定全部组；Admin 为指定 `1..N` 个组或全部组 | 账号能管理和查看汇总哪些组 | 不自动授予具体业务对象权限 |

三类关系互不替代：账号可以只参与某组但不管理该组，也可以管理某组但不参与该组；加入参与组或获得 Admin 范围都不改变账号的所属组。

#### 所属组与组内身份

1. 组织创建时自动创建默认组，并始终至少保留一个组；所有 Owner、Admin 和普通 Member 都必须有且仅有一个所属组 `mainGroupId`。
2. T2/T3 只在所属组内定义：T2 是所属组内负责人，T3 是所属组成员。账号不能以 T2 身份跨组管理，也不在参与组内重复获得 T2/T3 身份。
3. 每组允许 `0..1` 还是 `0..N` 名 T2 仍按真实共同负责需求另行确认，但 T2 必须以该组为所属组。
4. 账号自己创建并成为 Owner 的项目、CRM 记录、支付单等业务对象，默认归属于 Owner 的所属组；本期不要求用户选择当前组，也不为对象新增可手工切换的项目组字段。
5. 账号业绩、账号配额、组级配额占用、默认路由和组级报表只归集到账号所属组。参与多个组不得导致同一账号、同一对象或同一消耗被重复统计。
6. Owner 所属组变化继续通过成员转组/离职数据移交流程处理；不能通过调整参与组关系改变已有对象归属。

#### 参与组

1. 账号可以加入 `0..N` 个参与组；参与组与所属组不能重复保存，所属组变化时需要重新校验参与组列表并去重。
2. 参与组成员统一显示为「参与成员」，不在该组成为 T2/T3，不计入该组的直属成员业绩、账号配额、默认路由、轮转或组内负责人数量。
3. 参与组提供该组业务对象的动态 Viewer 范围，但不自动产生 Editor、Owner 或任何高风险附加能力。动态 Viewer 逐对象计算，不批量写入对象 ACL。
4. 参与组成员需要编辑具体对象时，仍由合法的 Owner/T1 按对象显式授予 Editor；`can_manage_collaborators`、`can_execute_payment` 等附加能力继续按既有非传递规则单独授予。
5. 参与组关系使账号成为该组对象的合法协作者候选，不再视为跨组协作；没有共同所属组/参与组关系的普通成员仍不得跨组协作或接收 Owner。
6. 模块未向账号启用、账号失效、套餐限制和其他硬限制优先于参与组 Viewer。参与组不能用于绕过账号模块准入、支付门禁或组织套餐。
7. 参与组 Viewer 是否可读取跨境支付敏感信息，继续受支付模块的独立敏感读取策略约束；Viewer 身份本身不授予支付执行。
8. 退出参与组后，动态 Viewer 立即失效；重新加入参与组只重新获得当前动态 Viewer，不恢复历史显式 ACL 或附加能力。

#### 参与组维护与 ACL 清理

1. Owner 可以设置所有有效成员的所属组和参与组。拥有对应成员/分组管理能力的 Admin，可以按与所属组设置相同的权限检查，在其管理范围内添加或移除参与组关系；多个 Admin 管理范围重叠时，任一有权 Admin 均可操作。本期不向 T2 开放参与组维护。
2. 参与组关系变化不需要组内 T2 同意，但必须校验操作者权限、目标成员状态、目标组状态、账号模块硬限制和并发配置版本。
3. 账号的合法业务参与组集合为 `mainGroupId + extraGroupIds`；对象归属组仍由对象 Owner 的 `mainGroupId` 派生。参与组变化后，服务端按变更后的完整集合重新校验该账号全部显式 ACL，不按单个被移除组名盲删。
4. 如果账号仍通过所属组或其他合法参与组满足对象协作范围，保留其显式 ACL；如果对象归属组已不在账号合法业务参与组集合内，永久删除该对象上的 Viewer/Editor，以及随该 ACL 保存的 `can_manage_collaborators`、`can_execute_payment` 等附加能力。
5. 删除参与组前必须预检查并展示影响摘要：将失效的动态 Viewer 范围、将删除的显式 Viewer/Editor 数量、涉及对象和模块数量，以及将收回的附加能力数量。存在显式 ACL 或附加能力时必须二次确认；没有显式 ACL 时可直接提交。
6. 参与组关系变化、动态范围失效和非法 ACL 清理必须全量成功或全量失败。数据量较小时同步原子提交；超过普通接口时限时复用标准后台任务和锁定机制，但不能先提交组关系、再留下待异步清理的非法 ACL。
7. 重新加入参与组只恢复当前规则产生的动态 Viewer。此前被删除的 Editor、`can_manage_collaborators`、`can_execute_payment` 不自动恢复，需要有权账号重新按对象显式授权。
8. ACL 清理只影响之后的访问和操作，不删除或改写历史评论、跟进记录、`actorUid`、审计记录、额度消耗、支付 `fundingUid` 和已经形成的资金承诺，也不删除成员创建的组织共享标签等非 ACL 数据。
9. 已经预约或提交的支付不因参与组退出撤销既有资金承诺；账号失去有效 ACL 后不能继续修改、取消、放行或执行新的支付动作，除非重新获得合法权限。
10. 每次参与组新增、移除、预检查确认、ACL 删除、失败回滚和最终结果必须记录操作者、目标成员、目标组、对象与 ACL 前后值、附加能力、时间和结果；完成后向目标成员发送系统通知，存在 ACL 清理时同时向操作者展示结果摘要。

#### Admin 管理范围

1. Owner 的管理范围固定为全组织。Admin 在任命或编辑时配置指定组或全部组，多个 Admin 的管理范围允许重叠。
2. Owner 可以查看全组织及各组汇总；Admin 可以查看管理范围内各组的分别汇总与合并汇总。汇总查看属于管理行为，不授予构成汇总的对象明细访问权。
3. Admin 在管理范围内可执行哪些成员、配额、组设置和模块治理动作，由后续固定管理动作清单决定；管理范围只限制动作对象，不扩大动作种类。
4. Admin 的业务权限仍由账号状态、模块准入、所属组 T2/T3、参与组动态 Viewer、对象 Owner/Viewer/Editor ACL 和高风险动作规则计算。Admin 管理范围本身不产生 Viewer、Editor、Owner 或附加能力。
5. 分组界面必须分开展示直属 T2/T3、参与成员和有权管理该组的 Owner/Admin，不能将三种权限来源合并成同一成员角色。

#### 典型账号解释

| 账号 | 组织身份 | 所属组 | 参与组 | Admin 管理范围 | 默认结果 |
| --- | --- | --- | --- | --- | --- |
| A 营销负责人 | Admin | 营销管理组，T2/T3 | 营销一组、营销二组 | 营销一组、营销二组 | 汇总来自 Admin 范围；两组业务 Viewer 来自参与组；具体编辑来自对象 ACL；自身成果归营销管理组 |
| B 公司老板 | Owner | 默认组，T2/T3 | 按实际业务参与需要配置 | 全组织固定范围 | 查看全组织及各组汇总；是否参与具体业务与参与组/对象 ACL 分开计算 |
| C 营销一组负责人 | Member | 营销一组，T2 | 可选其他参与组 | 无 | 组内管理来自所属组 T2；额外业务查看来自参与组 |
| D 营销一组执行成员 | Member | 营销一组，T3 | 无 | 无 | 使用账号模块权限、自身 Owner 权限和对象协作权限 |

#### 根模型确认后的待补规则

1. 每组 T2 是 `0..1` 还是 `0..N`；无 T2 时由范围内 Admin 还是 Owner 承担组内日常管理。
2. Admin 管理范围的固定动作清单，以及哪些动作只能由 Owner 执行。
3. 存量隐藏分组、现有 `adminStatus=2`、旧跨组 ACL 和账号配额如何迁移到 `mainGroupId + extraGroupIds + adminScope`。
4. 各 P0 模块的动态参与组 Viewer 是否都能从现有 Owner/创建人事实稳定计算；不能稳定计算的对象不得仅靠前端筛选模拟权限。

### 9.3 已确认根模型：多组成员 + 单组项目 + 全局组身份切换

决策结论：不采用唯一所属组或主组/参与组模型。组织成员可以同时属于 `1..N` 个组；每个项目型业务对象必须直接归属于且仅归属于一个组；业务协作、Owner 转交和对象访问严格限制在项目所属组内，不支持跨组协作。多组成员通过全局「组身份切换」进入明确的业务上下文，不使用隐式主组或持续猜测对象归属。

#### 核心实体与基数

| 实体/关系 | 基数 | 作用 |
| --- | --- | --- |
| 组织成员关系 | 每个账号本期最多 `0..1` 个有效组织关系 | 承载 `Owner / Admin / Member` 组织身份 |
| 组成员关系 `GroupMembership` | 每个有效组织成员常态有 `1..N` 个 `ACTIVE`；退组过渡期允许暂时没有 `ACTIVE`，但保留 `REMOVING` 关系 | 承载账号在具体组内的 T2/T3、可分配型 Scope 配额和退组状态 |
| 组内身份 | 每组 `0..N` 名 T2、`0..N` 名 T3 | 允许多人共同负责；无 T2 或组织的组长默认协作开关关闭时，不产生 T2 系统协作者来源 |
| Admin 管理范围 | Owner 固定全部组；Admin 为指定 `1..N` 个组或全部组 | 承载组级管理动作和汇总查看，不产生业务对象权限 |
| 项目型业务对象 | 每个对象恰好一个 `groupId` 和一个 `ownerUid` | `groupId` 决定业务归属，`ownerUid` 决定个人责任 |
| 组属业务记录（CRM） | 每条记录恰好一个 `groupId`，可有 `0..1` 个 `assigneeUid` | `groupId` 决定业务归属；`assigneeUid` 只表达可空的个人对接责任，不承担项目 Owner 语义 |
| 对象授权 | 每个对象 `0..N` 个 Collaborator；按需存在显式查看授权和附加能力来源 | 只允许授予对象所属组的有效成员；只读查看对象不进入协作者列表 |

1. 组织创建时自动创建默认组；所有正常参与业务的有效成员必须至少拥有一个 `ACTIVE` 组成员关系。退组过渡期可暂时没有 `ACTIVE` 组，此时账号仍可保留组织身份和组织级管理能力，但不能进入任何需要组身份的业务上下文。组可以先创建后添加成员，因此允许暂时为空；每组允许 `0..N` 名 T2，不设置唯一组长限制。
2. 同一账号在不同组拥有独立的 GroupMembership，可以在 A 组为 T2、在 B 组为 T3；角色只在当前对象或当前组上下文内解释，不设置账号级全局 T2/T3。
3. T2/T3 和可分配型 Scope 的 `inherit / capped` 都保存到 `uid + groupId` 的组成员关系，不再按账号保存一份跨组共享配置；不可分配 Scope 随组织 Entitlement 生效，不保存组/成员数值配置；本版本不设置独立模块启用/禁用字段。
4. Owner/Admin 组织身份与组成员身份分开。Owner/Admin 想查看或操作某组业务明细，也必须是该组有效成员并满足该组业务权限；Admin 管理范围只提供管理动作和汇总数据。
5. 组织成员关系自身也必须有 `ACTIVE -> REMOVING -> REMOVED`，或等价的持久离职聚合态。组织移出提交后立即进入 `REMOVING`、失去全部组织及组内有效权限，并不再占用有效成员席位；关系记录保留用于承接移交任务，全部 GroupMembership 任务完成后才进入 `REMOVED` 并完成数据清理。组织 Owner 必须先完成所有权转让，不能直接进入组织移出。

#### 全局组身份切换

1. 【UI交互】多组成员在全站业务区使用统一的「当前组」切换控件。当前组决定当前展示的 T2/T3 身份、业务列表范围、可分配型 Scope 配额和新建对象默认 `groupId`；无业务对象的搜索、榜单、详情等 Scope 动作也以经服务端验证的当前组作为新增用量归属。可分配额度为 `0` 只影响相应消耗型业务动作，不直接撤销对象读取或已有 ACL。
2. 账号只属于一个组时不要求主动选择，可弱化或隐藏切换控件；账号属于多个组时，当前组必须持续可见，不能只在首次进入时提示。
3. 【UI交互】新建项目时使用当前组作为对象 `groupId`，创建表单必须显式展示归属组。需要为其他组创建时先切换组；本期不在同一创建表单内再提供第二套独立组选择器。
4. 切组不是权限授予。只能切换到账号拥有有效 GroupMembership 且账号状态正常的组；服务端仍按请求携带的 `groupId` 和对象真实 `groupId` 鉴权。可分配型 Scope 的有效可用量为 `0` 只影响相应消耗型业务动作，不阻断对象读取或已有 ACL。
5. 当前组不得只保存为全账号共享的服务端 Session 权限状态。每个页面路由或业务请求必须显式携带 `groupId`，服务端逐次校验；客户端可保存最近使用组作为下次进入默认值，但不同浏览器标签页切组不得互相串改正在进行的业务上下文。
6. 【UI交互】【UI反馈】从通知、收藏或外部链接打开其他组对象时，系统先展示目标组并要求显式切换；不能静默切换后直接执行写操作。仅查看跳转是否允许自动切换留到 design/spec 决定，但服务端始终使用对象真实组鉴权。
7. 【UI反馈】存在未保存表单、上传、批量选择或其他进行中操作时，切组必须提示影响并由用户确认；切换后所有候选人、业务配额和对象数据按新组重新加载，不能复用旧组缓存提交。
8. 组织设置、Admin 管理页、全组织汇总、账单和组织钱包等组织级页面不依赖当前业务组。进入某组管理明细时使用明确的管理目标组，不把 Admin 管理范围误解为当前业务身份。

#### 业务对象归属、Owner / Assignee 与协作边界

1. 邮件项目、资源夹/收藏夹、内容监控项目、CRM 记录、跨境支付单/草稿等接入对象都必须保存稳定 `groupId`；其从属记录继承根对象组，不逐条重复选择。项目型对象另外保存唯一 `ownerUid`；CRM 记录保存可空 `assigneeUid`，不强制建立项目 Owner。
2. `groupId` 负责业绩、组级配额、业务范围和组级汇总。项目型对象的 `ownerUid` 负责日常责任、通知、协作者管理和需要个人承担的业务动作，项目归组不能替代唯一 Owner；CRM 的 `assigneeUid` 负责对接责任、对应的普通写权限来源和 CRM 记录协作治理，但不天然获得项目 Owner 的治理动作，记录归属也不由 Assignee 所在组反推。
3. 常态下项目 Owner 必须是对象所属组的 `ACTIVE` 成员；CRM Assignee 非空时必须是记录组内 `ACTIVE` 成员。Collaborator 和显式查看对象也必须是同一组 `ACTIVE` 成员。对象授权不因可分配型 Scope 的有效可用量为 `0` 自动撤销，但需要消耗配额的动作必须另行通过对应 Scope 规则校验。唯一过渡例外是：退组成员进入 `REMOVING` 后，既有项目型对象的 `ownerUid` 可以暂时继续指向该账号，用于标识尚未完成的移交责任，但不再提供任何业务权限。CRM 记录不因 Assignee 为空进入 `OWNER_UNRESOLVED` 或同类异常态。组织身份、Admin 管理范围、`REMOVING` 关系或另一个组的成员关系都不能绕过组边界。
4. T2 身份产生的组级治理与汇总范围只作用于其当前 GroupMembership 对应的组，不直接授予项目明细权限。账号在其他组是 T3 时，切换到其他组后按 T3、Owner、对象 ACL 和当前组织策略重新计算；同组项目读写仍须命中本节第 6 项开关产生的系统来源或其他对象授权。
5. 不存在跨组 Collaborator、跨组显式查看授权、跨组 Owner 转交或跨组协作者候选。两个账号即使还共同属于其他组，也必须同时是当前对象 `groupId` 的有效成员，才能在该对象上获得授权。
6. 【UI交互】【UI反馈】组织级“组长默认成为组内所有项目协作者”开关默认关闭。开启后，同组 T2 通过系统来源获得组内项目常规业务读写，替代旧 Admin 强制协作和 T1 隐式业务权限。系统动态计算当前组内的全部 ACTIVE T2，并在协作者列表中以锁定来源显式展示；无需向每个对象持久写入账号 ACL，项目 Owner 不能手动移除系统来源。关闭后该来源立即失效；可分配型 Scope 的有效可用量为 `0` 时不撤销来源，但不能完成相应消耗型业务动作。
7. T2 系统协作是组织策略控制的独立授权来源：开关开启或成员升为 T2 时对该组既有项目即时生效；开关关闭、成员降为 T3 或进入 `REMOVING` 时立即停用该来源，最终进入 `REMOVED` 时永久清理相关缓存/索引。账号在同一项目上另有显式 Collaborator、显式查看授权或附加能力时，移除 T2 系统来源不能误删这些来源。T2 系统来源不自动获得 `can_manage_collaborators`、`can_execute_payment` 等附加能力；若同一账号另有显式能力来源，两个来源分别保留并合并正向能力。
8. 普通编辑不能修改 `groupId`。本版本只在账号加入目标组时，由有权 Owner/Admin 发起该账号名下项目整批迁移；每个批次严格限定为 `ownerUid + sourceGroupId -> targetGroupId`，不得读取、修改或重新归属来源组内其他 Owner 的对象。CRM 记录不因 Assignee 进组或换组自动迁移；其组间迁移只进入未来「合并组」或 CRM 专项能力。按项目多选迁移留作后续能力。
9. 以下 Owner 转交规则只适用于项目型对象，不适用于 CRM Assignee 变更。Owner 转交只能在项目所属组内完成，不改变 `groupId`。Owner 退组不要求在提交退组时当场完成转交；成员先进入 `REMOVING`，其 Owner 型对象留在原组并进入待移交状态，之后再由有权账号指定同组新 Owner。
10. Owner 转交时，在同一事务中更新对象 `ownerUid`，并清理新 Owner 在该对象上的显式 Collaborator、显式查看授权及其附加能力记录；这些低级对象授权由 Owner 权限完整覆盖，不允许同一账号同时保留有效 Owner 与显式协作者身份。其他账号的对象授权、对象 `groupId`、不可变 `createdBy` 和历史数据均不改写，清理内容进入审计记录而不是可恢复 ACL。
11. 新 Owner 同时是同组 T2 且组长默认协作策略开启时，仍会命中动态 T2 系统来源；该来源不持久写入对象 ACL，权限计算和界面均只呈现 Owner，不视为重复显式授权。新 Owner 以后再次转交时，不因本次已经清理的旧 Collaborator 记录自动恢复访问。
12. 【UI交互】【UI反馈】Owner 主动转交时提供“转交后将我设为协作者”选项，默认不勾选；只有原 Owner 显式勾选并确认，系统才在同一事务中为其新建一条不带附加能力的普通 Collaborator 记录。未勾选时不生成原 Owner 的显式对象授权，但其另行命中的动态 T2、查看范围等独立来源仍按统一权限计算生效，确认界面需说明转交后的实际访问结果。该快捷选项只用于有效 Owner 主动转交，不适用于退组/离职数据移交或禁止主动转交的跨境支付对象。
13. Owner 主动转交不要求新 Owner 接受，不设置待接受、双 Owner 或临时无 Owner 状态。原 Owner 二次确认后，服务端在提交事务中重新校验操作者仍是当前 Owner、新 Owner 仍为对象组内 `ACTIVE` 成员，并同步完成 `ownerUid` 与本节约定的对象授权调整；任一校验或写入失败时整次不生效。成功后立即通知新 Owner，并向原 Owner 返回明确结果。

#### 存量组织无感初始化

1. 本版本不设置用户侧迁移过渡期。新规则上线时，存量组织无需先完成分组配置或手工归档历史项目；不执行任何主动操作，也必须可以继续原有业务。该过程原则上不新增用户迁移页面；若后台初始化失败，需在组织管理侧提供异常状态和处理提示。
2. 技术上仍按组织执行原子初始化：创建一个真实默认组，将全部有效组织成员初始化为该组 `ACTIVE` 成员，并为已接入的存量项目型根对象补写默认组 `groupId`；CRM 记录必须在同一原子切换中按最终选定的旧分组迁移方案写入稳定 `groupId`，不能在方案未定时一律压入默认组。任一步失败时不得启用新鉴权，不能产生部分成员或部分对象已进入新模型的半迁移组织。
3. 默认组遵守真实组的完整业务、配额、ACL 和删除规则，不是虚拟「未分组」或特殊兼容空间。组织 Owner 初始化为默认组 T2；原 `adminStatus=2` 也迁为默认组 T2，其他成员迁为默认组 T3；组织 Admin 身份单独保留，不因此自动迁为 T2。
4. 原项目型对象 `ownerUid`、显式协作者和既有附加能力原样保留，成员和对象都在同一默认组内，因此一般协作关系继续有效。存量协作者统一映射为 Collaborator，保持升级前可执行的常规业务动作，不要求用户重新配置。CRM `ownerUser` 映射为可空 `assigneeUid`；空值保持「未分配」，不得为了满足统一模型补造 Owner。CRM 旧分组范围和支付正式单/草稿可见范围必须按下述模块专项迁移，不能仅靠默认组保证无损。组长默认协作开关对新组织和存量组织均初始化为关闭，因此项目 Owner、CRM Assignee 或原组长迁为默认组 T2 不会在上线瞬间新增系统协作来源；后续主动开启才形成可预览、可审计的权限扩展。
5. 默认组的可分配型 Scope 配置初始化为 `inherit` 组织当前有效上限；已有子账号数值上限按迁移时服务端真值写入默认组 GroupMembership 的 `capped(原上限)`，原本使用团队共享额度的账号迁为 `inherit`。不可分配 Scope 继续随组织 Entitlement，不生成虚假数值配置。支付金额的组织层上限直接读取组织钱包当前可用余额；默认组初始化为使用组织未分配共享余额，不生成虚假的历史组分配记录，账号支付上限默认 `unlimited`。历史用量、`createdBy`、`actorUid`、支付 `fundingUid`、审计和资金承诺不因补写 `groupId` 改写。
6. 默认组初始化只是上线兼容基线，不要求历史项目永久留在默认组。组织后续创建真实业务组并添加成员时，可使用下述 Owner 名下项目迁移能力逐步形成真实分组结构。
7. 研发确认现有 CRM 同组权限读取旧单组关系。若组织当前存在多个 CRM 组，直接压入一个默认组会扩大同组写范围；CRM 是否保留旧组映射或使用可迁移范围授权，必须先决策，未决前默认组初始化不能标为整体迁移已闭环。
8. 研发确认正式支付单当前全组织可读、草稿仅创建人可读。存量正式单可按独立迁移查看来源维持原范围，草稿必须保持 Owner/既有明确授权可见；最终形式待产品确认，禁止统一开启同组查看而扩大历史草稿。

#### 账号进组与 Owner 名下项目迁移

1. 【UI交互】Owner/Admin 将账号加入目标组时，可以从该账号已有的任意 `ACTIVE` 来源组中选择是否迁移其 Owner 型对象。每个迁移批次只处理 `ownerUid` 等于该账号且 `groupId` 等于所选 `sourceGroupId` 的全部已接入对象，统一改为 `targetGroupId`；服务端不得触及该来源组内其他 Owner 的对象。
2. 【UI交互】【UI反馈】若账号当前只属于默认组，加入新组时必须主动询问是否将其在默认组名下的全部项目迁移到新组；默认不得静默迁移。若不迁移，只新增目标组 GroupMembership，来源组身份、原项目 `groupId`、Owner 和 ACL 均保持不变，该账号在新组中暂时没有名下项目。
3. 本版本的「整批」粒度固定为一个 Owner 在一个来源组内的全部项目型对象。同一账号存在多个来源组时，每个来源组分别选择和生成迁移批次；不支持项目多选，也不能把整个来源组的所有项目迁走。
4. CRM 记录不是账号名下的 Owner 型对象，不进入上述进组整批迁移。Assignee 加入其他组或切换当前组不改变 CRM 记录 `groupId`；CRM 记录改组留给「合并组」或 CRM 专项迁移能力。
5. 【UI反馈】迁移前必须确认目标 GroupMembership 已生效，且 Owner 在目标组已显式确认待迁移对象涉及的可分配型 Scope 配额；缺失时在进组流程中按默认 `inherit` 补齐或改为允许范围内的 `capped`。不可分配 Scope 只校验组织 Entitlement，不要求生成组/成员配置。不能让项目迁移后出现 Owner 不是目标组有效成员的状态；可分配额度为 `0` 不使对象 ACL 失效，但相应消耗型动作需等额度恢复后执行。
6. 项目迁移时逐项检查显式 Collaborator、显式查看授权和附加能力来源。授权对象不是目标组 `ACTIVE` 成员时，不删除该授权，而是将整条授权快照标记为禁用；禁用期间协作者常规读写、只读查看和 `can_manage_collaborators`、`can_execute_payment` 等附加能力均不生效。该成员之后加入目标组且满足账号状态、对象组关系和支付准入等当前硬门槛时，按原授权快照自动恢复原有授权，不新增其禁用前没有的能力；可分配型 Scope 的有效可用量为 `0` 只阻断消耗型动作。
7. 【UI交互】【UI反馈】有权账号可以对禁用 ACL 执行显式删除，操作前必须二次确认将永久失去自动恢复资格；删除后即使该成员以后进组也不自动恢复，且成员未进组前不再出现在该项目的可选协作者列表中。旧来源组的 T2 系统协作来源随项目迁出移除；只有组长默认协作开关开启时，目标组才按当前 `ACTIVE T2` 重新生成系统来源，该来源不进入可自动恢复的禁用 ACL。
8. 本版本由有权 Owner/Admin 在进组流程中发起 Owner 名下项目整批迁移。未来允许项目 Owner 选择部分名下项目迁移到自己已加入的其他组，但不进入本版本；入口、批量选择、影响预览与二次确认在后续专项设计。
9. 项目迁移只改变当前归属和之后的权限、统计与配额作用域，不改写历史 `actorUid`、历史额度消耗、支付 `fundingUid`、审计事件或已经形成的资金承诺。迁移后的新操作按目标组计入。
10. 成员加入目标组本身先独立成功，项目迁移是可追踪批次：按提交时对象快照逐对象原子迁移，成功项保留，失败项留在来源组并可重试，不回滚已建立的目标 GroupMembership。发起迁移的 Admin 必须同时管理来源组和目标组；Owner 拥有全组织管理范围。

#### 模块权限与配额

1. 【UI反馈】本版本不设置独立模块启用/禁用字段。普通业务动作必须先满足 `组织 Entitlement AND GroupMembership ACTIVE`，再按 Scope 类型执行门禁、窗口、频率、容量、解锁或消耗规则；只有可分配型 Scope 继续校验组和 GroupMembership 上限。不可分配 Scope 本期随组织权益继承，不能通过“额度为 0”针对成员关闭；业务入口可保留，但在执行前说明缺少的组织权益、组身份或可分配额度。
2. 可分配型 Scope 按 `组织当前有效上限 -> 对象所属组或 currentGroupId 的组上限 -> 实际操作人在该组的 GroupMembership 上限` 逐层校验；每项 Scope 的团队/账号计量、去重、周期和返还规则继续以服务端 Scope 矩阵为准。一个账号在多个组分别配置可分配上限，不使用一份跨组共享个人额度。不可分配 Scope 不进入这条三级数值链路。
3. 新产生的 Scope 使用、占用或解锁事件必须记录实际 `actorUid` 和归属 `groupId`：对象型动作取对象稳定 `groupId`，无对象动作取经服务端验证的 `currentGroupId`。操作 A 组上下文只影响 A 组及该账号在 A 组的可分配上限，不影响其在 B 组的配置；团队去重 Scope 的后续复用不重复计入。支付预约提交继续独立形成 `pending`，归属 `fundingUid + fundingGroupId`，同时占用对应组剩余金额和账号上限，审批/放行人不承担额度。
4. Owner、审批人、提交人和实际操作人的责任规则保持原有分离；跨境支付 `fundingUid` 仍按形成资金承诺时的 Owner 快照，不因组身份切换改写。组织钱包余额是支付金额的硬上限；已分配组不能突破本组剩余金额，共享组不能使用其他组已承诺的余额，账号 `unlimited` 也不能绕过组织或组层约束。
5. 【UI反馈】当前组切换后，配额页和用量提示必须展示该账号在目标组的可分配 Scope 配置和有意义的剩余/占用结果；不可分配 Scope 只显示“随组织权益”和当前可用原因，不伪造剩余量。支付金额展示组织钱包、组织未分配余额、组累计分配/已支付/占用/剩余和账号上限；全组织汇总另走 Owner/Admin 管理视图。

#### GroupMembership 变化

1. 【UI交互】移除 GroupMembership 是组织管理动作，只能由组织 Owner 或具备成员/分组管理能力的 Admin 发起和推进；T2 不得发起退组、指定接收人、撤销、完成或重试退组任务。Owner 可以维护所有成员的组成员关系；Admin 当前按管理范围维护。会议提出移除 Admin 分组管理范围和 T2 邀请例外，两项在替代路径确认前仍按正文基线处理。
2. 新增 GroupMembership 时必须显式配置该账号在目标组的 T2/T3，并确认可分配型 Scope 默认 `inherit` 或改为 `capped`；不能直接复制其他组配置，也不能留下缺失身份或可分配模式的半成品状态。不可分配 Scope 只读展示“随组织权益”，不要求保存组/成员配置；同时只读展示目标组当前支付资金状态，账号支付上限默认 `unlimited`，允许在当前组与组织资金约束内改为具体金额。
3. `GroupMembership` 至少包含 `ACTIVE -> REMOVING -> REMOVED` 三态。只有 `ACTIVE` 是有效业务组身份；`REMOVING` 是对该账号已经退组、但尚未最终移交资产和清理关系的过渡状态，不是仍可工作的锁定态。任务同时记录 `exitScope=GROUP | ORGANIZATION`：仅退组且组织关系仍有效时可撤销，移出组织一经提交即不可撤销。
4. 【UI反馈】移除前必须预检查该成员在该组负责的项目型 Owner 对象、CRM Assignee 记录、显式 Collaborator、显式查看授权、附加能力、进行中支付或后台任务、业务配额状态。项目型 Owner 对象进入必处理移交清单；CRM Assignee 记录只进入独立影响清单，不进入强制唯一 Owner 或同一接收人规则。预检查用于生成待移交清单和暴露风险，不以「尚未指定新 Owner」或「仍有 Owner 型对象」为理由阻止进入 `REMOVING`；已有并发成员变更或有效移交任务时应阻止重复创建并返回当前任务。
5. 【UI交互】【UI反馈】Owner/Admin 提交退组后，系统在同一事务中把关系从 `ACTIVE` 改为 `REMOVING`、立即撤销该组身份的有效权限并创建可追踪的移交任务；不能从 `ACTIVE` 直接物理删除关系。接收人可以在提交时选择，也可以稍后补充或更换。后续移交失败不会自动把关系回滚为 `ACTIVE`，但仅退组任务可由有权账号主动撤销。仅退组任务即使没有待移交对象或待清理授权，也必须先停留在 `REMOVING`，等待有权账号选择「撤销退组」或「确认完成退组」；不可撤销的组织移出任务在没有待处理项时可以自动完成到 `REMOVED`。进入 `REMOVING` 不得调用现有 `/ws/userRelation/setAdmin status=2 -> evict` 分支，因为该分支会立即转移资产、删除关系并改写部分创建人。
6. 进入 `REMOVING` 后，该账号立即从可切换组、组内候选人和有效成员范围中排除；其 T2/T3、账号配额、T2 系统协作来源、项目 Owner、CRM Assignee、Collaborator、显式查看授权及附加能力均不得再用于该组任何读写或执行鉴权。`REMOVING` 期间不改写对象 `ownerUid` 或 CRM `assigneeUid`，不永久删除对象授权、附加能力或配额配置；这些数据被冻结并仅作为最终完成事务的输入。
7. 该成员原 Owner 项目继续留在原组，不能随成员迁往其他组；`ownerUid` 在移交前作为「待移交责任人」暂存，不再代表有效 Owner 权限。项目上其他 `ACTIVE` 同组协作者仍按自身有效授权工作；必须由有效 Owner 完成的专属动作，在指定新 Owner 前暂停。
8. 【UI交互】【UI反馈】只有组织 Owner，或管理范围覆盖该组且具备成员/分组管理能力的 Admin，可以指定接收人、撤销仅退组任务、完成或重试移交；T2 不具备这些权限。同一次 GroupMembership 退组的全部项目型 Owner 对象必须统一移交给一个同组 `ACTIVE` 接收人，不允许按模块或对象拆分。接收人必须具备待接对象涉及业务动作所需的配额；Owner/Admin 可在组上限内快捷补权，不要求额外增加数据额度，也不能突破组织/组上限。CRM Assignee 记录不纳入项目型对象的强制接收人约束：影响清单按记录所属组汇总，操作者可以为每个受影响组另选 `0..1` 名同组 `ACTIVE` CRM 接收人；选择后批量改派该成员在该组负责的全部 CRM 记录，未选择则接受这些记录变为未分配。全局移出组织时各组独立选择。该能力只属于退组/组织移出任务的数据清理，不授予 Owner/Admin 日常设置或改派 CRM Assignee 的业务权限。
9. 从 `REMOVING` 完成到 `REMOVED` 时，项目 Owner 移交、CRM Assignee 按组批量改派或置为 `null`、该账号对原组对象的 Collaborator、显式查看授权与附加能力清理、T2 系统来源失效、配额配置清理，以及 GroupMembership 状态变化必须形成一个产品语义上的全量原子事务。任一项失败即回滚本次事务，不保留部分对象移交结果。CRM 允许 `assigneeUid=null`，因此未选择接收人不得阻塞任务完成，也不得把记录误判为无 Owner 异常；`REMOVING` 期间仍保留原 `assigneeUid`，仅在最终事务中改写，因此可撤销退组不需要逆向恢复。其他有效协作者不因项目 Owner 移交被清除。因其他项目迁入别组而处于禁用状态的对象授权不属于本次退组清理范围。最终事务也不能直接复用现有 `evict` 的“统一转给团队管理员并改写 creator”逻辑，必须按已选择的同组接收人写项目型对象的目标 `ownerUid`，保留不可变 `createdBy`；现有模块副作用需逐项拆分、替换或明确废弃。
10. 【UI交互】【UI反馈】仅退出当前组、账号仍有有效组织关系且未进入组织移出流程时，可以在最终完成事务开始前撤销。撤销原子完成 `REMOVING -> ACTIVE` 并取消任务；由于 `REMOVING` 期间没有资产移交或永久权限清理，原 `ownerUid`、ACL、角色、配额无需逆向恢复，只需重新按撤销时的组织 Entitlement、组上限和账号状态计算有效权限。
11. 直接移出组织时，组织成员关系先进入不可撤销 `REMOVING`，立即失去全部组织与组内业务权限并释放有效成员席位；其所有尚未处理的 GroupMembership 进入不可撤销 `REMOVING`。若账号先在某组进入可撤销 `REMOVING`，之后又被移出组织，则该组任务转为不可撤销。多组账号按组分别选择一个同组接收人；全部组任务完成后，永久清理该账号在组织内所有活动及禁用 ACL，组织关系才进入 `REMOVED`。
12. 退组不影响账号在其他组的 `ACTIVE` GroupMembership、项目 Owner 对象、CRM Assignee 关系、ACL 或配额。只有进入 `REMOVED` 后再次加入原组，才必须新建 GroupMembership 并显式配置角色和配额，不恢复已清理的历史 ACL、附加能力或 Assignee 关系；撤销 `REMOVING` 不属于重新加入。
13. 历史 `createdBy`、`actorUid`、审计事件、额度消耗、支付 `fundingUid` 和已经形成的资金承诺不因退组改写；预约支付等已形成的系统任务可继续按既有承诺执行，但 `REMOVING` 或已移出组织的账号不得再提交、放行或修改。
14. 本节状态机覆盖第 7.13 节原「成员关系与资产移交必须同一事务完成」的旧口径：组身份先在 `ACTIVE -> REMOVING` 时失效，资产和关系清理只在最终 `REMOVING -> REMOVED` 事务中发生。
15. 仅退组且会导致账号没有其他 `ACTIVE` 组时，可以进入 `REMOVING`，但不能最终进入 GroupMembership `REMOVED`；必须先加入另一个真实组，或把任务升级为不可撤销的组织移出。组织 Owner 不适用组织移出，必须保留至少一个 `ACTIVE` 组。
16. 【UI交互】【UI反馈】在逐组配置接收人的标准流程之外，提供“整体移交给一个账号”快捷入口。单组退组时覆盖该组，全组织移出时覆盖原账号全部受影响组；操作者只选择一个接收账号，系统将其预填为所有组和全部可移交对象关系的统一接收人。快捷流程只是对现有按组移交任务的编排，不建立第二套资产迁移模型；需要例外分配时返回标准逐组流程处理。
17. 【UI交互】接收人可以是组织内已有账号，也可以是在该流程中输入邮箱新邀请的账号。已有账号缺少某个受影响组时，操作者在确认页直接补建该组 GroupMembership；新账号只发送一次组织邀请，并携带全部待创建 GroupMembership 配置。未接受邀请前不创建有效对象 Owner、Assignee 或 ACL，整体任务进入 `WAITING_FOR_TARGET`；原账号仍按既定语义立即进入 `REMOVING` 并失权。新账号接受后，系统先原子创建组织成员关系和全部已确认的 GroupMembership，再启动各组移交；邀请失效或长期未接受时，Owner/Admin 可以更换接收人或重发邀请。仅退组但原账号仍留在组织时，新账号占用新增组织席位，席位不足必须在提交 `REMOVING` 前阻断；全组织移出并替换为新账号时，原账号进入组织级 `REMOVING` 所释放的一个席位由该移交任务临时保留，目标账号接受邀请时消耗该保留席位，避免接受阶段再次因席位已满失败。更换为组织内已有接收人或任务不再需要新账号时释放保留席位。
18. 【UI交互】【UI反馈】每条待补 GroupMembership 必须显式确认 T2/T3、可分配型 Scope 的 `inherit / capped` 和支付账号上限；默认使用 T3、可分配 Scope `inherit`、支付账号上限 `unlimited`，不能直接复制原账号配置。原账号是某组最后一个 `ACTIVE T2` 时，页面强提醒并提供一键将接收人设为 T2 或另选 T2；由于每组允许 `0..N T2`，操作者也可以显式确认该组暂时无 T2。组织 Owner/Admin 身份、Admin 管理范围和其他组织级权限不随整体移交自动继承。
19. 整体移交必须以任务快照为准，把原账号在受影响组内的全部有效业务关系替换给接收人：项目型对象写入新的 `ownerUid`；CRM 记录写入新的 `assigneeUid`；原账号作为显式 Collaborator、显式查看对象及其 ACL 绑定附加能力的关系按原能力复制给接收人后删除原关系。接收人已有同对象授权时去重并合并正向能力；接收人成为 Owner/Assignee 后不得保留同对象重复的普通 Collaborator/显式查看身份。禁用 ACL、T2 系统协作、模块策略范围等非有效或系统派生来源不复制，后续按接收人的 GroupMembership 和组织策略重新计算。
20. 整体移交不改写或转移历史 `createdBy`、`actorUid`、审计记录、Scope 历史用量、已形成支付承诺的 `fundingUid + fundingGroupId`、组级配额和支付资金账本。接收人的账号配额与支付上限使用第 18 项显式配置；获得 Collaborator 或 `can_execute_payment` 等对象能力后仍须通过自身 GroupMembership、配额和资金硬限制。
21. 已有接收账号且所有 GroupMembership 已就绪时可以立即执行；新邀账号必须等待接受。全组织整体移交按组执行原子事务并允许失败组独立重试，已完成组不因其他组失败回滚；原账号的组织关系只有在全部组移交、对象关系替换和清理完成后才进入 `REMOVED`。任务页必须展示各组对象数量、待补身份/配额、邀请状态、执行进度、失败原因、重试结果和最终摘要，并在完成时发送系统通知。

#### 分组冻结归档与合并边界

1. 分组允许没有成员，支持先建空组后再配置成员；空组本身不是异常状态。
2. 分组不提供彻底删除。管理动作统一为“冻结并归档”，保留稳定 `groupId`、所有归组业务对象、成员关系历史、责任快照、后台任务引用、配额/支付账本、统计口径和审计记录；无成员空组也使用同一归档语义，不通过物理删除制造引用失效。
3. 【UI交互】【UI反馈】归档前展示影响清单，但业务对象、进行中任务、资金承诺、未回收支付余额和 `REMOVING` GroupMembership 不再作为归档阻断条件。归档组不能成为当前组，不能创建新对象、建立新的 `ACTIVE` GroupMembership 或发起普通业务写动作；已形成的预约支付、退款、冲正和其他系统责任仍按原 `groupId`、`fundingUid`、账本与状态机继续，不因归档被取消或转移。
4. 业务非空组允许没有 `ACTIVE` 成员并直接归档。项目型对象可以暂时保留指向 `REMOVING` 原 Owner 的待移交责任，CRM 允许 `assigneeUid=null`；这些“孤悬”状态不生成业务权限。归档后 Owner/Admin 仍可在管理视角查看影响与历史，并继续推进已有 `REMOVING -> REMOVED` 清理任务；是否允许解除归档并重新开展业务留到 Spec 前确认。
5. 「合并组」升级为显式待确认：若需要把旧组业务继续迁入目标组，必须统一处理对象 `groupId`、Owner/Assignee、ACL、组配额、支付资金、成员关系、统计和审计，不能用归档或单账号项目迁移模拟。是否进入本版本需单独决策。

#### 典型账号解释

| 账号 | 组织身份 | 组成员关系 | Admin 管理范围 | 默认结果 |
| --- | --- | --- | --- | --- |
| A 营销负责人 | Admin | 营销一组 T2、营销二组 T2/T3 | 营销一组、营销二组 | 可管理两组汇总；切换组后按该组身份、业务配额和对象 ACL 参与业务 |
| B 公司老板 | Owner | 按实际需要加入默认组及其他组 | 全组织固定范围 | 查看全组织汇总；只有加入某组并切换后才访问该组业务明细 |
| C 营销一组负责人 | Member | 营销一组 T2 | 无 | 查看营销一组汇总；项目明细按组长默认协作开关或其他对象授权计算，不访问其他组对象 |
| D 营销一组执行成员 | Member | 营销一组 T3 | 无 | 使用营销一组账号权限、自身 Owner 权限和对象 ACL |

#### 当前待处理项与后置专题

1. **已确认：组长默认协作策略**。组织级全局开关“组长默认成为组内所有项目协作者”默认关闭；开启后所有同组 `ACTIVE T2` 通过锁定系统来源成为普通 Collaborator，获得常规业务读写；关闭时只撤销系统来源。T2 不自动获得 `can_manage_collaborators`、`can_execute_payment` 或模块高风险治理动作。对象协作者不再区分 Viewer/Editor。
2. **进入 Spec 前的必要迁移收口**。研发已确认 CRM 四项写权限、全组织读范围、支付真实鉴权与清退副作用，但结论证明默认组不能机械覆盖全部模块。CRM 已明确使用可空 Assignee，不要求补齐项目 Owner；Assignee 天然治理协作，已有 Assignee 时由当前 Assignee 或同组 `ACTIVE T2` 指定新 Assignee，未分配时仅 T2 可分配，日常不能主动清空；普通 Collaborator 和 Owner/Admin 无日常改派权；离组采用可选按组批量改派、未选则置为未分配。仍需确认权限 `1/2/3/4` 的旧范围。另需确认支付缺失创建人、邮件 `email[12]`、其他 P0 项目型根对象 Owner/ACL，并按已确认的 Scope 存量迁移原则完成逐 Scope 可归属性扫描；不能稳定补齐 `groupId`，或项目型对象不能稳定补齐 Owner 时，必须给出明确兜底或暂缓接入名单。
3. **后置专题：Admin 动作矩阵**。待各模块的对象、常规动作、高风险动作和既有线上权限全部梳理完成后，再统一形成 Owner-only、Owner+Admin、按管理范围 Admin、T2 可委派四档矩阵。其中必须单列“修改组长默认协作策略”的组织级动作：Owner 固定可修改，Admin 是否可修改及是否要求全组织管理范围待矩阵确认，T2/T3 不可修改。该矩阵不阻塞当前 Input 继续确认其他问题；当前只锁定管理范围授予管理与汇总能力，不自动授予业务对象明细权限。
4. **2026-08-20 会议建议裁剪，尚未生效**：①移除“每个 Admin 可管理 `0..N` 个组”；②移除“多个 Admin 管理范围可重叠”；③移除 T2 邀请当前组 T3；④邀请时不再显式选择首组；⑤不建设通用只读访问；⑥Owner 转交不提供“转交后成为 Collaborator”勾选项。第一、二项若确认，Admin 默认是全组织管理还是缩小为少数动作需与 Admin 动作矩阵一起锁定；第四项若确认，必须在“邀请只建组织成员、后续再入组”与“自动加入默认组”之间选择，否则会与成员常态 `1..N` 个 `ACTIVE` GroupMembership 冲突；第五项当前仅能理解为裁掉通用显式只读授权框架，不能同时删除 CRM 线上读范围、资源夹公开/部分可见和支付正式单同组只读等模块既有或已确认行为；第六项若确认，原 Owner 转交后固定不新增 Collaborator，仍可通过其他独立来源获得权限。
5. **新增待确认：月度配额的双周期模型**。套餐权益/组织额度的发放周期与组/成员的分配控制周期分开。企业年付月发直接继承服务端月度窗口；年度组织额度上的月度下级分配建议作为不预占年度额度的子周期上限。周期锚点、结转、中途调整和是否进入本版本仍未锁定。
6. **新增待确认：组合并是否进入本版本**。冻结归档已可以承接带遗留数据和 `REMOVING` 关系的组关闭，但不能满足“旧部门业务继续并入新部门”。需在生命周期 Spec 前决定只做归档，还是增加最小组合并。

以下不再是根模型决策，只进入 spec/design：`REMOVING` 长期任务的提醒频率与升级机制、项目迁移批次的页面交互、只读深链切组方式。退最后一个 `ACTIVE` 组已锁定为“可进入 REMOVING，但加入另一真实组或转组织移出前不得最终完成”。

#### 当前方案 UI 交互与复杂度初评

以下清单只评估 Input 阶段的产品交互复杂度，不是研发工时估算。`低` 表示可复用现有页面上的字段、筛选或确认弹窗；`中` 表示需要跨列表/表单/详情的统一状态；`高` 表示涉及跨页面上下文、异步任务、权限即时变化或资产迁移。

| 优先级 | 交互域 | 必须在界面体现的操作和状态 | 初步入口建议 | Input 复杂度 |
| --- | --- | --- | --- | --- |
| P0 | 全局当前组 | 切换当前组；持续显示当前组；创建对象时显示归属组；深链打开其他组时确认切换；未保存表单切组前告警；切组后重载候选人、配额和列表 | 复用全站 Header/业务壳层，只提供一个全局切换控件；业务页面不重复放第二个组选择器 | 高 |
| P0 | 组织成员、组和管理范围 | 新建空组、改名、冻结归档影响预览；归档状态和历史入口；成员加入/移出组；`ACTIVE / REMOVING / REMOVED`；T2/T3；Admin 管理范围是否保留待会议收口 | 复用 `/brand/sub-account` 成员页，增加“组关系/管理范围”侧栏或抽屉；归档组进入独立筛选，不新建大而全的权限中心 | 中 |
| P0 | 邀请与首个 GroupMembership | 邮箱邀请；首个组；T2/T3；可分配型 Scope 默认 `inherit` 或设置 `capped`；不可分配 Scope“随组织权益”只读摘要；目标组支付资金状态与账号支付上限；提交前摘要；席位不足保留输入并给出原因 | 扩展现有添加成员弹窗为分步或分区表单；最终确认页统一展示身份、可配置配额、继承权益、支付上限和席位占用 | 中 |
| P0 | 类型化 Scope 与组成员配额 | Scope 类型/可分配性说明；可分配型 Scope 的组与账号 `inherit / capped`；不可分配 Scope 只读展示；支付组级追加分配、分配记录、组织未分配余额、账号支付上限和受控冲正；保存前超用提示；批量增加预览、阻止、成功摘要 | 复用 `/brand/sub-account/quota`，增加当前组上下文、GroupMembership 视图和独立支付资金区；不做逐模块启用开关，也不把支付资金伪装成普通 Scope | 高 |
| P0 | 额度可见性 | `成员可查看团队总体额度` 开关；Owner/Admin/T2/T3 对应范围的汇总/明细；个人实际可用量和耗尽层级提示 | 继续放在配额页和现有策略入口；服务端裁剪结果，前端不承担权限隐藏 | 低-中 |
| P0 | 成员/协作者/标签搜索 | 成员邮箱/昵称搜索；对象协作者搜索；候选人仅显示对象所属组 `ACTIVE` 成员；消息标签“我创建的/当前组成员创建的/全部”；搜索范围筛选 | 复用现有列表筛选和 `cooperatorSelect`；统一搜索参数，不新增账号选择中心 | 低 |
| P0 | 对象协作与查看授权 | “组长默认成为组内所有项目协作者”全局开关、影响预览和结果摘要；协作者列表；显式 Collaborator；开关开启时锁定的 T2 系统来源和授权解释；Owner 授权 `can_manage_collaborators`；Owner 同组转交及默认关闭的“转交后将我设为协作者”；只读查看范围不进入协作者列表；禁用对象授权恢复/永久删除确认 | 开关放组织策略区，Admin 编辑权接动作矩阵；对象侧复用现有协作者/项目设置入口，增加授权来源、Owner 转交确认和结果状态；不要把系统 T2 伪装成普通可删除勾选项 | 中 |
| P0 | CRM 兼容迁移 | 保留线上四项写权限设置；Assignee 管理 Collaborator/显式查看和 `can_manage_collaborators`；已有 Assignee 时，当前 Assignee 和同组 `ACTIVE T2` 共用“改派给新 Assignee”动作，未分配时仅 T2 可分配，不提供日常清空；普通 Collaborator 和 Owner/Admin 不显示日常改派入口；无有效 T2 时提示先任命组长；离场清理单独按组批量处理；标签删除入口、影响范围、二次确认；统一 ACL 生效/无权限提示 | CRM 继续使用现有列表/详情和数据管理页；T2 分工清单只显示必要标识，不开放完整明细；迁移真值和后端权限合并复杂度高 | 中（UI中，整体高） |
| P1 | 内容监控标签治理 | 全局“是否只有 T2 才能增删编辑标签”开关；T3 的定义动作隐藏/禁用；标签应用入口保持可用 | 复用内容监控现有标签管理入口，在组织策略/数据管理页增加一个开关和权限提示 | 低 |
| P0 | 跨境支付协作与资金校验 | 正式单同组固定只读、同组敏感信息开关；显式 Collaborator；`can_execute_payment` 授权；草稿删除确认；支付提交/手动放行前显示权限、钱包余额、组剩余和账号上限拦截原因；按网红账号选择全组织历史收款人 | 复用支付列表、支付单/草稿详情和已有支付弹窗；敏感信息开关放组织管理侧；组分配/冲正和账号上限统一复用配额管理入口 | 高 |
| P0 | 进组与 Owner 项目整批迁移 | 选择来源组；是否迁移该账号名下全部项目；目标配额缺失提示/快捷补齐；ACL 禁用说明；批次进度、失败项、重试和完成摘要 | 作为“加入组”流程中的第二步/侧栏任务，不做独立项目搬运中心；只处理当前账号 Owner 项目 | 高 |
| P0 | 退组、组织移出与数据移交 | 影响预检查；标准逐组接收人配置；“整体移交给一个账号”快捷入口；选择已有账号或输入邮箱邀请新账号；席位校验或替换席位保留；缺失 GroupMembership 的 T2/T3、配额和支付上限确认；`WAITING_FOR_TARGET`、`REMOVING`；Owner、Assignee、有效显式 Collaborator/查看授权/附加能力替换；邀请状态、按组进度、失败重试、摘要和通知；组织移出不可撤销确认 | 成员详情进入移交任务页；整体移交作为标准逐组任务的快捷编排；新账号复用邀请表单和接受流程；不开放给 T2 | 高 |
| P0 | 存量默认组初始化 | 正常上线不要求用户操作；组织侧只在初始化失败时展示异常状态、影响范围和处理提示 | 后台原子初始化；不设计迁移向导作为上线前置流程 | 无用户流程（异常低） |
| P1 | 周期与搜索范围展示 | 配额当前周期首屏展示；搜索“我对接的/全团队对接的”选择 | 复用现有配额页和搜索筛选控件 | 低 |
| TODO | 支付单组长审核放行 | 组级开关；立即/定时/手动三种闸门；`待我放行`；预约逾期；通知中心跨组汇集 | 后续版本独立进入支付状态机 spec；本版本不预埋页面入口 | 高 |
| 待确认 | 会议建议裁剪 | Admin 管理范围、T2 邀请、邀请首组、通用只读授权、Owner 转交后保留 Collaborator 的入口是否整体移除，以及各自替代路径 | 不继续细化这些入口，先完成产品决策和兼容范围确认 | 中-高 |
| 待确认 | 月度下级分配 | 组织发放周期与组/成员控制周期、年度父额度上的月度上限、重置锚点、结转和中途调整 | 仍复用配额页；只有纳入本版本后才增加逐 Scope 周期配置 | 高 |
| 待确认 | 组合并 | 源组、目标组、对象、成员、配额、资金和审计整体迁移；与冻结归档的边界 | 若本期不做，只保留归档入口；不得用单账号迁组模拟 | 高 |
| TODO | 暂不新增交互 | 数据导出、会话级跨项目协作、自定义角色/完整动作矩阵、全量审计中心 | 保留为后续专项，不在本版本页面中预留复杂入口 | 不评估 |

**初步落地建议：**

1. 先建设 5 个共享交互原语：全局当前组切换、组/成员选择器、配额模式与有效剩余量提示、协作者授权来源展示、异步操作结果摘要/通知。它们会被多个模块复用，优先级高于单独美化某个模块页面。
2. 页面入口保持收敛：成员/组/组织策略主要落在子账号页，配额落在现有配额页，CRM/内容监控策略落在现有数据管理页，协作落在现有项目协作者弹窗，支付沿用现有支付列表和支付弹窗。
3. 不在 Input 阶段承诺“完整权限矩阵页面”。本期只要能让用户完成组关系、具体配额、对象协作者和策略开关的配置，并能解释最终权限来源即可；动作矩阵在 spec 中按模块展开。
4. 高复杂度的进组迁移和退组移交必须按任务型流程设计，不能压缩成一个确认弹窗；两者应共用任务状态、进度、失败重试、结果摘要和通知机制。
5. 交互验收至少覆盖五类负面状态：无 `ACTIVE` 组身份、组织缺少不可分配 Scope 权益、可分配型 Scope 在组织/组/账号层耗尽、ACL 被禁用、钱包余额不足。按钮隐藏或禁用只改善体验，不能替代服务端拦截。

## 10. 后续动作

1. 以第 7.3 节 26 项范围索引和第 9.3 节根模型为唯一基线；第 7.4-7.13、9.1、9.2 均只保留历史废案，不再校正或复用。
2. 可开关的 T2 系统协作者、项目型对象 Owner/Collaborator、CRM 组属记录 Assignee/Collaborator、“类型化 Scope + 可分配子集”及 Scope 存量迁移原则已确认；研发问题包已关闭 CRM/支付/清退/审计的主要现状真值。支付生命周期以及 CRM Assignee 的协作治理、日常分配/改派主体、离组/组织移出处理已收口；下一步确认 CRM 旧权限范围与标签应用，并补 CRM 空 Assignee 分布、支付缺失创建人、其他 P0 项目型对象与邮件 `email[12]` 迁移证据、逐 Scope 可归属性矩阵，以及新增支付额度账本问题包。支付单组长审核放行保留为后续版本 TODO，不阻塞本版本。Admin 动作矩阵继续后置统一处理。
3. 事实与产品取舍收口后进入新一轮 Spec，拆解 Organization / GroupMembership 状态、全局组上下文、Scope 类型/可分配性矩阵与三级上限契约、支付分配/冲正账本、项目型 Owner 与 CRM Assignee 的对象授权模型、Collaborator/查看范围/附加能力统一合并器、项目迁移批次、退组/组织移出任务、最小审计事件、逐模块动作矩阵和迁移验收用例。B2/E2、数据导出等 TODO 不阻塞本版本。