聚星 / 账号权限、协作与配额


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


从线上现状到下一套组织模型

从线上现状到下一套组织模型


团队共同理解与决策材料
旧 T1-T2-T3 Spec 基线 × 新扁平分组候选

团队共同理解与决策材料 | 旧 T1-T2-T3 Spec 基线 × 新扁平分组候选


事实
→
规则
→
选择

事实 | → | 规则 | → | 选择


本简报用于团队同步与根模型讨论，不把新候选方案表述为已定稿。
Sources: input_v0.md; fact_check_v0.md; spec_v0.md; current online sub-account pages.


01 / 共识


今天要对齐的不是页面，而是权限的根模型

今天要对齐的不是页面，而是权限的根模型


先分清线上事实、已确认规则和仍待决定的结构性选择。

先分清线上事实、已确认规则和仍待决定的结构性选择。


核心结论


线上事实


当前有入口，但没有统一解释层

当前有入口，但没有统一解释层


团队 / 权限 / 数据三页并列；角色、配额、CRM 和项目协作分散实现。

团队 / 权限 / 数据三页并列；角色、配额、CRM 和项目协作分散实现。


已确认


对象协作与安全底线基本成形

对象协作与安全底线基本成形


Owner / Editor / Viewer、对象级授权、硬限制优先、支付资金责任和移交任务等规则可继续复用。


待讨论


账号与分组的根模型尚未定稿

账号与分组的根模型尚未定稿


旧 T1-T2-T3 与新“所属分组 + 管理范围 + 0..N T2”并列，需要团队判断取舍。


讲解重点：不要从“要做哪些页面”开始，而要先确定身份、分组和业务范围如何计算。
Sources: input_v0.md sections 1, 7; fact_check_v0.md sections 3, 9.


02 / 需求范围


42 条反馈最终收敛为权限主线，导出先退出本轮

42 条反馈最终收敛为权限主线，导出先退出本轮


原始反馈仍保留，但本简报只把导出作为范围边界展示。

原始反馈仍保留，但本简报只把导出作为范围边界展示。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


线上事实 · 需求基线


反馈总条数


主子账号和权限


数据配额


数据导出 TODO


18 条


进入本轮 Input / Spec 主线


8 条


数据导出


16 条


保留原始证据，进入独立专项

保留原始证据，进入独立专项


反馈池共有 42 条数据，按原始具体模块统计为权限 18、配额 8、导出 16。
Sources: (【CSM】反馈池)权限账号反馈池.xlsx, sheet 权限账号反馈池, A1:X43; input_v0.md section 2.1.


03 / 线上现状


线上已经有一套“团队和权限”入口，但三页各自承载不同语义

线上已经有一套“团队和权限”入口，但三页各自承载不同语义


当前页面是增量改造的起点，不是从零建设权限中台。

当前页面是增量改造的起点，不是从零建设权限中台。


线上事实 · A 级证据

线上事实 · A 级证据


当前可见结构


- 团队管理：成员、分组、角色、席位和操作记录

- 团队管理：成员、分组、角色、席位和操作记录


- 权限管理：配额页，当前使用 / 累计使用、按账号配置

- 权限管理：配额页，当前使用 / 累计使用、按账号配置


- 数据管理：CRM 四项写权限 + 邮件强制管理员协作

- 数据管理：CRM 四项写权限 + 邮件强制管理员协作


- 现有角色文案：管理员 / 组长 / 成员

- 现有角色文案：管理员 / 组长 / 成员


重要边界


前端页面能证明“展示和提交了什么”，不能单独证明服务端如何裁剪数据或鉴权。

前端页面能证明“展示和提交了什么”，不能单独证明服务端如何裁剪数据或鉴权。


截图来自 2026-08-05 线上页面。团队管理页显示成员 46、已用 45、待邀请 0、剩余 5、总席位 50；简报中使用的截图已裁掉成员明细。
数据管理页仍展示 CRM 四项写权限和邮件“强制添加管理员为协作人”。
Sources: https://cn.noxinfluencer.com/brand/sub-account; https://cn.noxinfluencer.com/brand/sub-account/data; fact_check_v0.md sections 4, 5.


线上能力分散在多个模块，现有基础足够做增量，但缺少统一计算顺序

线上能力分散在多个模块，现有基础足够做增量，但缺少统一计算顺序


“权限管理”不是一个页面问题，而是多个对象和动作共享同一套解释层。

“权限管理”不是一个页面问题，而是多个对象和动作共享同一套解释层。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


线上事实 · 代码基线


账号 / 分组


adminStatus=0/1/2
teamId / group
已有成员转组

adminStatus=0/1/2 | teamId / group | 已有成员转组


复用 + 统一解释


配额


当期 / 累计
共享团队 / 账号上限
已有 inherit 雏形

当期 / 累计 | 共享团队 / 账号上限 | 已有 inherit 雏形


接入统一模型


CRM


ownerUser
四项写权限
viewAuthors 仅视图共享


对象协作


邮件 / 资源夹 / 监控
已有 members / Editor 雏形
项目级接口

邮件 / 资源夹 / 监控 | 已有 members / Editor 雏形 | 项目级接口


支付 / 审计


支付单 / 草稿 / 钱包
通知底座已有
跨模块审计与移交缺口

支付单 / 草稿 / 钱包 | 通知底座已有 | 跨模块审计与移交缺口


身份字段待后端


增量原则：保留现有模块的业务字段和流程；统一的是“谁能看、谁能做、谁承担额度”，不是重建所有模块。


这里展示的是事实地图，不是目标架构。
Sources: fact_check_v0.md sections 4-7; kol-next current code paths listed in fact_check_v0.md.


03 / 线上现状


当前真正的痛点是“同一个人，在不同模块被不同方式解释”

当前真正的痛点是“同一个人，在不同模块被不同方式解释”


页面有能力，规则却分散在 adminStatus、模块开关、对象字段和服务端真值中。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


线上事实 → 产品问题


线上现状


代码 / 页面表现


团队实际感受


角色判断


成员页 / 配额页使用 Boolean(adminStatus)；邮件只认 adminStatus=1


同一个组长是否算管理员，跨模块不一致

同一个组长是否算管理员，跨模块不一致


邀请


当前弹窗只提交 emails

当前弹窗只提交 emails


无法在引入成员时显式设置分组、模块和配额

无法在引入成员时显式设置分组、模块和配额


协作


邮件、资源夹、监控、CRM、支付各有成员或范围字段

邮件、资源夹、监控、CRM、支付各有成员或范围字段


无法统一解释 Owner、Editor、Viewer 和高风险动作


数据移交


清退只解除成员关系，没有资产预检查和任务

清退只解除成员关系，没有资产预检查和任务


Owner、ACL、资金责任可能留下孤儿或跨组残留

Owner、ACL、资金责任可能留下孤儿或跨组残留


这也是为什么旧 Spec 不能直接进入开发：根模型一变，鉴权、协作者候选、转组移交和 Dashboard 口径都会一起变。


Sources: fact_check_v0.md sections 4.1, 4.2, 6, 7; spec_v0.md sections 3, 4, 10, 11.


04 / 已确认


有一批规则已经可以锁定，不应随根模型变化反复重讨论

有一批规则已经可以锁定，不应随根模型变化反复重讨论


这些规则是模块接入时的安全底线和对象语义。

这些规则是模块接入时的安全底线和对象语义。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


已确认 · 适用于两套模型

已确认 · 适用于两套模型


对象身份


项目型对象统一使用 Owner / Editor / Viewer；Owner 与 created_by 分离。


授权粒度


显式协作绑定具体项目、CRM 记录或支付单，不建设模块级协作者名单。

显式协作绑定具体项目、CRM 记录或支付单，不建设模块级协作者名单。


权限合并


多来源取最高有效权限；模块禁用、套餐无权益、账号停用等硬限制优先。

多来源取最高有效权限；模块禁用、套餐无权益、账号停用等硬限制优先。


协作边界


普通成员不允许跨组协作或跨组转交；高风险动作独立判断。

普通成员不允许跨组协作或跨组转交；高风险动作独立判断。


支付责任


支付资金责任归预约提交时的 Owner 快照；提交人、放行人只记 actor。

支付资金责任归预约提交时的 Owner 快照；提交人、放行人只记 actor。


数据移交


转组 / 离职必须进入标准移交流程，支持跟随本人或移交接收人。

转组 / 离职必须进入标准移交流程，支持跟随本人或移交接收人。


这些是 Input 和前序讨论中已经明确的系统不变量或对象语义。
Sources: input_v0.md sections 7.2-7.10; spec_v0.md sections 2, 4, 10, 11.


05 / 旧方案


旧 Spec 的 T1-T2-T3 模型：角色同时承担组织身份和业务范围

旧 Spec 的 T1-T2-T3 模型：角色同时承担组织身份和业务范围


它对简单分组足够直观，但把 T1 放在组体系之外。

它对简单分组足够直观，但把 T1 放在组体系之外。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


旧方案基线 · spec_v0


T1
主账号 / 超级管理员
全组织管理 + 隐式业务策略

T1 | 主账号 / 超级管理员 | 全组织管理 + 隐式业务策略


正式分组 A
0..1 个 T2
若无 T2，由 T1 直管


正式分组 B
0..1 个 T2
T2 管本组 T3


隐藏分组
T3 未分组成员
无 T2，T1 直管

隐藏分组 | T3 未分组成员 | 无 T2，T1 直管


旧方案的关键特征


T1 不归组；T2/T3 只有一个主分组；T1 可成为跨组协作者或数据接收人；T2 业务范围默认是本组。


这是当前 spec_v0 的设计基线，不是线上已经完整实现的状态。
Sources: spec_v0.md sections 3.2-3.4, 4.1, 10.3, 11.6; input_v0.md sections 7.5-7.6.


05 / 场景


三个场景同时成立，才是根模型的验收标准

三个场景同时成立，才是根模型的验收标准


不是为了支持复杂组织而复杂化，而是要覆盖 A、B 和小团队的共同底线。

不是为了支持复杂组织而复杂化，而是要覆盖 A、B 和小团队的共同底线。


需求场景 · 决策依据


A / 营销负责人


管理营销一组、营销二组
分配配额、看业绩汇总、管组级配置
不能看到不负责的其他团队

管理营销一组、营销二组 | 分配配额、看业绩汇总、管组级配置 | 不能看到不负责的其他团队


B / 公司老板


日常查看全组织业绩
必要时参与各组业务
不应因为所有者身份自动获得全部业务权限

日常查看全组织业绩 | 必要时参与各组业务 | 不应因为所有者身份自动获得全部业务权限


C / 小团队


5 个账号甚至不需要分组
一个默认组即可
不需要学习当前组或复杂组织树

5 个账号甚至不需要分组 | 一个默认组即可 | 不需要学习当前组或复杂组织树


验收问题：是否能让账号稳定地“属于一个组”，同时在不切换当前组的情况下管理多个组？


该页来自用户在多轮讨论中明确的业务场景。
Sources: current discussion 2026-07-24 to 2026-08-05; memory task group 2026-07-10 account/group model redesign.


06 / 新候选


新候选把“属于哪里”和“负责哪里”分成两个字段

新候选把“属于哪里”和“负责哪里”分成两个字段


扁平分组、没有嵌套、没有当前组切换；管理范围可以重叠。

扁平分组、没有嵌套、没有当前组切换；管理范围可以重叠。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


待讨论候选


组织身份


所有者 / 管理员 / 普通成员

所有者 / 管理员 / 普通成员


业务身份


T2 / T3


稳定归属


所属分组
每个账号恰好一个

所属分组 | 每个账号恰好一个


Owner 的对象归属
项目 / 记录 / 支付单

Owner 的对象归属 | 项目 / 记录 / 支付单


管理范围


0..N 个扁平分组
或“全部分组”

0..N 个扁平分组 | 或“全部分组”


Dashboard / 配额 / 组级设置
范围内业务访问

Dashboard / 配额 / 组级设置 | 范围内业务访问


候选规则：每组允许 0..N 名 T2 管理者；一个 T2 可以管理 1..N 个组；范围可重叠。


新候选尚未确认。这里故意把“所属分组”和“管理范围”画成两个事实。
Sources: current discussion; memory task group 2; candidate model not yet promoted into input_v0.md.


06 / 新候选


在新候选中，A、B、C 都能被解释，但不需要当前组切换

在新候选中，A、B、C 都能被解释，但不需要当前组切换


这张表是团队讨论时最重要的“代入题”。

这张表是团队讨论时最重要的“代入题”。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


待讨论候选


账号


组织身份


业务等级


所属分组


默认效果


A 营销负责人


管理员或普通成员


营销管理组


营销一组、营销二组


看汇总 / 配额 / 组级配置

看汇总 / 配额 / 组级配置


B 老板


组织所有者


默认组


全部分组


全组织业务管理，但权限显式来源

全组织业务管理，但权限显式来源


C 组负责人


普通成员


营销一组


本组日常管理


D 执行成员


无


自身和对象协作权限


小团队：只创建一个默认组；B/A 的管理范围就是默认组，普通成员不感知额外概念。


“T2/T3 由管理范围推导”是当前候选，尚未确认。另一种实现是保留独立 accountLevel，但管理权限仍由管理范围计算。
Sources: current discussion; spec_v0.md sections 3.2, 3.3, 9.7 as old baseline.


07 / 权限计算


两套模型都应使用同一条权限计算链，差别只在“范围来源”

两套模型都应使用同一条权限计算链，差别只在“范围来源”


这样可以保留已确认的对象协作和安全边界，控制改动面。

这样可以保留已确认的对象协作和安全边界，控制改动面。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


已确认底座 + 待讨论范围

已确认底座 + 待讨论范围


硬限制


模块未开通 / 套餐无权益 / 账号停用 / 组织关系失效

模块未开通 / 套餐无权益 / 账号停用 / 组织关系失效


账号准入


账号级模块可用性 + 账号配额状态

账号级模块可用性 + 账号配额状态


管理范围


旧：T1 全组织 / T2 本组
新：管理范围命中的分组

旧：T1 全组织 / T2 本组 | 新：管理范围命中的分组


对象授权


Owner / Editor / Viewer + can_manage_collaborators / can_execute_payment


动作判断


查看、编辑、删除、转交、协作者管理、支付执行分别判断

查看、编辑、删除、转交、协作者管理、支付执行分别判断


旧新方案均可复用这一条鉴权顺序；主要变化是管理范围的来源，以及管理范围是否能覆盖组级业务访问。
Sources: spec_v0.md sections 2, 4, 11; input_v0.md sections 7.2-7.10.


对象协作继续保持项目级，管理范围不等于把账号批量写进协作者列表

对象协作继续保持项目级，管理范围不等于把账号批量写进协作者列表


这是减少同步成本和避免权限“传染”的关键设计。

这是减少同步成本和避免权限“传染”的关键设计。


已确认底座


模块准入
账号是否能进入

模块准入 | 账号是否能进入


Owner 所属分组
决定对象归属

Owner 所属分组 | 决定对象归属


管理范围 / 角色范围
动态覆盖一批对象

管理范围 / 角色范围 | 动态覆盖一批对象


对象 ACL
当前项目显式 Viewer / Editor


高风险动作永远单独判断


- 删除：不从普通 Editor 自动推导

- 删除：不从普通 Editor 自动推导


- Owner 转交：遵守同组 / 移交任务规则

- Owner 转交：遵守同组 / 移交任务规则


- 协作者管理：Owner / T1 或显式附加能力

- 协作者管理：Owner / T1 或显式附加能力


- 支付执行：Owner / T1 或 can_execute_payment；资金责任仍归 Owner


“管理范围覆盖对象”是新候选需要进一步明确的地方：它可以获得模块范围 Viewer/Editor，但不应把具体账号批量写入 ACL。
Sources: input_v0.md sections 7.7-7.10; spec_v0.md sections 4, 11.


08 / 配额与特殊对象


08 / 配额与特殊对象

08 / 配额与特殊对象


配额、支付和移交可以先沿用既定边界，根模型只替换“谁有权操作”

配额、支付和移交可以先沿用既定边界，根模型只替换“谁有权操作”


这部分是新方案相对可控的原因。

这部分是新方案相对可控的原因。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


已确认底座 + 后端待核验

已确认底座 + 后端待核验


配额


组织 → 分组 → 账号
允许下级上限之和超过父级
实际消耗逐层拦截
账号 inherit = 不设个人上限

组织 → 分组 → 账号 | 允许下级上限之和超过父级 | 实际消耗逐层拦截 | 账号 inherit = 不设个人上限


跨境支付


本期所有账号不受个人支付额度限制
资金模式 shared
预约提交即形成资金承诺
fundingUid 取 Owner 快照

本期所有账号不受个人支付额度限制 | 资金模式 shared | 预约提交即形成资金承诺 | fundingUid 取 Owner 快照


转组 / 离职


必须进入标准移交任务
选择跟随本人或移交接收人
预检查、摘要页、通知、回滚

必须进入标准移交任务 | 选择跟随本人或移交接收人 | 预检查、摘要页、通知、回滚


后端仍需确认：真实扣额主体、支付可见范围、editFlag / Owner 真值、移交事务边界。


Sources: input_v0.md sections 7.3, 7.8, 7.9; fact_check_v0.md sections 7-8; spec_v0.md sections 5, 10.


09 / 影响评估


新候选不是全盘重做：对象底座保留，账号与范围章节需要重写

新候选不是全盘重做：对象底座保留，账号与范围章节需要重写


影响最大的不是页面数量，而是权限来源和迁移逻辑。

影响最大的不是页面数量，而是权限来源和迁移逻辑。


新旧方案对比


Spec 区域


旧模型处理


新候选处理


影响


核心实体


T1 无组；T2/T3 唯一组；group.leaderUid 单值


所有账号唯一所属组；组与 T2 多对多

所有账号唯一所属组；组与 T2 多对多


重写


统一鉴权


T1 隐式 / T2 本组 / ACL


管理范围命中组 / ACL

管理范围命中组 / ACL


重写来源


配额计算


组织 → 组 → 账号


基本保留


对象 ACL


Owner / Editor / Viewer


保留


成员移交


T1 特殊接收人，普通成员同组

T1 特殊接收人，普通成员同组


所有账号有组；范围负责人不自动成为接收人

所有账号有组；范围负责人不自动成为接收人


需重新定边界


CRM 迁移


T1 + T2/同组范围策略

T1 + T2/同组范围策略


改为新业务范围来源，四项语义仍等价

改为新业务范围来源，四项语义仍等价


需重写映射


影响评估基于当前 spec_v0，未进入实现估算。
Sources: spec_v0.md sections 3, 4, 5, 10, 11; current candidate model discussion.


10 / 决策台账


已确认事项：先把不依赖根模型的底座做成稳定共识

已确认事项：先把不依赖根模型的底座做成稳定共识


这些内容可以作为后续 Spec 重写时的保留区。

这些内容可以作为后续 Spec 重写时的保留区。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


已确认


- 本轮范围：主子账号和权限为主；配额做强关联项；数据导出进入 TODO。

- 本轮范围：主子账号和权限为主；配额做强关联项；数据导出进入 TODO。


- 所有模块逐账号配置可用性和配额，不用 T1/T2/T3 聚合全部功能权限。

- 所有模块逐账号配置可用性和配额，不用 T1/T2/T3 聚合全部功能权限。


- 项目 / 记录 / 支付单使用 Owner / Editor / Viewer；协作至少落到对象级。


- Owner、created_by、实际 actor、资金责任账号分开保存。


- T1 隐式协作、Viewer、Editor 附加能力不能互相传染；高风险动作独立判断。


- CRM 线上四项写权限保持等价迁移，不直接清空或重置。

- CRM 线上四项写权限保持等价迁移，不直接清空或重置。


- 跨境支付本期不做账号支付额度，保持 shared；支付单接入对象协作。

- 跨境支付本期不做账号支付额度，保持 shared；支付单接入对象协作。


- 成员转组 / 离职数据移交是必需独立议题，支付模块先接口化假设。

- 成员转组 / 离职数据移交是必需独立议题，支付模块先接口化假设。


这些规则会被新旧两套根模型共同复用。

这些规则会被新旧两套根模型共同复用。


Sources: input_v0.md sections 1, 7.1-7.10; fact_check_v0.md section 9; current discussion.


未确定事项：根模型只有一个总决策，但会影响五个下游规则

未确定事项：根模型只有一个总决策，但会影响五个下游规则


团队讨论可以先集中处理这些问题，不必同时讨论全部模块动作矩阵。

团队讨论可以先集中处理这些问题，不必同时讨论全部模块动作矩阵。


待讨论


是否采用扁平分组 + 账号唯一所属组？

是否采用扁平分组 + 账号唯一所属组？


新候选的基础前提


每组 T2 是 0..1 还是 0..N？


0..N 能同时支持 A / B / C，但取消唯一组长

0..N 能同时支持 A / B / C，但取消唯一组长


T2/T3 是独立字段还是由管理范围推导？

T2/T3 是独立字段还是由管理范围推导？


推导更一致，独立字段迁移更稳

推导更一致，独立字段迁移更稳


管理范围固定授予哪些动作？

管理范围固定授予哪些动作？


查看汇总、配额、组级配置、业务读写

查看汇总、配额、组级配置、业务读写


负责范围账号能否参与跨组对象操作？

负责范围账号能否参与跨组对象操作？


要区分范围管理权与显式跨组协作

要区分范围管理权与显式跨组协作


组织所有者/管理员如何获得业务权限？

组织所有者/管理员如何获得业务权限？


显式范围，还是仅角色身份 + 账号配置

显式范围，还是仅角色身份 + 账号配置


D1-D6 是本轮新根模型的开放决策，不应在简报中标成已确认。
Sources: current discussion; spec_v0.md sections 3, 4, 9, 10, 11.


11 / 范围与节奏


交付范围分四层：P0 先做主线，未确认模型不进入实施

交付范围分四层：P0 先做主线，未确认模型不进入实施


优先级已基本明确，根模型确认是进入 Spec 重写的前置条件。

优先级已基本明确，根模型确认是进入 Spec 重写的前置条件。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


优先级台账


角色 / 账号 / 分组根模型
账号级模块准入与配额
对象级协作
CRM 等价迁移
跨境支付 ACL 与准入
成员转组 / 离职移交

角色 / 账号 / 分组根模型 | 账号级模块准入与配额 | 对象级协作 | CRM 等价迁移 | 跨境支付 ACL 与准入 | 成员转组 / 离职移交


成员与协作人搜索
配额周期 / 可见性细化
内容监控标签定义限制
批量增加额度
相关页面入口优化

成员与协作人搜索 | 配额周期 / 可见性细化 | 内容监控标签定义限制 | 批量增加额度 | 相关页面入口优化


Backlog


旧任务列表默认协作
消息中心单会话 ACL
更复杂的数据迁移选择
非主线业务对象接入

旧任务列表默认协作 | 消息中心单会话 ACL | 更复杂的数据迁移选择 | 非主线业务对象接入


TODO


数据导出专项 16 条
支付个人额度 / 充值余额分配
逐组差异化策略
自定义角色体系
跨组织账号治理

数据导出专项 16 条 | 支付个人额度 / 充值余额分配 | 逐组差异化策略 | 自定义角色体系 | 跨组织账号治理


本期不是建设通用权限中台；任何候选模型都必须先通过现有聚星场景和后端事实核验。

本期不是建设通用权限中台；任何候选模型都必须先通过现有聚星场景和后端事实核验。


P0/P1/Backlog/TODO 基于 input_v0.md 现有优先级和后续讨论补充。
Sources: input_v0.md sections 2, 7.1, 7.10, 8; fact_check_v0.md section 8.


12 / 下一步


团队今天需要带走三件事，而不是一次定完所有动作矩阵

团队今天需要带走三件事，而不是一次定完所有动作矩阵


先定根模型，再把影响范围落入 Input；Spec 进入实现设计阶段后再拆动作矩阵。


会议收束


确认旧模型是否继续作为基线

确认旧模型是否继续作为基线


T1 是否仍是未分组的业务高权限主体？每组是否坚持 0..1 T2？

T1 是否仍是未分组的业务高权限主体？每组是否坚持 0..1 T2？


讨论新扁平模型是否成立


所属分组、管理范围、0..N T2 和 T2/T3 语义是否能覆盖 A/B/C？


锁定进入 Input 的版本

锁定进入 Input 的版本


本轮只保留最小能力包；模块动作矩阵、后端真值和 UI 进入后续 Spec。

本轮只保留最小能力包；模块动作矩阵、后端真值和 UI 进入后续 Spec。


建议会议结论格式：保留 / 修改 / 否决 + 影响章节 + 需要谁补事实。

建议会议结论格式：保留 / 修改 / 否决 + 影响章节 + 需要谁补事实。


结束时不要把新方案写成已确认；输出应是根模型决策、待补事实和受影响的 Input/Spec 章节。
Sources: current discussion; input_v0.md; fact_check_v0.md; spec_v0.md.


A / 附录


附录：事实来源和后续核验入口

附录：事实来源和后续核验入口


简报中的线上事实、代码事实和行业参照都保留可追溯路径。

简报中的线上事实、代码事实和行业参照都保留可追溯路径。


聚星 / 账号权限、协作与配额

聚星 / 账号权限、协作与配额


来源索引


项目材料


01_Product_Specs/account_permission_collaboration/
- (【CSM】反馈池)权限账号反馈池.xlsx
- input_v0.md
- fact_check_v0.md
- spec_v0.md
- crm_write_permissions_online.png

01_Product_Specs/account_permission_collaboration/ | - (【CSM】反馈池)权限账号反馈池.xlsx | - input_v0.md | - fact_check_v0.md | - spec_v0.md | - crm...


线上与代码


线上：/brand/sub-account
线上：/brand/sub-account/quota
线上：/brand/sub-account/data
代码：kol-next/pages/brand/sub-account
代码：kol-next/assets/script/constant/subAccount.js
代码：kol-next/api/setting/subAccount.js

线上：/brand/sub-account | 线上：/brand/sub-account/quota | 线上：/brand/sub-account/data | 代码：kol-next/pages/brand/sub-account | 代码：kol-next/asse...


行业参照


HubSpot Main / Extra / nested teams
Salesforce role hierarchy and record sharing
Asana project team ownership
Google Workspace scoped admin roles
GitHub organization / team / repository roles

HubSpot Main / Extra / nested teams | Salesforce role hierarchy and record sharing | Asana project team ownership | Google Workspace scop...


后端待核验问题包


CRM 16 组合真值
共享对象扣额主体
支付可见范围 / editFlag / Owner
清退副作用
跨模块审计能力

CRM 16 组合真值 | 共享对象扣额主体 | 支付可见范围 / editFlag / Owner | 清退副作用 | 跨模块审计能力


完整来源和链接在配套 Markdown 讲稿与事实索引中。
Sources: fact_check_v0.md section 8; official references: https://knowledge.hubspot.com/user-management/create-and-manage-teams, https://trailhead.salesforce.com/en/content/learn/modules/data_security/data_security_roles, https://help.asana.com/s/article/create-projects-in-asana, https://support.google.com/a/answer/9807615, https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams.