从一封邀请出发，理解企业、成员、组织、用户组和授权如何协作；同时审视设计距离真实可用还有多远。
account 管理“谁属于哪个企业、组织和用户组，以及在这些范围里有什么管理权”。用户账号与登录身份由 auth 管理；平台操作员及应用分配由 management 管理。
deploy/local/mysql/stubs/30-account.sql 只是本地／测试契约桩，仅含企业、组织、组、审计四张简化表和种子数据；不能用它证明真实业务可运行。管理账号、登录、会话与验证结果；account 读取其发布的视图。
管理企业成员、组织、邀请、角色、组、云绑定及本应用审计。
管理操作员与应用分配；按已知 ID 读取 account 的组织、组视图。
先成为企业成员才能归属该企业组织；没有业务组织时自动归入默认组织。
组织属于企业并可有层级；用户组是本站集合，可跨企业，管理权独立。
创始人是企业治理身份；角色是单独授予并带具体范围的权限事实。
组织层级只表达结构，不继承管理权限。主组织是账号跨企业的单一选择，可为空；只有当前有效组织归属可被选中。
假设本站已有账号：陈（U1）和林（U2）。这是一组虚构的设计示例，ID 是阅读用别名，生产设计使用 UUIDv7。
随后陈创建研发部 O1 并安排林加入；林在 E1 有业务组织后，默认归属自动移除。若林此前的主组织指向 O0，该选择先被清空；林可自行选 O1。平台操作员另建跨企业用户组 G1 并任命组管理员，组管理员将林加入。组关系与企业成员资格相互独立。
以下为同一时点的设计示例快照：林已接受邀请并进入研发部。为可读性只展示关键列；T0 为 2026-11-01 09:00，T1 为 11-02 10:00，T2 为 11-03 10:00（UTC）；H、D、C 为摘要／密文占位符，非可用凭据。省略的时间戳和摘要列仍须遵循设计。表之间的别名是引用，不是实际 SQL 值。
| 设计表 | 示例行（关键列） | 约束与含义 |
|---|---|---|
account_enterprise | id=E1 · name=星河科技 · founder_id=U1 · create_operation_id=OP0 · create_request_hash=H0 | 企业 ID 主键；创始人 + 开通请求键唯一。 |
account_enterprise_member | (E1,U1,T0) (E1,U2,T1) | 复合主键 (enterprise_id, account_id)；移除后当前关系物理删除。 |
account_organization | (O0,E1,默认组织,NULL,true,E1) (O1,E1,研发部,NULL,false,NULL) | 列依次为 id、enterprise_id、name、parent_id、is_default、default_enterprise_id；每企业至多一个默认组织。 |
account_organization_member | (E1,O0,U1,T0) (E1,O1,U2,T2) | 列为 enterprise_id、organization_id、account_id、joined_at；林有业务归属，故不再属于 O0。 |
account_primary_organization | (U1,O0,T0) (U2,O1,T2) | 列为 account_id、organization_id、updated_at；只能指向本人现有归属。 |
| 设计表 | 示例行（关键列） | 约束与含义 |
|---|---|---|
account_invitation | id=I1 · enterprise_id=E1 · normalized_email=lin@example.com · inviter_id=U1 · proposed_role=enterprise_admin · status=accepted · token_version=1 · token_digest=D1 · accepted_account_id=U2 · accept_operation_id=OP1 · accept_request_hash=H1 · accepted_at=T1 | 过期由时间计算；接受的账号、键、摘要和时间共同保存。令牌明文不入表。 |
account_verification_request | id=VR1 · purpose=invitation_accept · subject_id=U2 · operation_id=OP1 · method=email · normalized_target=lin@example.com · invitation_id=I1 · owner_type=NULL · owner_id=NULL · created_at=2026-11-02 09:55 · expires_at=2026-11-02 10:25 | 这是验证委托，不是验证结果；结果由 auth 持有。示例假定尚未被清理。 |
account_role_grant | (R1,U2,enterprise_admin,enterprise,E1,T1) (R2,U1,group_admin,group,G1,T2) | 列为 id、account_id、role_code、scope_type、scope_id、granted_at；范围配对受约束。 |
| 设计表 | 示例行（关键列） | 约束与含义 |
|---|---|---|
account_user_group | id=G1 · name=试用成员 · description=NULL · created_at=T2 | 组不属于企业；操作员登记，组管理员另行授予。 |
account_group_member | (G1,U2,T2) | 列为 group_id、account_id、joined_at；移除企业成员不会自动删除组关系。 |
account_external_binding | owner_type=enterprise · owner_id=E1 · provider=huawei · external_domain=huawei-cn · external_account_id=HC1 · operation_id=OP2 · request_hash=H2 · verification_id=V2 · created_at=T2 | 假设该站能力已验收并开启；同一所有者至多一个绑定，同一云账号可被多个所有者绑定。 |
account_audit_event | event_id=A1 · event_version=1 · occurred_at=T1 · category=user · actor_type=user · actor_id=U2 · action=invitation.accept · target_type=invitation · target_id=I1 · enterprise_id=E1 · outcome=success · policy_version=p2 · policy_matches=[] · details={} | 发生时核实企业归属；记录历史，不依赖业务对象当前存在。其他可空字段此例为 NULL。 |
上表展示业务关键列，不是完整 DDL 或可直接执行的 INSERT。设计还包含索引、事务、保留和保护规则；完整字段请参阅文末各 DATA 文档。桩 SQL 的结构与这份设计并不完全一致。
文档对并发、授权和恢复的设计相当细，但“写了规则”距离“产品场景可交付”还有明显距离。以下区分未实现、未定方案和明确不在首期的边界。
优先级为本次专业评估，不是仓库既定排期。首期排除的能力是产品选择，但一旦目标客户需要相应场景，就构成实际缺口。
推荐业务表述：“企业身份提供商联合登录（企业 SSO）”。企业配置自己的 IdP；受邀员工使用企业身份登录平台，平台完成身份映射后，根据企业成员资格与角色授权。
需要明确：企业 IdP 如何与企业绑定和发现；采用 OIDC 还是 SAML；使用发行方 + 稳定主体标识映射，还是允许经验证邮箱参与首次关联；邀请邮箱与 IdP 身份不匹配时如何处理；停用、离职、会话撤销和 IdP 不可用时如何处置。不能仅凭相同邮箱静默合并账号，也不能把认证成功当成企业授权成功。自动建账号或自动加企业（JIT provisioning）是另一个明确的产品决策。
以下为工作区内的参考文件名称；在线版本不公开仓库源文件。