SaaS 多租户平台技术方案设计（M-Design 民用版）：领域划分 · 需求分析 · 功能分析 · 概要设计 · 详细设计

晓寒风骤2026-11-05 7:10

业务领域划分

域 名称 为什么独立成域 对应服务 / 部署落位
D1 身份与组织 注册→认领→成员→角色→转让，一条完整生命周期 身份与组织服务 → core identity
D2 商品与权益 版本发布/下架 \+ 授予→激活→到期→替换/撤销 \+ 试用资格去重 权益与商品服务 → core entitlement
D3 交易与履约 订单、支付尝试、核实、履约、授予、合同核销；BR\-003 三段分离 交易与履约服务 → core trade
D4 售后与财务 客服受理→财务审核→计算→执行→补偿，权限与角色都不同于交易 售后服务 → core aftersale
D5 数据生命周期 90\+30 保留清理、注销撤回、取回，独立状态机与批处理 生命周期服务 → core \+ job-executor
D6 独立部署授权 签发→导入→校验→撤销→时钟异常，完全离线、与 SaaS 轨不共享语义 License 服务 → core license
D7 平台运营治理 运营账号与后台人员生命周期、角色与权限模板、可信功能动作目录、通用字典、公告、客户端版本、商品与协议治理、空间与建模用户管控、订单与发票办理、调度、审计 运营管理后台 → ops-console \+ core ops API
D8 计量与用量 上报→聚合→超额判定；承接未来并发席位、按量计费 首期挂 entitlement，预留 metering
X1 授权运行时（横切） epoch/变更事件/降级事件，是运行时基础设施不是业务 授权网关 → saas-authz-gateway

授权运行时（横切）：epoch/变更事件/降级事件（运行时基础设施不是业务）。先不独立拆分，融入到身份与组织中。

独立部署授权：这一块内容，第一期先不考虑

需求分析

本层对应 M\-Design「01需求分析」包的 6 张分域需求图：18 个需求组 R1\~R18、87 条叶子需求。编号规则：组保留 S00 的 R 号，叶子改域编号 D\<n\>\.\<m\>；父子需求用"叶子→组"的包含连线表达；需求组框居左列、叶子需求按编号升序向右展开。S00 原编号与域编号的追溯以《S00\-域编号映射表》为唯一依据。

D1 身份与组织

图上内容描述：D1 身份与组织分域需求图：12 个需求组、51 条叶子需求，图上 63 个具名符号、51 条连线（全部 Containment）。本轮按《SaaS 需求中心》补 2 组 6 叶------R19 受控治理访问（3 叶：D1\.46\~D1\.48）、R20 团队邀请与成员世代（3 叶：D1\.49\~D1\.51）。

  • 看图口径：63 个具名符号的构造型都是 <<需求>>（12 个组框 \+ 51 个叶子框）；连线全部是 Containment（嵌套包含），方向固定读作叶子需求 → 所属需求组，一叶子一条，故符号 63 而连线 51。
  • 存量四组（17 叶）：R1 用户租户与空间 6 叶（D1\.1\~D1\.6）、R2 角色与职责边界 4 叶（D1\.7\~D1\.10）、R3 席位规则 3 叶（D1\.11\~D1\.13）、R10 生效时效与故障降级 4 叶（D1\.14\~D1\.17）。
  • 新增四组（19 叶）：R13 账号注册与一次性验证凭证 6 叶（D1\.18\~D1\.23）、R14 登录会话与设备 4 叶（D1\.24\~D1\.27）、R15 找回、改绑与账号注销 4 叶（D1\.28\~D1\.31）、R16 协议版本与同意审计 5 叶（D1\.32\~D1\.36）。
  • 权限管控两组（9 叶）：R17 权限资源与权限组定义 4 叶（D1\.37\~D1\.40）、R18 权限初始化与接口访问鉴权 5 叶（D1\.41\~D1\.45）。
  • R13 点名：手机号唯一标识与部署身份域边界、一次性验证凭证绑定用途与尝试、人机校验票据经服务端验证后才发短信、发送与校验频控（参数建议待确认）、验证通过后幂等建号、验证码登录自动注册边界。
  • R14 与 R15 点名：R14：登录建立身份会话不等于业务授权、会话与设备可查可撤、凭证与风险变更使会话按范围失效（参数建议待确认）、身份状态与异步操作结果可查询收敛；R15：凭证找回须先证明控制权、手机号改绑双侧证明且冲突不合并、注销前置检查与撤回期、账号清理不级联。
  • R16 点名：逐流程逐次主动同意并只追加留痕、同意证据服务端校验与版本变更拒绝、自动注册与登录同意事件串联、协议版本发布即锁定与纠错走新版本、同意记录访问边界与敏感信息保护。
  • R17 点名：权限资源四类（接口 / 页面 / 操作 / 功能权限点）与路径模式口径、权限资源与权限组为平台级定义且编码唯一、权限组是权限资源的复用集合、功能权限点已并入权限资源同表管理。
  • R18 点名：建租户时权限组展开为角色资源授权、平台角色与租户自定义角色共用一张授权表、接口访问按路径与方法服务端判定、页面与操作可见性只是体验层、授权变更可追溯且不吊销既有身份。
  • 连线与编号核对：51 条 Containment 按 6\+4\+3\+4\+6\+4\+4\+5\+4\+5\+3\+3 收口到十二个组框；叶子域内连续编号 D1\.1\~D1\.51，组框保留 S00 原 R 号（R1/R2/R3/R10/R13\~R20）做追溯；图上无叶子互连、无跨域引用块。
  • 需求中心两组（6 叶）：R19 受控治理访问 3 叶（D1\.46\~D1\.48）、R20 团队邀请与成员世代 3 叶（D1\.49\~D1\.51），本域合计 12 组 51 叶。
  • R19 与 R20 点名：R19：用途隔离的治理上下文替代业务会话、治理动作须带对象引用与时效并留痕、受限账号仅可状态查询申诉与售后受理；R20：先有邀请接受后才有资格、重发邀请使旧链接失效且不得延长截止、重新加入生成新世代旧回调只结旧绑定。

为什么这么设计：身份域从"组织与席位"扩成"组织 \+ 账号生命周期 \+ 权限管控"：U01 的 19 条与权限管控的 9 条新叶都挂在同一域里，才与既有 17 叶共用同一套身份、角色与空间锚点。

  • 归域依据：注册、凭证、会话、找回改绑、注销、协议同意全部指向同一个稳定用户身份与个人空间锚点（D1\.1\~D1\.2），外拆任何一段都会让 user 与 space 变成跨域共享表。
  • 归域依据（分组）：R13\~R16 按 U01 补、R17\~R18 按权限管控补，与 S00 的 R1/R2/R3/R10 并列而不合并：账号生命周期管"凭证与会话的有效性"，权限两组管"资源定义与访问判定"，存量四组管"身份归属、角色与席位"，判据不同但同域才可验收。
  • 归域依据（权限两组）：权限资源与授权判定挂在同一套角色（D1\.7\~D1\.10）与空间上下文（D1\.1\~D1\.2）上，另立域会让 role\_resource 变成跨域共享表；D1\.40 的功能权限点同表分流也只有与 resource、role\_resource 同域才核得了。
  • 关键决策与备选：否掉"登录会话另立授权域"------D1\.24 明确登录只建立身份会话，能力放行是 R10 的每请求 epoch 校验，同域才验得了撤权即时生效；否掉"手机号当主身份"------D1\.18 与 DEC\-01 一致，手机号只是登录凭证，改绑不迁资产。
  • 承接的硬约束：D1\.19 一次性凭证绑定用途与尝试、D1\.20 票据先服务端验证再发短信、D1\.22 幂等建号、D1\.29 冲突不合并、D1\.31 清理不级联、D1\.32/D1\.33 主动同意与服务端版本校验------六条都是可判定的禁止项，不做成偏好项。
  • 待确认口径：D1\.21 与 D1\.26 把验证码长度、有效期、发送频控、会话绝对有效期与失效范围粒度都标为"参数建议待确认"：需求层只锁"有频控""按范围失效"的行为约束，数值留给安全评审。
  • 落地形态：新增身份操作尝试（注册与凭证变更同表）、验证凭证、人机校验票据、会话、设备、账号注销申请、协议版本、同意事件、部署身份域九张表与对应操作，本轮再加权限资源、权限组、权限组资源项、角色资源授权四张表与对应操作；空间、成员、席位、授权水位四组存量表结构不动。
  • 验收与留痕：同意事件只追加，会话与设备可查可撤，身份操作尝试与账号注销申请带幂等键；账号注销的验收样本是"撤回期内撤销 → 数据与权益不变"。

D2 商品与权益

图上内容描述：D2 商品与权益分域需求图：2 个需求组、8 条叶子需求，图上 10 个具名符号、8 条连线（全部 Containment）。本轮按《SaaS 需求中心》补 1 组 3 叶------R23 席位降额与商业写围栏（3 叶：D2\.6\~D2\.8）。

  • 看图口径：10 个具名符号全为 <<需求>>（组框 R4 与 R23、8 个叶子框）；连线类型为 Containment（嵌套包含），8 条一律读作叶子需求 → 所属组：5 条归 R4 试用资格与时间、3 条归 R23 席位降额与商业写围栏。
  • R4 叶子清单：D2\.1 试用包与默认配置、D2\.2 激活时绑定最新版本、D2\.3 个人试用一次性、D2\.4 团队试用双重去重、D2\.5 试用有效区间算法。
  • 组内语义分层：D2\.1/D2\.2 管包对象与版本绑定，D2\.3/D2\.4 管资格去重，D2\.5 管时间算法；三类专业关注点共用一个组框，因为 S00 只为试用立了一条 DEC\-04。
  • 关键连线：8 条一叶子一条、无叶子互连；图上不含交易域与身份域的块，试用与付费的衔接改由 D3 的 D3\.3 试用转付费切换表达。
  • R23 叶子清单：D2\.6 降额超限须当前所有者确认保留名单、D2\.7 未确认前只停该产品团队写入与新专业导出、D2\.8 零额度只可确认空名单不得默认保留。
  • 为何单立一组：R4 管「能不能拿到试用」，R23 管「席位拿多了怎么收」，两者共用 plan\_version 与席位语义但判据相反；S00 未为降额立 DEC，故新组挂 R23 而不并入 R4，验收时两条政策也能各自出题。

为什么这么设计：试用归 D2 而不归交易域：资格判定是权益体系的内在规则，不该先有一张订单。

  • 归域依据 ：映射表口径 D2←R4（DEC\-04）。试用与付费共用 plan / plan_version / entitlement 同一套版本与配额语义，试用只是获取入口，席位上限又与 D1\.12 共用同一条政策。
  • 关键决策与备选：备选是把试用建模成 0 元订单并入 D3，被否------双重去重与订单链路无关，合并会造成先下单才能验资格的错误耦合，activateTrial 与 createOrder 互相牵制，幂等键语义也会混。
  • 承接的硬约束：D2\.2 激活时绑定最新版本、已激活不追溯，区别于付费订单在成交时锁快照；D2\.1 个人与团队是两个不同权益包对象，默认 7 天、个人 100MB、团队 200MB、各 3 项目。
  • 承接的硬约束：D2\.5 有效区间为 \[激活时点, 激活日次日 00:00 起 N 个自然日\)，右端点不含、统一北京时间，例：9 月 21 日 15:00 激活 7 天则 9 月 29 日 00:00 失效。
  • 落地形态 ：去重靠 trial_consumption \+ trial_consumed_member 唯一键（纯 DB 约束，不依赖 Redis 锁），绑定版本落 entitlement.plan_version_id；操作 checkTrialEligibility / activateTrial。
  • 取舍与代价：双重去重只限制试用获取，不等于禁止加入团队或使用合法付费权益；滥用识别与申诉机制按 S00 §4\.2 留给后续文档，本层不承诺防住所有薅试用行为。

D3 交易与履约

图上内容描述：D3 交易与履约分域需求图：2 个需求组、9 条叶子需求，图上 11 个具名符号、9 条连线（全部 Containment）。本轮本域需求层无新增条款。

  • 看图口径 ：11 个具名符号均为 <<需求>>（组框 R5、R8 与 9 个叶子框）；连线类型为 Containment（嵌套包含）、方向叶子 → 组，7 条指向 R5 付费周期续购与升级、2 条指向 R8。
  • R5 付费周期续购与升级（7 叶）：D3\.1 起算与日期锚点、D3\.2 同套餐续购顺延、D3\.3 试用转付费切换、D3\.4 有效期内可升不可降、D3\.5 升级换单与退款、D3\.6 退款失败不回退权益、D3\.7 主套餐唯一与增购独立。
  • R8 首发续费方式（2 叶）：D3\.8 首期仅手动购买续购、D3\.9 不伪装连续包。
  • 关键连线：9 条与 9 叶一一对应；两组分开画，是因为 D3\.1\~D3\.7 属周期与权益变更算法（DEC\-05），D3\.8\~D3\.9 属发布节奏约束（DEC\-08），S00 未合并这两条规则。
  • 图上不出现的部分：无支付渠道块、无身份域块；下单---支付---履约的三段切分不在本图表达，改由 D7 的 D7\.12 交易三段分离作横切约束。

为什么这么设计：D3 把周期算法与首发节奏收在一域：所有起算点都由支付核实这一交易事件驱动。

  • 归域依据：映射表 D3←R5,R8；R5 划入交易与履约而非权益域是 2026\-09\-23 用户裁决的争议项之一------次日 00:00 起算、锚点保留、顺延与换单都以支付核实成功为触发事件，脱离订单链无法验收。
  • 关键决策与备选：升级曾考虑直接补差价，被 S00 §5\.3 否为新订单完整付款 \+ 原订单按时间比例退款，D3\.5 因此成文；另一条被否的是把手动年付包装成连续包售卖。
  • 承接的硬约束：D3\.1 锚点不因短月漂移（非闰年 1 月 31 日起算，首月止于 2 月 28 日 00:00、后续边界回到 3 月 31 日）；D3\.4 有效期内禁降级；D3\.6 退款失败进独立补偿、不要求重复付款。
  • 承接的硬约束：D3\.7 同一空间同一销售产品仅一套生效主套餐，专业模块与扩容独立、不因主套餐续购或升级连带退款，个人空间与团队空间权益不叠加。
  • 落地形态 ：order.snapshot_json、entitlement.anchor_at / end_at、upgrade_record；操作 renewSubscription、quoteUpgrade、upgradeSubscription，补偿由 refund\-compensation 任务承接。
  • 验收与留痕 ：时间口径按 S00\-AC\-02/03/04 三条算例回归；换单要求旧权益停止与新订单生效落在同一时点，核 upgrade_record 与 entitlement.status=REPLACED 的一致性。

D4 售后与财务

图上内容描述：D4 售后与财务分域需求图：2 个需求组、9 条叶子需求，图上 11 个具名符号、9 条连线（全部 Containment）。本轮按《SaaS 需求中心》补 1 组 3 叶------R24 对账批次与异常实收（3 叶：D4\.7\~D4\.9）。

  • 看图口径：11 个具名符号均为 <<需求>>（组框 R7 退款与发票、R24 对账批次与异常实收与 9 个叶子框）；连线类型为 Containment（嵌套包含），9 条一律读作叶子 → 所属组：6 条归 R7、3 条归 R24。
  • R7 叶子清单：D4\.1 退款申请与人工审核、D4\.2 计算时点取权益停止时点、D4\.3 时间比例与费率快照、D4\.4 分类退款范围、D4\.5 退款可追踪不重复、D4\.6 发票线上申请人工开具。
  • 组内语义分层：D4\.1/D4\.5 是流程与重复处理，D4\.2/D4\.3 是金额计算口径，D4\.4 是可退范围，D4\.6 是发票；一个组框同时承载退款与发票两类售后对象。
  • 图上不出现的部分：无支付渠道块、无正向订单块；渠道结果未知时的核实动作不在本图，由 D7 的 D7\.14 幂等与失败处置统一约束。
  • R24 叶子清单：D4\.7 缺页或未知批次判不完整待核实不得称无差异、D4\.8 差异工单未结不得结案、D4\.9 异常收款返还按逐笔上限且不套普通费率。
  • 为何补一组：售后原只有退款与发票两条逆向线；需求中心把渠道对账列为售后的独立职责域，批次完整性自证与差异工单闭环都是可判定的禁止项，塞进 R7 会让一个组框承载三类对象，故单立 R24。

为什么这么设计：退款与发票独立成域：资金逆向流出的主责方与正向交易不同，角色边界要在需求层钉死。

  • 归域依据：映射表 D4←R7（DEC\-07）。客服受理、财务审核、执行退款三种角色都不等同于下单人，与 D3 混画会让谁可审谁的边界含糊，故单独立域。
  • 关键决策与备选：曾考虑按剩余比例自动批准退款，被 D4\.1 否掉（首期不自动批准）；另一条被否的是申请期间先撤销权益，改为确认范围后才联动，因此 D4\.2 取权益实际停止时点而非提交时点。
  • 承接的硬约束：D4\.3 公式为 D=E−S 按实际秒数（不按 30 天折月）、R=max\(0, E−max\(S, C\)\)、B=P×R÷D、F=B×购买时锁定的费率快照，精确到分四舍五入且不超剩余可退；升级退款不扣手续费。
  • 承接的硬约束：D4\.4 只对独立成交商品项退款，项内不拆退部分席位或部分容量；D4\.5 渠道退款结果未知时先核实、重复处理不重复退款。
  • 落地形态 ：refund_application 把 P、S、E、C、D/R 秒、B、费率快照 r、F、退款金额全量落字段，配 invoice_application；操作 applyRefund、calcRefund、executeRefund、applyInvoice。
  • 取舍与代价：发票不做开票系统自动对接，线上申请、人工开具并回传文件；次数型、用量型与永久模块退款规则未定，本层不承诺其可退；已开票订单退款转财务调整发票而不删原记录。

D5 数据生命周期

图上内容描述：D5 数据生命周期分域需求图：3 个需求组、12 条叶子需求，图上 15 个具名符号、12 条连线（全部 Containment）。本轮按《SaaS 需求中心》补 2 组 6 叶------R21 配额预占与容量保护（3 叶：D5\.7\~D5\.9）、R22 争议保全与清理暂停（3 叶：D5\.10\~D5\.12）。

  • 看图口径：15 个具名符号均为 <<需求>>（组框 R6、R21 配额预占与容量保护、R22 争议保全与清理暂停与 12 个叶子框）；连线类型为 Containment（嵌套包含），12 条全部读作叶子 → 所属组：6 条归 R6、3 条归 R21、3 条归 R22。
  • R6 叶子清单：D5\.1 到期只读与原始数据取回、D5\.2 保留期与受控清理、D5\.3 仅容量超额只限新增占用、D5\.4 注销与解散撤回期、D5\.5 独立部署不自动删除、D5\.6 商业与审计记录独立留存。
  • 组内语义分层：R6 内 D5\.1/D5\.2 是到期后政策、D5\.3 是超额政策、D5\.4 是主动注销、D5\.5 是独立部署例外、D5\.6 是留存边界，五条输入条件共用一条生命周期状态机；R21 把「写入之前」的额度判定独立成组，R22 把「删除之前」的保全闸门独立成组，三组同域不同判据。
  • 图上不出现的部分：无容量计量块与权益实体块；上限的实际判定在 D2 的计量上报侧，本图只写到期与超额各自限制哪些操作。
  • R21 与 R22 叶子清单：R21：D5\.7 先预占再写入后结算且同键幂等、D5\.8 仅超额只禁新增占用不触发清理、D5\.9 平台容量保护与客户超额分列不得互称；R22：D5\.10 争议或法定保全期间暂停删除并可恢复、D5\.11 归属不明的数据集不得自动清理、D5\.12 关闭预检查不到必须返回未知而非空列表。
  • D5\.3 与 D5\.9 的分界：D5\.3 说客户侧超额只限新增占用、不触发清理；D5\.9 说平台容量保护（CPU/队列/带宽）与客户超额是两套状态、不得互称------同域分列才不会被实现成同一个开关。

为什么这么设计：到期不等于删除：这是一套独立状态机与批处理政策，与商业权益解耦后才有可验收口径。

  • 归域依据：映射表 D5←R6（DEC\-06）。保留期、宽限期、清理与备份轮转属数据政策，续费只是取消其中一步，所以不从属于 D3 的周期算法。
  • 关键决策与备选：备选是到期即冻结、30 天后删除，被 S00 否为 90 天保留 \+ 30 天宽限、业务删除后备份最迟 30 天随轮换清除；主动注销也明确不叠加 90\+30，只用独立 30 天撤回期。
  • 承接的硬约束：D5\.1 到期后停新建、编辑保存与导入新增，但经授权仍可查看与取回原始数据、不要求先续费，且取回不绕过授权（权限服务故障时 D1\.16 保守降级优先）。
  • 承接的硬约束：D5\.3 仅容量超额只禁止新增存储占用的操作（含会产生新版本的保存），不触发全项目清理；D5\.5 独立部署不因 License 到期自动删除客户数据。
  • 落地形态 ：lifecycle_state / purge_record / closure_request / data_takeaway_request 等五张表，配 getRetentionStatus、requestTakeaway、requestClosure、executePurge 操作。
  • 验收与留痕 ：批侧由 XXL\-Job 的 lifecycle\-transition、purge\-execute、closure\-window 推进，清理须留 purge_record 与审计；S00\-AC\-06 核 90\+30 与备份 ≤30 天，D5\.6 要求订单、退款与审计记录不随项目内容删除。

D7 平台运营治理

图上内容描述：D7 平台运营治理分域需求图：21 个需求组、70 条叶子需求，图上 91 个具名符号、70 条连线（全部 Containment）。OPS v1\.9 这轮再补 15 组 45 叶------R28 运营平台边界与能力 至 R42 运营侧非功能与验收，叶子编号续到 D7\.70。

  • 看图口径：31 个具名符号均为 <<需求>>（R9、R11、R12、R25 通知模板与投递、R26 全链路验收与证据、R27 性能与容量基线六个组框 \+ 25 个叶子框）；连线类型为 Containment（嵌套包含），方向叶子 → 组：5 条归 R9、5 条归 R11、6 条归 R12、各 3 条归 R25/R26/R27。
  • R9 独立部署与License（5 叶）：D7\.1 实例与租户绑定、D7\.2 期限授权与永久授权、D7\.3 高版本完整快照导入、D7\.4 离线有效与撤销凭证、D7\.5 时钟回拨与环境异常。
  • R11 运营配置发布与下架（5 叶）：D7\.6 逐版本配置权益、D7\.7 发布不审批但须校验、D7\.8 变更走新版本并留快照、D7\.9 下架仅停新购、D7\.10 关键操作留痕。
  • R12 一致性约束与优先关系（6 叶）：D7\.11 四主体主责分离、D7\.12 交易三段分离、D7\.13 时间与容量权益独立、D7\.14 幂等与失败处置、D7\.15 参数不取默认值日志不敏感、D7\.16 状态组合优先关系。
  • 关键连线：25 条 Containment 与 25 叶一一对应、无叶子互连；R12 一组独占 6 条且全是对其它五域的横切约束，R26/R27 又把验收与性能基线的判定收在治理侧，本图因此同时充当交付治理域与全局约束的落点。
  • 图上不出现的部分：无部署实例块、无外部参与者、无跨域引用块；License 与发布动作的执行方只在需求文字里约定，本层不画结构。
  • 需求中心三组（9 叶）：R25 通知模板与投递（D7\.17\~D7\.19）、R26 全链路验收与证据（D7\.20\~D7\.22）、R27 性能与容量基线（D7\.23\~D7\.25），本域合计 6 组 25 叶。
  • 三组点名：R25：通知意图按事件版本与接收者去重、每类通知每部署责任域只一个现行模板版本、投递失败沿原意图受控重试不回滚业务事实；R26：复测必须新建执行并保留上次失败记录、执行须绑定来源修订与构建产物摘要、文档原型集成安全性能专业审核六层分别出结论；R27：负载画像十维未签认不得填零或无限制、基线项区分候选已签认与实测结果、计费量与物理量分开错放行为功能阻断。

为什么这么设计：D7 收 R9/R11/R12：License 与发布共用签发、留痕、审计设施，横切约束也需要有主责域认领。

  • 归域依据：映射表 D7←R9,R11,R12（DEC\-09 \+ DEC\-11 \+ BR\-001\~006）。R9 原拟单列为 D6 独立部署与 License 域，2026\-09\-23 六域定版并入 D7、D6 编号本轮不占。
  • 归域依据 ：并入的理由是 License 签发与导入属交付治理动作，与运营配置发布共用同一套签发、留痕与审计设施（audit_log 主责也在 D7），不为它单设业务域。
  • 归域依据：R12 的一致性约束自身没有业务流程，散落到各域就无人认领验收，挂在负责参数管控与审计的运营治理域下才有主责方，这是它进 D7 而非独立横切域的原因。
  • 关键决策与备选：D7\.7 明确发布不审批但须校验，否掉首期上版本发布审批流的备选（系统做完整性、合法性、一致性校验属数据校验，不是人工审批），同时钉住退款审核、开票处理、License 迁移审核不受该豁免影响。
  • 承接的硬约束 ：D7\.1 绑定独立部署实例 \+ 团队租户、不强绑单机硬件、签发私钥不入交付包；D7\.3 先完整校验再整体替换、失败保留原授权、重复导入不增权、旧版本不回退；D7\.14 对应 grant.idempotency_key。
  • 验收与留痕：S00\-AC\-08 用导入失败、重复导入、旧版重放三场景核 D7\.3；D7\.10 要求配置、发布、下架、订单关闭记操作者、原因与结果；售价、额度、费率与并发席位按 D7\.6 只留配置位不填值。
  • OPS v1\.9 十五组（45 叶）：R28（3 叶）；R29（3 叶）；R30（3 叶）；R31（3 叶）；R32（3 叶）；R33（3 叶）；R34（3 叶）；R35（3 叶）；R36（3 叶）；R37（3 叶）；R38（3 叶）；R39（3 叶）；R40（3 叶）；R41（3 叶）；R42（3 叶）
  • 十五组逐组点名：R28 运营平台边界与能力（D7\.26、D7\.27、D7\.28）：运营平台只交付六类业务对象与独立治理入口、延期能力编号不复用且事实仍由来源服务留存、页面不得把加载失败或未授权伪装成空值与成功；R29 后台人员治理与账号生命周期（D7\.29、D7\.30、D7\.31）：受控初始化首个超级管理员仅成功一次且未知查原操作、邀请须经本人身份核验接受且旧令牌不继承授权、禁用撤销后台资格并失效会话恢复须本人重验且不得禁用最后有效管理员；R30 可信功能动作目录与角色范围（D7\.32、D7\.33、D7\.34）：功能动作须由研发登记可信标识与守卫界面输入不得创建动作、角色只有一个平台范围且发布后不可跨范围迁移、超级管理员治理身份不自动获得客户业务动作权限；R31 权限模板发布与影响预览（D7\.35、D7\.36、D7\.37）：发布须经草稿校验影响预览确认读回五步并逐版本绑定、任一版本变化非法动作或职责越权阻止发布、被商品订单席位或后台绑定引用的角色禁止物理删除；R32 通用字典与引用保护（D7\.38、D7\.39、D7\.40）：协议类型与权益周期取自启用字典项且随版本冻结语义、周期语义由基本单位与倍率显式保存不得由显示标签计算、字典条目被引用后只能停用或出新版本且旧引用按快照读取；R33 建模用户账号治理（D7\.41、D7\.42、D7\.43）：账号状态与团队成员关系分开读取且已注销不可复活、启用禁用须填原因带来源版本并按原操作读回、关联依据按稳定主体标识标注不得凭姓名或手机号推断；R34 空间运营管控与分区读回（D7\.44、D7\.45、D7\.46）：空间生命周期权益席位存储四分区独立加载独立降级、暂停恢复须原因带生命周期版本并展示影响预览、运营不得代建认领关闭团队或访问项目与模型内容；R35 商品三段与不可变版本（D7\.47、D7\.48、D7\.49）：商品目录不持久保存草稿编辑仅存在于提交前的工作副本、商品版本冻结成员上限多类型角色席位与项目存储额度、现行发布指针原子切换且停售只阻止新购买不改成交快照；R36 赠送商品受众与领取资格（D7\.50、D7\.51、D7\.52）：赠送商品原价现价必须为零且周期单位与次数统一、受众取全部用户或稳定用户标识名单并随版本锁定、同商品同受益空间至多成功领取一次且未知只查原操作；R37 跨产品主套餐升级（D7\.53、D7\.54、D7\.55）：升级只替换用户选中的旧主套餐且目标已有有效主套餐拒绝、支付确认先于主套餐切换且旧余款按成交条款免手续费退款、交易权益财务各自保留源操作不得宣称跨库共同事务；R38 订单查询与原支付核实（D7\.56、D7\.57、D7\.58）：订单列表按提交人付款人与受益空间三主体组合筛选、同一订单多关联只出现一行并显示关联依据、支付未知只查原尝试不得代客户付款或手工标记成功；R39 订单内运营发起退款（D7\.59、D7\.60、D7\.61）：运营在原订单详情内直接发起普通退款且用户申请不是前置条件、权益来源实际停止确认后才按成交费率核算并进入渠道、核算零分不出款未知保留预留且不得换键重出；R40 发票开具事实与原件（D7\.62、D7\.63、D7\.64）：发票只由合格申请人沿原订单申请运营不代建申请、真实开具事实先持久化首次附件就绪才标记已开具、已开具后原件故障只修同一附件不改发票历史且下载逐次重鉴权；R41 协议类型实例与发布指针（D7\.65、D7\.66、D7\.67）：每个稳定协议类型至多一个实例且类型来自启用字典、取消发布清空指针不自动回退历史且显式重发同一不可变正文、已发布正文不可编辑且运营不代替用户确认协议；R42 运营侧非功能与验收（D7\.68、D7\.69、D7\.70）：每个变更保留操作者前后版本原因操作号来源与结果、空值长度极值与未知按字段契约逐项校验并指出字段、列表详情与写受理按候选性能基线实测后方可判通过
  • 本轮定档 ：超级管理员不自动 拥有业务动作权限（治理身份与业务资格分离，落进 R30 与 R31）；商品目录不保留持久草稿（编辑态只在页面工作副本，校验失败整次拒绝，落进 R35）。
  • 配图状态 ：需求图\-D7 画布本轮已重排（R 组与叶按真实尺寸落位、图框扩到包住内容），本节的原生导出图仍是上一轮产物，待重导。

功能分析

本层对应 M\-Design「02功能分析」包的 6 张分域用例图。全模型 9 个参与者：个人用户、团队所有者、团队管理员、账单管理员、普通成员、平台运营、交付与签发人员、支付渠道、主体软件（M\-Design）；用例按六个业务域分组落图，Include/Extend 均以 connectShape 一步建模型加连线（关系模型唯一，无 treeDrop 复制件）。

D1 身份与组织

图上内容描述：D1 身份与组织用例图：5 个执行者配 24 个用例，符号 29 / 连线 34，其中实线关联 27、Include 5、Extend 2；本轮新增 2 条用例。

  • 看图口径：<<执行者>> 5 个------个人用户、团队所有者、团队管理员、平台运营、主体软件；<<用例>> 24 个。关联按"执行者 → 用例"读作该角色可发起；Include/Extend 是用例之间的虚线关系并带构造型标签。
  • 个人用户段：个人用户挂 12 个用例：注册并生成个人空间、验证码登录并自动建号、密码登录、发送一次性验证凭证、找回登录凭证、变更绑定手机号、管理会话与设备、注销账号与撤回、查询身份状态、切换空间、查看我同意的协议、接受团队邀请。
  • 其余执行者：团队所有者 4（开通并认领团队、发起所有权转让、接受所有权转让、授予或撤销团队角色）、团队管理员 3（邀请并移除成员、授予或撤销团队角色、配置角色资源授权）、平台运营 6（开通并认领团队、发布协议版本、维护权限资源、维护权限组、初始化租户权限、签发受控治理上下文）、主体软件 2（查询身份状态、按资源校验接口访问）。
  • 权限管控五条：平台运营挂维护权限资源、维护权限组、初始化租户权限；团队管理员挂配置角色资源授权；主体软件挂按资源校验接口访问。资源与权限组的定义权只在平台侧，租户只能在本租户角色上配置授权。
  • Include 五条：五条 Include 里有四条的终点都是"发送一次性验证凭证"，基用例分别是验证码登录并自动建号、找回登录凭证、变更绑定手机号、注销账号与撤回------发码动作被四个流程复用而不各画一遍；第五条从"按资源校验接口访问"指向"查询身份状态"，接口鉴权先确认身份与生效范围，再匹配资源。
  • Extend 两条：一条从"验证码登录并自动建号"指向"注册并生成个人空间"：自动建号是注册在验证码登录场景下的扩展，图上因此不给"先注册再登录"留第二条入口；另一条从"初始化租户权限"指向"开通并认领团队"，权限初始化只在建租户时发生，不另开一条主流程。
  • 关键连线：27 条关联里"开通并认领团队""授予或撤销团队角色"各由两个执行者共享；"发送一次性验证凭证"既有个人用户的直接关联又被 4 个基用例 Include，是本图的汇聚点；权限管控五条用例各由单一执行者挂接，不与存量用例共用角色边。
  • 边界与缺席：账单管理员、普通成员、交付与签发人员、支付渠道等执行者在本图零连线；"发布协议版本""维护权限资源""维护权限组""初始化租户权限"只挂平台运营，"配置角色资源授权"只挂团队管理员，"查看我同意的协议"只挂个人用户；资源与权限组是平台级定义，租户侧碰不到定义本身，只能给本租户的角色配授权。
  • 本轮新增两条：签发受控治理上下文只挂平台运营（D1\.46\~D1\.48：治理凭证由平台签发、业务侧逐请求校验）；接受团队邀请只挂个人用户（D1\.49\~D1\.51：先有接受动作才有成员资格）。两条都不与存量用例共用角色边。
  • 为何不再抽 Include：治理上下文校验与邀请接受都只在各自的一条主流程里发生一次，不像发码那样被四条流程复用，因此不建 Include 汇聚点，判据留在用例内部。

为什么这么设计：账号动作、权限管控动作与治理/邀请动作补进来后 D1 用例从 7 个涨到 24 个，靠 Include 收敛发码与身份状态确认、靠 Extend 表达自动注册与权限初始化，才不会把同一个安全动作画成五份。

  • 归域依据：账号侧 10 个新用例守 D1\.18\~D1\.36：注册与自动建号、发码与登录、会话与设备管理、找回与改绑、注销与撤回、身份状态查询、协议阅读与发版；权限侧 5 个新用例守 D1\.37\~D1\.45：资源与权限组维护、建租户时初始化、本租户角色授权配置、逐请求资源校验。
  • 关键决策与备选：否掉"把发码写进每个用例的前置条件"------抽成"发送一次性验证凭证"并 Include，验收只测一处频控与一次性消费；否掉"自动注册单列用例"------用 Extend 挂在验证码登录并自动建号上，保留自动注册边界与同意串联；否掉"注销即删"------"注销账号与撤回"是一个用例，撤回期落在用例内部。
  • 承接的硬约束：主体软件作为执行者只连"查询身份状态"，能问状态但点不到任何账号写操作；个人用户可发起改绑、注销与会话管理，但发版只在运营侧；转让两条边仍只连团队所有者，管理员可邀人移人、授撤角色但不能接手团队。
  • 验收与留痕：计数可核对：24 用例、27 关联、5 Include、2 Extend；两处 Include 汇聚点与两条 Extend 各自可数，评审按"同一安全动作只画一处"验收。
  • 取舍与代价："管理会话与设备""查询身份状态"按用例粒度合并，代价是接口侧 revokeSession/listSessions 与 queryIdentityState/queryOperationResult 的四条操作在图上看不出一对多映射，拆分留在接口设计层。

D2 商品与权益

图上内容描述：D2 商品与权益用例图：6 个执行者配 7 个用例，符号 13 / 连线 12，其中实线关联 11、Include 1、Extend 0；本轮新增 1 条用例。

  • 看图口径：标题即「02功能分析/D2」域包；<<include>> 读「基础用例 → 必含子用例」，箭头指向必含子用例。
  • 本图参与者：出现个人用户、团队所有者、团队管理员、账单管理员、普通成员、平台运营 6 个；支付渠道、主体软件、交付与签发人员零连线。
  • 用例清单（激活与确认）：个人用户------激活个人试用、校验试用双重去重资格、浏览可售权益版本、查看有效权益与额度；团队所有者------激活团队试用并绑定席位、确认席位保留名单。
  • 用例清单（查看）：账单管理员------浏览可售权益版本；团队管理员------查看有效权益与额度、查看席位使用量；普通成员只连查看有效权益与额度。
  • 关键连线：唯一虚线为激活团队试用并绑定席位 → 校验试用双重去重资格；激活个人试用不入 include，校验用例反被个人用户与平台运营直连。
  • 新增一条用例：确认席位保留名单由团队所有者发起（D2\.6 降额超限须当前所有者确认，D2\.8 零额度只可确认空名单）；团队管理员与账单管理员都不挂这条边，避免系统或运营替客户挑选保留席位。

为什么这么设计：试用资格判定被抽成独立用例复用，权益与席位查看按角色分档开放。

  • 归域依据：6 条试用与权益用例落 D2\.1\~D2\.5（DEC\-04）：默认配额 7 天、个人 100MB、团队 200MB、3 项目；激活绑定最新版、个人一次性、团队双重去重、区间算法。第 7 条确认席位保留名单守 D2\.6\~D2\.8（R23），与试用同域是因为共用同一套 plan\_version 与席位对象，而不是同一条规则。
  • 关键决策与备选：校验试用双重去重资格从激活流程抽成独立用例，被团队轨 include、被个人与运营直连复用；否掉的备选是把判定内联进两条流程，那样 D2\.3 与 D2\.4 要各写一份规则。
  • 承接的硬约束：个人轨没画 include 边，靠个人用户对校验用例的直连表达同一判定入口；运营那条边是后台人工复核路径，对应 S00\-AC\-11 团队维与人员维分别阻止重复获取；并发席位与协作首期不做。
  • 验收与留痕：激活团队试用并绑定席位只连团队所有者（DEC\-03 最多 3 席且含所有者）；查看席位使用量只连团队管理员；账单管理员可浏览版本但不可激活试用（D1\.9 账单角色不越权）。

D3 交易与履约

图上内容描述：D3 交易与履约用例图：6 个执行者配 10 个用例，符号 16 / 连线 18，其中实线关联 15、Include 3、Extend 0；本轮新增 0 条用例。

  • 看图口径：标题即「02功能分析/D3」域包；include 读「基础用例 → 必含子用例」，支付渠道与主体软件在边界外。
  • 本图参与者：出现 6 个：个人用户、账单管理员、团队所有者、平台运营、支付渠道、主体软件；其余三角色零连线。
  • 用例清单（买家）：账单管理员 6 条边------创建订单并指定受益空间、发起支付尝试、续购同套餐、询价升级、升级替换权益、增购模块或扩容；个人用户连前两项、团队所有者连末项。
  • 用例清单（运营与外部）：平台运营 4 条边------核实支付结果、授予权益、登记合同并核销到账、按合同人工配置授予；支付渠道与主体软件分别连前两项。
  • 关键连线：include 依次为创建订单并指定受益空间 → 核实支付结果 → 授予权益、升级替换权益 → 询价升级；发起支付尝试无虚线。

为什么这么设计：两条轨只在钱怎么进来这段分叉，来源统一在授予权益这一用例合流，下游鉴权只有一套。

  • 归域依据：10 个用例守 D3\.1\~D3\.9（R5 续购升级 \+ R8 首发仅手动）；增购模块或扩容单列而不并入升级，正是 D3\.7 要求模块与扩容独立、不随主套餐续购连带。
  • 关键决策与备选：登记合同并核销到账与按合同人工配置授予拆成两个可复用用例，核销后的授予记为 MANUAL\_CONFIG；被否的备选是合同直变订阅，那会多出第五种 Grant 来源。
  • 承接的硬约束：三条 include 各守一条规则------下单必含核实（BR\-003 三段分离，超时不等于失败）、核实必含授予（支付成功不等于履约完成）、换单必先询价（DEC\-05）。
  • 验收与留痕：授予权益的两条角色边只来自平台运营与主体软件，客户侧无一条自授权边；再拿 grant 幂等键核重复通知不重复授予（BR\-005），拿订单快照核成交锁定。

D4 售后与财务

图上内容描述：D4 售后与财务用例图：4 个执行者配 6 个用例，符号 10 / 连线 12，其中实线关联 11、Include 1、Extend 0；本轮新增 1 条用例。

  • 看图口径：标题即「02功能分析/D4」域包；<<include>> 方向是「申请 → 必含的审核执行」，不可反读为审核包含申请。
  • 本图参与者：出现个人用户、团队所有者、账单管理员、平台运营 4 个；团队管理员、普通成员、支付渠道、主体软件、交付与签发人员零连线。
  • 用例清单（申请侧）：个人用户 4 条边------申请退款、申请发票、上传并下载发票、查看退款与发票进度；账单管理员连申请退款、申请发票、查看进度；团队所有者只连申请退款。
  • 用例清单（处理侧）：平台运营 3 条边------审核并执行退款、上传并下载发票、处理对账差异工单；上传并下载发票一用例两条边，运营上传、用户下载共用同一单据。
  • 关键连线：唯一 include 为申请退款 → 审核并执行退款；申请发票与上传并下载发票之间无连线，审核并执行退款只有一条角色边。
  • 新增一条用例：处理对账差异工单只挂平台运营（D4\.7 缺页或未知批次判不完整待核实、D4\.8 差异工单未结不得结案）；客户角色零条边，对账是平台侧财务动作，不向客户开放处置入口。

为什么这么设计：首期人工审核边界画进模型：申请与审核执行分两用例，执行端只留给平台运营。

  • 归域依据：6 用例，其中 5 条退款与发票用例守 D4\.1\~D4\.6（DEC\-07），新增的处理对账差异工单守 D4\.7\~D4\.9（R24）；退款是资金逆向流出，客服受理、财务审核与正向付款人权限不同批，独立成域才钉得死职责边界。
  • 关键决策与备选：include 取「申请退款 → 审核并执行退款」，表达申请必然进入人工审核；被否的备选是自动退款一步到位与把审核画成可选支路------DEC\-11 发布不审批不等于取消退款开票人工处理。
  • 承接的硬约束：时点取权益实际停止时点 C 而非申请提交时点（D4\.2）；D=E−S 按实际秒、B=P×R÷D、F=B×购买时锁定费率，不超剩余可退（D4\.3）；渠道未知先核实（D4\.5）。
  • 验收与留痕：执行端只有平台运营、客户角色无审核边；但 D4\.1 与 D4\.6 均写团队由所有者或账单管理员申请，图上申请发票与查看进度未连所有者，评审须补边；项内不拆退席位（D4\.4）、不对接开票系统。

D5 数据生命周期

图上内容描述：D5 数据生命周期用例图：5 个执行者配 7 个用例，符号 12 / 连线 13，其中实线关联 12、Include 0、Extend 1；本轮新增 2 条用例。

  • 看图口径：标题即「02功能分析/D5」域包；<<extend>> 方向是扩展用例 → 基础用例，箭头指向被附加行为的用例，与 include 读法相反。
  • 本图参与者：出现个人用户、普通成员、团队所有者、平台运营、主体软件 5 个；团队管理员、账单管理员、交付与签发人员零连线。
  • 用例清单（客户侧）：个人用户 4 条边------查看到期与保留状态、取回原始项目数据、申请注销或解散、撤回注销；普通成员只连前两项。
  • 用例清单（解散与执行）：团队所有者------申请注销或解散、撤回注销；主体软件------取回原始项目数据、申请与结算配额预占；平台运营------执行数据清理、处理争议与保全暂停，两条都没有客户角色参与。
  • 关键连线：唯一 extend 为取回原始项目数据 → 查看到期与保留状态；执行数据清理与其余四用例间无任何连线，两端只由状态机衔接。
  • 新增两条用例：申请与结算配额预占挂主体软件（D5\.7 先预占再写入后结算且同键幂等，写入前的额度判定由主体软件发起、平台只做判定）；处理争议与保全暂停挂平台运营（D5\.10 保全期间暂停删除并可恢复，D5\.11 归属不明不得自动清理）。

为什么这么设计：把「到期不等于删除」这套独立状态机的两端画进同图，客户动作与受控动作靠边隔开。

  • 归域依据：7 个用例，存量 5 条守 D5\.1\~D5\.6（DEC\-06），本轮两条新增分守 D5\.7\~D5\.9（R21 配额预占与容量保护）与 D5\.10\~D5\.12（R22 争议保全与清理暂停）；都是与商业权益解耦的独立状态机与批处理，故不挂回 D2/D3，商业与审计记录独立留存单列在 D5\.6。
  • 关键决策与备选：取回画成查看到期与保留状态的 extend 而非必含子行为------取回只在到期或注销成立且资源权限仍有效时附加发生；被否的备选是把取回并入查看用例，那会丢掉「取回不绕过授权」的独立判定。
  • 承接的硬约束：90 天保留 \+ 30 天宽限、删除后备份最迟 30 天清除；注销走独立 30 天撤回期不叠加 90\+30；遇权限服务故障按 D1\.16 保守降级优先。
  • 落地形态：生命周期接口的 8 个操作 getRetentionStatus 到 listPurgeHolds 逐一对应用例；模型资产不进平台，打包由主体软件执行，删除写清理记录与审计日志。

D7 平台运营治理

图上内容描述：D7 平台运营治理用例图：9 个执行者配 35 个用例，符号 44 / 连线 39（实线关联 38、Include 0、Extend 1）。OPS v1\.9 这轮新增 3 个执行者（超级管理员、后台人员、部署授权责任人）与 20 个用例。

  • 看图口径：标题即「02功能分析/D7」域包，实线是角色发起、虚线 extend 指向被扩展用例。
  • 本图参与者：出现平台运营、主体软件、交付与签发人员、团队所有者、个人用户、普通成员。
  • 用例清单（运营簇）：平台运营------配置权益包版本、发布权益包版本、下架权益包版本、管控租户冻结与解冻、发布公告、维护客户端版本（主体软件版本包）、发布通知模板、登记验收执行与证据、签认性能与容量基线。
  • 用例清单（License 簇）：交付与签发人员------导入License、报告时钟与环境异常；团队所有者------导入License、查看授权状态。
  • 用例清单（运行时簇）：主体软件------校验能力与席位、上报实际占用量、消费授权变更并降级；普通成员连校验、个人用户连降级。
  • 关键连线：唯一 extend 为消费授权变更并降级 → 校验能力与席位；运行时三用例无连线。
  • 新增三条用例：发布通知模板守 D7\.18（每类通知每部署责任域只一个现行模板版本）；登记验收执行与证据守 D7\.20/D7\.21（复测必新建执行、执行绑定来源修订与产物摘要）；签认性能与容量基线守 D7\.23/D7\.24（十维画像未签认不得填零或无限制）。三条都是平台运营单边，客户与主体软件无入口。

为什么这么设计：版本治理、租户管控、License 与授权消费共用签发审计设施。

  • 归域依据：15 用例覆盖 D7\.1\~D7\.25：D7\.1\~D7\.5（DEC\-09）是 License 簇，D7\.6\~D7\.10 是运营簇，D7\.11\~D7\.16（BR\-001\~006）是横切约束的认领主责，D7\.17\~D7\.19 通知、D7\.20\~D7\.22 验收证据、D7\.23\~D7\.25 性能与容量基线三条新簇都挂平台运营；D6 已并入。
  • 关键决策与备选：配置与发布拆成两用例守 D7\.7：配置完整即直接发布、发布这步仍做校验留痕；被否备选是配置即发布，会吞掉发布校验记录；下架独立成用例守 D7\.9 只停新购。
  • 承接的硬约束：消费授权变更并降级以 extend 挂校验能力与席位，表达只在读不到最新 epoch 时附加发生（D1\.16）；备选是每次必含降级，会掩盖暂不可用异常态。
  • 验收与留痕：运营侧九件事只有平台运营有边；导入 License 双人但签发私钥不入交付包、客户不得自签扩权（D1\.10）；鉴权内嵌 saas\-core 用户域（无独立网关），异常与关键操作入审计。
  • 新增执行者：超级管理员（治理面唯一入口）、后台人员（被邀请并激活后的运营经办身份）、部署授权责任人（受控初始化首个超级管理员的外呼责任人）。
  • 用例清单（超级管理员 发起）：配置发布固定角色权限模板、添加后台人员并邀请激活、禁用或申请恢复后台人员、分配后台人员多角色、维护可配置角色权限模板、维护通用字典与条目、维护可信功能动作目录。
  • 用例清单（后台人员 发起）：后台人员独立登录。
  • 用例清单（平台运营 发起）：编辑并保存协议草稿、校验并发布协议版本、替代停用或归档协议版本、查询并治理建模用户账号、查询并治理空间生命周期、维护商品三段与不可变版本、查询订单并核实原支付结果、在订单内发起普通退款、处理发票申请开具事实与原件、维护赠送商品受众与领取资格、办理跨产品主套餐升级核实。
  • 用例清单（部署授权责任人 发起）：受控初始化超级管理员。
  • 本轮定档：超级管理员默认只有治理动作，业务动作须经角色模板显式授予（X2 以需求为准）；商品侧用例不再有「保存草稿」入口，编辑与校验在一次发布操作内完成（X3）。
  • 配图状态 ：用例图\-D7 画布本轮已重排（三个新 Actor 各占一行、20 个用例按真实椭圆尺寸成簇落位），本节原生导出图待重导。

概要设计

部署设计

技术部署设计

图上内容描述：公有云 SaaS 部署拓扑以 BDD 呈现，15 个 <<模块>> 符号、13 条 Association 连线，表达从浏览器到中间件的完整运行时实例分布。

  • 看图口径：所有符号构造型均为 <<模块>>，每条 Association 的文字标注即为协议或机制说明（JDBC、HTTPS、回调\(验签\) 等）；方向 = 发起方 → 被调用方；'ACK集群框架' 与 '公有云' 是图上两个容器/分组块，框住内部署单元。
  • 外部流量入口三节点：用户/运营浏览器、主体软件\(M\-Design网页端\)、支付宝\(支付渠道\) 各一条线汇聚到 '接入层\(WAF·CDN·OSS·ALB Ingress\)'，标注分别为 HTTPS、API/协同连接、回调\(验签\)------接入层把三路合流后以第 13 条连线 '唯一北向入口\(内嵌鉴权:会话\+epoch比对\)' 送入 saas\-core。
  • ACK 工作负载四节点：业务单体 saas\-core\(3副本\+弹性\)、运营后台 saas\-ops\-console\(2副本\)、调度中心 xxl\-job\-admin\(2副本\)、定时任务执行器 saas\-job\-executor\(2副本\)；无独立鉴权网关节点------鉴权仅在接入层→core 的连线标注中出现。
  • 云中间件五节点：Redis 双副本、RocketMQ 5\.x、密钥管理KMS\+访问控制RAM\(存License签发私钥\)、日志服务SLS\+云监控ARMS\(脱敏/撤权延迟打点\)、以及数据库节点（图面无名，由 JDBC/HikariCP 与批量标注确认为 RDS MySQL）。
  • 关键连线：13 条 Association 中决定拓扑语义的三条------接入层→saas\-core 标 '唯一北向入口\(内嵌鉴权:会话\+epoch比对\)'；saas\-core→RocketMQ 标 'outbox事务投递；撤权广播\(core内消费,幂等,P95\<5s\)'；saas\-core→KMS 标 '签发调用\(私钥不出KMS\)'。
  • 面板与副本规格：saas\-core 3 副本\+弹性、ops\-console/admin/executor 各 2 副本、Redis 双副本；执行器→数据库标注 '批量\(90\+30清理/对账\)' 说明离线批任务与在线请求分离；admin→executor 标 '注册/派发\(accessToken\)'。

为什么这么设计：beta 阶段以单一业务单体 \+ 云托管中间件交付，否掉微服务拆分与独立鉴权网关，用最少 Deployment 守住 S00 全部硬约束。

  • 关键决策与备选：层 5 八个逻辑服务按 Java 包分模块而非拆微服务------被否方案是 Spring Cloud 微服务拆分，否决原因：beta 用户量与团队规模不支撑服务网格运维成本，单体 \+ 包隔离已满足 3 副本水平扩容需求。运营后台/调度中心独立则因为故障域不同。
  • 关键决策与备选：2026\-09\-23 拍板将原 saas\-authz\-gateway 合并进 saas\-core 用户域（内嵌鉴权过滤器）------被否方案是独立鉴权网关组件；收益是少一跳转发与一份 Deployment 运维，代价是鉴权与业务同进程同扩缩，撤权 5 秒时效需从业务链路中用埋点日志单独切出证明。
  • 承接的硬约束：S00 R10\.1/R10\.2 撤权 5 秒→连线标注 'outbox事务投递；撤权广播\(core内消费,幂等,P95\<5s\)' 即 RocketMQ 广播 \+ Redis epoch 秒级失效 \+ 鉴权过滤器比对；R10\.3 故障保守降级→Redis 连线标注 '会话/epoch读取\(故障→保守降级\)/限流'。
  • 承接的硬约束：R2\.4 私钥不入交付包→连线 '签发调用\(私钥不出KMS\)' 把 License 签名能力锁在 KMS 硬件边界内；R6\.1/R6\.2 到期 90\+30 清理→executor→数据库连线 '批量\(90\+30清理/对账\)' 对应 XXL\-Job purge\-execute 任务；R12\.5 日志不留敏感信息→SLS 连线 '日志/指标\(脱敏前置,含撤权延迟打点\)'。
  • 取舍与代价：双库门禁（MySQL 与达梦 DM8 CI 全绿才合并）增加构建流水线时间，同镜像双形态（SaaS 用 MySQL 方言、私有化用 dm 方言）要求 DDL 成对维护；beta 接受这些代价换取一份代码两套交付、不 fork 的长期可维护性。
  • 验收与留痕：压测场景 '成员撤销→core 鉴权过滤器拒绝写入' P95 \< 5s，证据为 SLS authz\_change\_event 的 emitted→delivered latency\_ms 指标；幂等验收为 RocketMQ 重复消费时 \(space\_id, epoch\) 单调过滤不穿透。

图上内容描述：独立部署内网拓扑以 BDD 呈现，8 个 <<模块>> 符号、6 条 Association 连线，描述客户内网全闭环运行时实例及外部输入物。

  • 看图口径：所有符号构造型均为 <<模块>>，Association 文字标注即机制/协议（离线部署、JDBC、缓存、时钟比对、导入快照、启动授权校验）；方向 = 主动调用/数据流向。
  • 内网运行节点：客户内网容器节点\(私有K8s/containerd\) 为容器基座；租户平台应用\(同镜像,内嵌鉴权过滤器\) 为业务进程------'同镜像' 表示与云端 saas\-core 同一份镜像不同 profile，'内嵌鉴权过滤器' 直接写在节点名称中表明无独立网关；主软件M\-Design\(私有化\) 为建模网页端本地部署。
  • 本地存储节点：达梦DM8\(COMPATIBLE\_MODE=4\) 为业务数据库，MySQL 兼容模式已配置在实例参数上；Redis\(单机,可选\) 为本地缓存，图上标注 '可选' 意味着断缓存不致命。
  • 外部输入物：离线交付包\(Helm\+镜像tar\+达梦初始化脚本\)、License文件\(公钥验签/高版本完整快照\)、NTP时钟源\(回拨检测上报\) 三个节点代表从外网带入内网的物料，通过连线 '接入' 到内网运行节点。
  • 关键连线：6 条连线中语义最重的两条------离线交付包→容器节点 标 '离线部署\(私钥不入包\)'，确认交付物不含签发私钥；主软件→租户平台应用 标 '启动授权校验/epoch\+每请求鉴权\(内嵌\)'，确认鉴权为应用内嵌机制而非网络层代理。
  • 面板标注补充：租户平台应用→达梦DM8 连线标 'JDBC\(dm方言,双库门禁\)'------同时揭示 ORM 方言选型与 CI 门禁策略；License文件→应用 标 '导入快照\(失败保留原授权\)' 即 R9\.3 高版本完整快照流程。

为什么这么设计：私有化轨道以同镜像\+profile 切换替代代码 fork，用部署形态本身保证私钥安全与达梦兼容，代价由双库门禁机制兜住。

  • 关键决策与备选：被否方案是 '私有化 fork 一套代码'------否决原因：双份代码无法同步业务迭代且鉴权逻辑容易漂移。选定方案：同一镜像、不同 Spring profile 切库方言和启动配置，部署图上 '租户平台应用\(同镜像,内嵌鉴权过滤器\)' 名称本身即表达此决策。
  • 承接的硬约束：R2\.4 签发私钥不入交付包→连线标注 '离线部署\(私钥不入包\)'；License文件只含公钥验证能力（'公钥验签/高版本完整快照'），私钥签名永远留在云端 KMS，客户侧即使拿到包也无法自签或扩权。
  • 承接的硬约束：NTP时钟源→主软件 标 '时钟比对\(回拨→只读\+审计\)'------对应 R9\.4 时钟回拨防护，部署上以独立时钟源而非系统时钟做基准，主软件检测到异常后降级只读并产生审计事件。
  • 承接的硬约束：R10\.1 撤权即时生效在私有化下由 '启动授权校验/epoch\+每请求鉴权\(内嵌\)' 实现------License 快照携带 epoch 值，主软件每请求在内嵌过滤器比对，失败即拒绝写入；与 SaaS 轨机制一致，区别仅在 epoch 分发从 RocketMQ 广播变为 License 导入快照。
  • 取舍与代价：达梦兼容策略（COMPATIBLE\_MODE=4 \+ CI 双库门禁 \+ DDL 成对目录 db/migration/mysql 与 dm）每次变更需 MySQL/DM 两套脚本跑绿才合并，构建时长与发布流程复杂度翻倍；Redis 标注 '单机,可选' 意味着不保证缓存可用性，应用须处理 Redis 缺失场景（保守降级）。
  • 落地形态：离线交付包实际内容是 Helm chart（K8s 编排）\+ containerd 镜像 tar \+ 达梦初始化脚本，部署时 helm install 到客户内网私有 K8s 或裸 containerd 节点；License 通过管理界面人工导入触发 '导入快照\(失败保留原授权\)' 流程。

业务部署设计

业务部署设计为预留视图：将在技术部署（4\.1\.1）之上，按业务域 D1\~D7 组织各域能力在公有云 SaaS 轨与独立部署轨的部署与启用形态（哪些域能力在私有化实例内本地闭环、哪些经 License/授权快照与云端对齐）。当前 M\-Design 模型 03\.1\.2 包为占位，待评审后单独定义。

本节对应 M\-Design「05接口设计/SaaS租户平台」系统块的 IBD（内部模块图）：12 个部件、13 条连接器。

图上内容描述：SaaS租户平台系统块内部部件协同图：12 个部件、13 条连接器，回答「谁和谁直接说话」。

  • 看图口径：本图为 IBD（SysMLInternalBlockDiagram），符号是带 <<属性>> 构型关键字的部件（PartProperty），连线是无向 Connector：两端标签即部件名本身、无附加角色名，一条线读作「两端部件存在直接调用路径」，不表示具体操作调用。
  • 四组 12 部件：三端＝网页前端、建模网页端、运营管理后台；授权收口＝授权运行时服务；六个业务服务＝身份与组织服务、权益与商品服务、交易与履约服务、售后服务、生命周期服务、License 服务；两个外部依赖＝建模引擎服务、支付渠道适配器。
  • 用户侧连线（5 条）：网页前端→授权运行时服务、建模网页端→授权运行时服务、授权运行时服务→身份与组织服务、身份与组织服务→权益与商品服务、权益与商品服务→交易与履约服务。
  • 业务链与出站连线（5 条）：交易与履约服务→支付渠道适配器、交易与履约服务→售后服务、权益与商品服务→生命周期服务、生命周期服务→建模引擎服务、建模引擎服务→建模网页端。
  • 运营与 License 连线（3 条）：运营管理后台→权益与商品服务（套餐配置）、运营管理后台→交易与履约服务（合同核销）、License 服务→权益与商品服务（授权快照落到权益侧）。
  • 读图提醒：运营管理后台在图上不接授权运行时服务；授权运行时服务仅一条出边到身份与组织服务，其余业务服务经由服务链间接触达------「收口」约束的是两个用户端的流量。
  • 面板信息：部件无属性/操作面板，只有名称与 <<属性>> 关键字；操作级契约全部在 05接口设计 各域 InterfaceBlock 上定义。

为什么这么设计：部件粒度镜像部署单元与 8 逻辑服务，用户流量的鉴权收口被画成结构上的唯一通路。

  • 落地形态：12 部件与部署同构------六个业务服务加授权运行时即 saas\-core 内的逻辑服务模块（Java 分包、不拆微服务），运营管理后台对应独立部署的 saas\-ops\-console（页面\+BFF，写操作调 core 的 ops API、权限与 C 端隔离），三端与建模引擎服务、支付渠道适配器是其余端与外部依赖；图上没有比代码更多的东西，防止「模型画微服务、代码是单体」两张皮。
  • 承接的硬约束：用户端无旁路------网页前端、建模网页端唯一的连线终点就是授权运行时服务；鉴权过滤器内嵌 saas\-core 用户域，epoch 比对先于业务代码，撤权 5 秒验收只需证明「端→授权运行时→业务」这一段。
  • 关键决策与备选：曾考虑「授权网关独立域/独立部件、各业务服务各自接鉴权」，2026\-09\-23 定版否掉：鉴权并入 core 后少一跳转发、少一份 Deployment；同时否掉「运营后台也走 C 端授权运行时」，运营侧走独立权限体系。
  • 归域依据：支付渠道适配器是图上唯一出站口（首期仅支付宝），渠道协议被防腐层挡在领域模型外，新增渠道不改业务服务；建模引擎服务只连生命周期服务与建模网页端------项目/模型资产留在主体软件侧，平台不建镜像（范围不做项）。
  • 取舍与代价：鉴权与业务同进程同扩缩、撤权广播需 core 每副本各自消费并按 \(space\_id, epoch\) 单调过滤------GA 前若需独立证明 5 秒时效可原样拆回，部件图随之增删一条线。

流程设计

本层对应 M\-Design「03概要设计/03\.2业务流程设计」包：19 张活动图 \+ 5 张协作图（时序语义），按六个业务域落包（本轮补上原先缺项的 D4 售后与财务）。流程只画跨角色/跨系统的关键链路，域内单步操作不进此层。

D1 身份与组织

团队开通与认领流程

图上内容描述：D1 团队开通与认领活动图：三条 <<分配>> 泳道串起预开通到认领生效，符号 19 / 连线 12。

  • 看图口径：图元关键字 <<分配>>（泳道头）、<<判断节点>>、<<活动起点>>、<<活动终点>>；12 条连线全是 控制流、无对象流，箭头指向后继动作，分支出边上的文字即守卫条件。
  • 泳道分工：三条泳道依序为运营/交付、客户责任人、租户平台；运营/交付段只做"预开通团队租户并指定责任人 → 发送认领通知"。
  • 客户责任人段：做"注册或登录个人账号 → 发起团队认领"，即认领之前账号必须已存在，图面不给未注册者放行入口。
  • 租户平台段：做"校验认领人与预开通记录一致 → 判断 → 创建团队空间并绑定租户 → 团队转为有效状态"，失败支为"提示失败原因并转人工核验"，9 个活动节点至此点名完毕。
  • 判断与守卫：唯一 <<判断节点>>「认领校验通过？」 两条出边------"是：完成认领"进创建团队空间并绑定租户，"否：不计为有效团队"进提示失败原因并转人工核验。
  • 关键连线：12 条控制流里 10 条在命名节点间流转，成功支与失败支共同汇入"记录操作审计留痕"再指向终点，起点到预开通节点另有一条。
  • 起止与规模：<<活动起点>>、<<活动终点>> 各 1 个（含泳道格元共 19 符号），两支收敛为同一审计收口，图面无 fork/join 并发段。

为什么这么设计：认领链路跨运营与客户两侧，且决定团队能否进入有效业务状态，必须单独立图。

  • 归域依据：守 D1\.4（S00 R1\.4）团队预开通须认领，与 DEC\-02"尚未认领的预开通团队不视为有效团队"同源；"团队转为有效状态"节点是图上唯一生效出口。
  • 关键决策与备选：否掉"运营预开通即视为有效团队"的一步开通，那会留下无人对内容负责的客户侧影子数据；也否掉"首个注册成员自动成为所有者"，那样所有权转让与审计归责没有起点。
  • 承接的硬约束：失败支守卫明文写"不计为有效团队"，两支都汇入"记录操作审计留痕"，把 BR\-005 要求的可关联留痕画成图上的强制收口，失败也不许静默返回。
  • 落地形态：tenant\.status 的 PRE\_PROVISIONED/PENDING\_CLAIM → CLAIMED 迁移与 claimTeam 操作；"创建团队空间并绑定租户"即 space 与 tenant 1:1 的写入点。
  • 验收与留痕：按 audit\_log 核认领成功与失败两类结果；认领之前图上没有任何邀请、席位节点，与"未认领团队不得开放 inviteMember/allocateSeat 入口"的验收口径一致。
  • 取舍与代价：失败支只到"转人工核验"即收口，未画客户自助申诉通道，首期靠运营/交付人工处理，代价是时效取决于人力排班。
启动授权校验与epoch降级协作

图上内容描述：D1 启动授权校验与 epoch 降级协同时序图：4 条生命线 11 条消息，符号 25 / 连线 11。

  • 看图口径：符号 25 = 生命线 4 \+ 生命线头 4 \+ 消息端点 17；11 条连线里 CallMessage 6 条、ReplyMessage 5 条，沿生命线纵向位置读时间先后。
  • 片段情况：清单中无 CombinedFragment，本图没有 alt/opt 条件片段，放行与降级两条路径只靠消息标签文字区分。
  • 生命线点名：四条 <<生命线>> 依序为成员网页端、鉴权过滤器\(内嵌core\)、权益与授权服务、运营管理后台；第二条名字自带"\(内嵌core\)"，图上没有独立鉴权网关。
  • 启动段 1--4：1 成员网页端→鉴权过滤器"启动并携带身份与目标空间"；2 →权益与授权服务"查询空间授权快照与epoch"；3 回"返回权益能力席位与epoch"；4 回"下发功能开关与只读标记"。
  • 请求段 5--8：5 网页端→鉴权过滤器"发起写入或导出（带本地epoch）"；6 →权益与授权服务"比对epoch是否最新"；7 回"epoch落后：拒绝放行"；8 回"保守降级并提示服务暂不可用"。
  • 变更段 9--11：9 运营管理后台→权益与授权服务"撤成员或席位后递增epoch"；10 →鉴权过滤器"推送授权变更事件"；11 回成员网页端"5秒内刷新并停止未授权操作"。
  • 跨系统入口：运营管理后台是本图唯一写权限变更的源头，出现在此是为了把撤权动作与刷新终点连成同一条可核对时间线。

为什么这么设计：5 秒撤权时效唯一要证明的链路：启动取快照、每请求比 epoch、变更靠推送，三段同处一条时间线。

  • 归域依据：D1\.15（R10\.2）的 5 秒目标与 D1\.14 即时生效都只在请求路径上成立，消息 11 的标签"5秒内刷新并停止未授权操作"即该验收目标的图上表述。
  • 关键决策与备选：否掉"登录时一次性读取授权快照"------S00 前的旧模型正是如此，撤权后旧会话继续放行，已由每请求 epoch 比对取代；也否掉"只等事件推送不做比对"，消息 2 与消息 6 的主动查询比对是必到步骤。
  • 承接的硬约束：消息 5 显式携带本地 epoch、消息 7 标签为"epoch落后：拒绝放行"，落实"不以旧缓存放行"；消息 8 的"保守降级并提示服务暂不可用"与 D1\.16 同向。
  • 部署口径：否掉独立鉴权网关部署形态------2026\-09\-23 定版把 epoch 比对、降级判定、撤权广播消费整体并入 saas\-core 用户域，鉴权过滤器\(内嵌core\)这条生命线名就是该决策的结果。
  • 落地形态：消息 1--8 落在 core 用户域过滤器（会话校验 \+ 空间级 epoch 比对），epoch 缓存 Redis、变更经 RocketMQ 广播，落后返回 401/403 并带新 epoch。
  • 取舍与代价：鉴权与业务同进程同扩缩，5 秒时效的证明与业务链路耦合；GA 前若需对外独立证明时效或独立扩容，把过滤器平移回独立 Deployment 即可，代码不重写。
席位绑定与释放协作

图上内容描述：D1 席位绑定与释放协同时序图：4 条生命线 12 条消息走完邀请---分配---回收，符号 28 / 连线 12。

  • 看图口径：符号 28 = 生命线 4 \+ 生命线头 4 \+ 消息端点 20；12 条连线含 CallMessage 8 条、ReplyMessage 4 条，纵向位置即时间序。
  • 片段与未画项：清单无 CombinedFragment，故没有 alt/opt 片段；上限不足与重复分配的回退分支未画，图上只有"余量充足并返回席位额度"一条成功回边。
  • 生命线点名：四条 <<生命线>> 为团队管理员、成员、成员与席位服务、权益服务；分配动作在席位服务、上限与额度判断在权益服务，两个服务分离是本图的结构读点。
  • 加入段 1--3：1 团队管理员→成员"邀请加入团队"；2 成员→席位服务"接受邀请建立成员关系"；3 回"通知成员已加入"。
  • 分配段 4--7：4 团队管理员→席位服务"为指定产品分配实名席位"；5 席位服务→权益服务"校验团队空间席位上限"；6 回"余量充足并返回席位额度"；7 回管理员"席位绑定成功"。
  • 三资格判断 8：席位服务→权益服务"成员资格席位资格项目权限分别判断"，按清单顺序落在"席位绑定成功"之后，读作使用期逐次判定。
  • 回收段：9 管理员→席位服务"回收席位（成员退出团队）"；10 →成员"释放席位并停止该产品访问"；11 →权益服务"记录变更并递增空间epoch"；12 回"确认个人空间与其他团队不受影响"。

为什么这么设计：席位链路跨管理员与成员两角色、跨席位服务与权益服务两契约，三资格分离与空间隔离排成时序才看得出先后。

  • 归域依据：D1\.11（R3\.1）实名席位与三资格分离落在消息 8 的一条标签上；D1\.12（R3\.2）团队试用最多 3 席含所有者，由消息 5 的上限校验给出，上限取 plan\_version\.seat\_count。
  • 关键决策与备选：否掉旧模型"席位绑 tenant\_member\_id"------成员关系一变席位即失锚，退出团队后残留可用席位；也否掉以手机号或团队名为绑定键（D1\.1 规定资源归属不用这两者），改绑稳定用户身份。
  • 承接的硬约束：消息 4 的"实名席位"即绑定稳定用户身份；消息 10 释放即时停止该产品访问；消息 11 在回收同一链上递增 epoch，守 D1\.14"不等重新登录"。
  • 落地形态：对应 inviteMember / allocateSeat / releaseSeat 与 seat\_allocation（space\_id \+ user\_id，含 bound\_at/released\_at）。
  • 空间隔离：消息 12"确认个人空间与其他团队不受影响"是 D1\.3 退出隔离与 D1\.6 空间隔离的图上证据------退出团队不得波及个人空间与其他团队的权益。
  • 取舍与代价：reassignSeat 未进本图，重分配复用同一分配链；并发抢同一席位靠 seat\_allocation 唯一约束兜底，本图不表达冲突分支。
撤权与故障保守降级流程

图上内容描述：D1 撤权与故障保守降级活动图：从撤权写操作到降级再恢复，符号 18 / 连线 11。

  • 看图口径：三条 <<分配>> 泳道 \+ 8 个活动节点 \+ 1 个 <<判断节点>> \+ 起止各 1；11 条连线均为 控制流，本图不画对象流，只表达执行先后。
  • 泳道点名：泳道为运营与管理员、授权服务、客户端（主体软件网页端侧）；第一段只有一个触发动作"撤销成员回收席位或权益失效"。
  • 授权服务段：做"递增空间授权epoch并发变更事件 → 推送或按epoch拉取最新授权状态"，可确认时给出"重校验后放行写入导出与下载"。
  • 客户端段：做"保守降级：暂停新增编辑提交导出与新下载 → 提示服务暂不可用而非误报到期的"，以及两支共用的"保留草稿与已保存内容不回滚合法保存 → 恢复后重校验且不自动提交故障期草稿"。
  • 判断与守卫：<<判断节点>>「能否确认最新授权状态？」 出边两条------"可确认：5秒内响应"走重校验后放行，"不可确认"走保守降级分支。
  • 关键连线：11 条控制流里，"提示服务暂不可用而非误报到期的"与"重校验后放行写入导出与下载"都指向"保留草稿与已保存内容不回滚合法保存"，两支在此汇合后单线进恢复节点再达终点。
  • 起止与规模：<<活动起点>>、<<活动终点>> 各 1 个，无 fork/join 节点，降级与恢复是一条串行链，图面不表达多副本并发消费。

为什么这么设计：撤权生效与故障降级跨管理员、授权服务、客户端三方，DEC\-10 的每个量词都要落在这条链上。

  • 归域依据：画在 D1 因为它同时守 D1\.14 撤权回收即时生效、D1\.15 五秒响应、D1\.16 无法确认时保守降级、D1\.17 草稿保护（R10\.1\~10\.4），四者同一因果链，拆图会打断"先确认状态再决定放行或降级"的判据。
  • 关键决策与备选：否掉"下次登录才生效"，旧会话可继续写入；否掉"靠缓存 TTL 自然过期"，过期窗口内仍按旧缓存放行且 5 秒无从证明；也否掉"故障时全禁"，只停新增/编辑提交/导出/新下载，保留查看与取回。
  • 承接的硬约束：守卫标签"可确认：5秒内响应"把 D1\.15 的目标钉在出边上；"提示服务暂不可用而非误报到期的"对应 DEC\-10 不得把故障伪装成到期；"不回滚合法保存"对应 D1\.17。
  • 落地形态：对应 authz\_state（space\_id UK \+ epoch）与 authz\_change\_event（event\_type 含 MEMBER\_REVOKED/SEAT\_RECLAIMED 等）。
  • 双路兜底：消费端按 \(space\_id, epoch\) 单调过滤保幂等；"推送或按epoch拉取"同载 pushAuthzChange 与 pullAuthzByEpoch，降级走 degradeToReadOnly。
  • 验收与留痕：降级期写 authz\_incident（reason、blocked\_actions、started\_at、recovered\_at）；指标看撤权投递 P95 延迟小于 5 秒与降级次数。
注册验证与登录会话流程

图上内容描述：D1 注册验证与登录会话活动图：四条泳道从勾选协议走到建立会话与个人空间上下文，符号 31 / 连线 22。

  • 看图口径：符号 31 = 泳道 1 \+ 泳道头 4 \+ 泳道格 4 \+ 活动节点 15 \+ 判断节点 3 \+ <<活动起点>> 1 \+ <<活动终点>> 3；22 条连线全部是控制流、无对象流，分支出边上的文字即守卫条件。
  • 泳道分工：四条泳道依序为访客或用户、身份与组织服务、校验与短信服务、空间服务；用户侧只有四个动作------勾选当前生效协议并提交注册、完成人机校验后请求验证码、回填验证码完成身份验证、进入产品。
  • 服务端段：身份与组织服务段依次做"校验协议版本摘要与同意场景 → 生成拖拽挑战并签发一次性票据 → 服务端校验票据有效且未消费 → 一次性消费凭证并锁定身份操作尝试 → 幂等创建账号（同键重复提交返回同一账号）→ 建立登录会话并绑定设备摘要"，失败出口是"版本已变更：要求重读并重新同意"。
  • 校验与空间段：校验与短信服务段两格------"按用途发送一次性验证码并记录尝试"与失败支"拒绝发送并提示稍后重试"；空间服务段一格"创建或切换个人空间上下文"。
  • 判断与守卫：三个 <<判断节点>>：「协议版本仍生效？」否走重读重同意；「票据与频控通过？」否走拒绝发送；「可创建账号？」否走"标识冲突：不建号不合并，转登录或人工核验"。
  • 关键连线："拒绝发送并提示稍后重试""标识冲突..."两条失败支各自直达一个 <<活动终点>>、不回流主链；成功支经幂等建号 → 建立会话 → 个人空间上下文 → 进入产品收敛到第三个终点。
  • 起止与规模：<<活动起点>> 1 个、<<活动终点>> 3 个，无 fork/join；验证码长度与有效期、频控阈值不在图面出现（对应 D1\.19/D1\.21，参数建议待确认）。

为什么这么设计：把注册、发码、验证、建号、建会话排成一条链，是因为 U01 的四道安全判据只有在同一条时序上才核对得了。

  • 归域依据：整链守 D1\.18\~D1\.24：手机号唯一标识与部署身份域边界、一次性验证凭证绑定用途与尝试、人机校验票据经服务端验证后才发短信、发送与校验频控、验证通过后幂等建号、验证码登录自动注册边界、登录建立身份会话不等于业务授权。
  • 关键决策与备选：否掉"人机校验只在浏览器里过"------票据必须服务端校验有效且未消费；否掉"已注册手机号直接拒绝"------改走验证码登录并自动建号，把首次登录与注册合到同一链；否掉"重复提交各建一号"------以幂等键收敛为同一账号；标识冲突不建号也不合并，与 D1\.29 同口径。
  • 承接的硬约束：入口第一格就是勾选当前生效协议，版本变更时不进发码环节而是回到重读；验证码一次性消费并锁定身份操作尝试；终点"进入产品；旧会话按失效范围拒绝"把会话失效范围写在收口节点上。
  • 落地形态：对应认证与账号接口的 register / requestOtp / verifyRegistration / login，数据侧落身份操作尝试（attempt\_type 取注册、status、idempotency\_key、agreement\_snapshot）、验证凭证（code\_digest、fail\_count、consumed\_at）、人机校验票据、会话、设备，以及个人空间 1:1 的写入点。
  • 验收与留痕：同意事件以"注册"场景追加一条只追加记录；身份操作尝试的状态机（注册类：待验证→验证完成→成功，失败支已过期/冲突/依赖不可用）与验证码发送尝试计数是两处可核对留痕。
  • 取舍与代价：注册与验证码登录合链的代价：账号可能由首次登录动作创建，因此自动注册边界与"自动注册与登录同意事件串联"必须同时生效；图末端只声明进入产品，能力放行判定交给授权侧协作图，身份图不承担授权证明。
凭证找回与手机号改绑流程

图上内容描述：D1 凭证找回与手机号改绑活动图：三条泳道串起旧侧证明、新侧证明与原子切换，符号 25 / 连线 17。

  • 看图口径：符号 25 = 泳道 1 \+ 泳道头 3 \+ 泳道格 3 \+ 活动节点 12 \+ 判断节点 2 \+ <<活动起点>> 1 \+ <<活动终点>> 3；17 条连线全为控制流。
  • 泳道点名：三条泳道为用户、身份与组织服务、风险与通知；用户侧只有"发起找回或改绑并声明操作类型""回填旧侧证明""回填新侧证明"三个动作，其余全在服务端。
  • 服务段：身份与组织服务段依次做"要求旧标识证明（验证码或恢复因素）→ 旧侧证明通过？→ 要求新手机号侧证明 → 新号未被占用？→ 原子提交：绑定与凭证一次性切换 → 生成异步操作记录并回传操作标识 → 按策略撤销既有会话并要求重登"。
  • 风险与通知段：风险与通知段一格收口------"向新旧手机号发送变更通知并写审计"，通知与审计同节点，图上不存在只改绑不留痕的路径。
  • 判断与守卫：「旧侧证明通过？」否→"失败：保持原绑定与原凭证不变"；「新号未被占用？」是：冲突→"冲突：不合并账号、不转移席位与订单"。两条失败支各自到终点。
  • 关键连线：找回与改绑共用同一条链，靠第一格声明的操作类型分流；"原子提交"是图上唯一改绑写入口，前置是双侧证明齐备，后续是会话撤销与通知。
  • 起止与规模：<<活动起点>> 1、<<活动终点>> 3（失败保原绑定、冲突不合并、通知与审计完成），无 fork/join；恢复因素范围与窗口时长不在图面出现（建议待确认）。

为什么这么设计：找回与改绑是同一账号上"先证明控制权、再改凭证"的两种操作，共用链路才能把双侧证明、原子切换、冲突不合并钉成一处。

  • 归域依据：守 D1\.28（凭证找回须先证明控制权）与 D1\.29（手机号改绑双侧证明且冲突不合并），并与 D1\.26（凭证与风险变更使会话按范围失效）、D1\.27（异步操作结果可查询收敛）同链。
  • 关键决策与备选：否掉"只验新手机号即可改绑"------旧侧证明是先决条件，否则号码劫持即接管账号；否掉"冲突时自动合并账号"------不合并、不转移席位与订单，避免跨账号资产凭空迁移；否掉"绑定改了、凭证慢慢跟"------绑定与凭证一次性原子切换。
  • 承接的硬约束：失败支守卫明文写"保持原绑定与原凭证不变"；"按策略撤销既有会话并要求重登"把会话失效落到图上；"不转移席位与订单"与退出隔离、实名席位口径一致。
  • 落地形态：对应 recoverCredential / changeLoginIdentifier，数据侧落身份操作尝试一行（attempt\_type 取密码找回或手机号变更，带 old\_proof\_flag、new\_proof\_flag、idempotency\_key、status）\+ 验证凭证在旧手机号验证/新手机号验证两种用途下的两条记录。
  • 验收与留痕：操作以操作标识异步回传，客户端用 queryOperationResult 收敛结果；新旧手机号通知与审计记录是评审核对项。
  • 取舍与代价：改绑按异步受理，代价是页面要处理"已受理/处理中"中间态；重认证因子范围、频控与通知渠道首期取保守默认，参数标注建议待确认。
账号注销与撤回期流程

图上内容描述：D1 账号注销与撤回期活动图：从发起到撤回期、期满复核再到只注销账号责任范围，符号 27 / 连线 20。

  • 看图口径：符号 27 = 泳道 1 \+ 泳道头 3 \+ 泳道格 3 \+ 活动节点 14 \+ 判断节点 2 \+ <<活动起点>> 1 \+ <<活动终点>> 3；20 条连线全为控制流。
  • 泳道点名：三条泳道为用户、身份与组织服务、权益与交易依赖；用户侧动作是"发起账号注销请求""完成重认证""撤回期内提交撤销"三个。
  • 服务段：身份与组织服务段做"校验登录态与凭证有效性 → 触发敏感操作重认证 → 存在阻止项？→ 无阻止项：进入撤回期 → 期满且未撤回？→ 仅注销账号责任范围：匿名化身份并撤销全部会话 → 不级联删除团队空间、交易记录与审计留痕"。
  • 依赖段：权益与交易依赖段承担前置与复核------"前置检查：个人空间所有权与团队归属""前置检查：未结订单、退款、续费与服务中断"，以及期满的"期满复核：团队转交、订单结清、数据取回已完成"和"移交数据生命周期域按策略清理"。
  • 判断与守卫：「存在阻止项？」是→"返回阻止项清单并保持账号有效"；「期满且未撤回？」否：期内已撤销→"账号恢复有效，数据与权益不变"，是→进期满复核。
  • 关键连线："撤回期内提交撤销"与"期间未撤回"都从进入撤回期节点引出，期满复核是清理前的第二道闸；图上没有任何一条从发起直达清理的边。
  • 起止与规模：<<活动终点>> 3 个（阻止项返回、期内撤销恢复有效、移交数据生命周期域），无 fork/join；撤回期天数在 D1\.30 里作为待确认参数，图面不落数值。

为什么这么设计：注销是全平台唯一不可逆的身份动作，撤回期与前置检查必须在跨域链上显式画出来，才不会实现成一个删除接口。

  • 归域依据：守 D1\.30（注销前置检查与撤回期）与 D1\.31（账号清理不级联）；前置检查画两条，是因为它同时依赖个人空间与成员关系，以及交易域的订单、退款、续费与数据取回。
  • 关键决策与备选：否掉"提交即注销"------先进撤回期，期内可撤销且数据权益不变；否掉"级联删除"------只注销账号责任范围（匿名化身份、撤销全部会话），团队空间、交易记录、审计留痕不动；否掉"绕过撤回期强制注销"------期满复核仍是图上必经节点。
  • 承接的硬约束：发起即触发敏感操作重认证；"不级联删除...审计留痕"把可关联留痕要求写成硬约束；清理以"移交数据生命周期域"收口，身份域不自行删数据。
  • 落地形态：requestDeletion / withdrawDeletion 两条操作 \+ 账号注销申请（closure\_status、blockers\_summary、idempotency\_key、withdrawal\_until、cleaned\_at）；状态取六值：前置检查中/存在阻止项/撤回期内/清理中/已注销/已撤回。
  • 验收与留痕：阻止项清单、撤回、期满复核、移交清理各留下状态迁移与审计；验收样本是"撤回期内撤销 → 数据权益不变"与"注销完成 → 团队空间与交易记录仍在"。
  • 取舍与代价：把交易与生命周期依赖引入注销，代价是注销时效受跨域返回影响、失败原因需人工核验通道兜住；阻止项范围与撤回窗口阈值建议待确认。
协议发布与同意校验流程

图上内容描述：D1 协议发布与同意校验活动图：运营发版与用户端同意在同一条链上，符号 22 / 连线 15，含一条版本变更回边。

  • 看图口径：符号 22 = 泳道 1 \+ 泳道头 3 \+ 泳道格 3 \+ 活动节点 11 \+ <<判断节点>> 1 \+ <<活动起点>> 1 \+ <<活动终点>> 2；15 条连线全为控制流。
  • 泳道点名：三条泳道为平台运营、协议服务、用户端；运营段只做"起草协议文本并声明类型与适用范围""发布版本并切换当前生效指针""已发布版本锁定：纠错只能出新版本"。
  • 服务段：协议服务段做"校验文本完整性并计算内容摘要""下发当前版本标识与正文快照""服务端比对版本标识与内容摘要""追加同意事件（用户、场景、版本、时间、请求号）""同意记录只追加不可改写；仅阅读不产生记录"。
  • 用户端段：用户端只有两格------"打开注册、找回、改绑等流程页面""主动勾选同意并携带版本标识提交"；图上没有预勾选，也没有"阅读即同意"的入口。
  • 判断与守卫：唯一判断节点「版本比对通过？」否：版本已变更→"版本已变更：拒绝并提示重新阅读新版"；是→追加同意事件。
  • 关键连线：图上唯一回边是拒绝节点以"重读后重新同意"接回"下发当前版本标识与正文快照"，其余单向；两个 <<活动终点>> 分别收在拒绝提示与同意记录之后。
  • 起止与规模：<<活动起点>> 1、<<活动终点>> 2，无 fork/join；同意记录不可改写是图上明写的收口约束。

为什么这么设计：同意是法律证据而不是界面状态，"发布即锁定 \+ 服务端比对 \+ 只追加留痕"必须在同一张图上才看得出证据链怎么闭合。

  • 归域依据：守 D1\.32\~D1\.36：逐流程逐次主动同意并只追加留痕、同意证据服务端校验与版本变更拒绝、自动注册与登录同意事件串联、协议版本发布即锁定纠错走新版本、同意记录访问边界与敏感信息保护。
  • 关键决策与备选：否掉"仅阅读即视为同意"（图上明写仅阅读不产生记录）；否掉默认勾选；否掉"就地编辑已发布协议"------纠错只能出新版本并切指针；否掉"客户端上报版本号就算数"------服务端同时比对版本标识与内容摘要。
  • 承接的硬约束：版本变更时拒绝并要求重读重同意，回边保证新同意事件对应新版本文本；同意记录只追加不可改写；注册、找回、改绑等页面走同一下发---比对---追加链路。
  • 落地形态：协议阅读与同意接口 getActiveAgreements / getAgreementContent / recordConsent / listMyConsents，协议版本运营接口 createAgreementDraft / publishAgreementVersion / listAgreementVersions / retireAgreementVersion；数据侧协议版本（agreement\_type、scope、locale、version、content\_digest、version\_status、published\_by）\+ 同意事件（consent\_scene、agreement\_version\_ids、content\_digests、outcome、request\_id、server\_received\_at）。
  • 验收与留痕：同意事件的请求号与服务端接收时间是"服务端收到"的证据；版本状态取草稿/已发布/已替代/已停用四值，停用不产生新版本号。
  • 取舍与代价：已发布版本不可改，代价是一次文案纠错要付一整轮重同意，用户会重新遇到同意弹窗；同意记录的访问边界与敏感字段脱敏首期取保守读取范围。
登录与会话撤销协作

图上内容描述：D1 登录与会话撤销协同时序图：三条生命线 12 条消息排开"登录不等于授权"与"按范围撤销"，符号 24 / 连线 12。

  • 看图口径：符号 24 = 生命线 3 \+ 生命线头 3 \+ 消息端点 18；12 条连线含 CallMessage 6 条、ReplyMessage 6 条，沿生命线纵向位置读时间先后。
  • 片段情况：清单中无 CombinedFragment，本图没有 alt/opt 条件片段，放行与被拒两条结果只靠消息标签文字区分。
  • 生命线点名：三条 <<生命线>> 依序为网页前端、身份与组织服务、授权运行时服务；身份与组织服务是账号侧唯一写入者，能力放行判定在授权运行时服务。
  • 登录段 1--2：1 网页前端→身份与组织服务"提交登录凭证并请求建立会话"；2 回"返回会话与账号状态（登录不等于授权）"------判据直接写在回边标签上。
  • 校验段 3--6：3 网页前端→授权运行时服务"携带会话访问产品并请求能力校验"；4 授权运行时服务→身份与组织服务"重校验身份状态与会话有效性"；5 回"会话有效且身份未受限"；6 回前端"放行当前操作且不含未授权能力"。
  • 撤销段 7--10：7 网页前端→身份与组织服务"改密或找回成功后请求撤销会话"；8 →授权运行时服务"按范围通知撤销既有会话"；9 回"返回已失效会话清单与影响范围"；10 回前端"旧会话后续敏感请求被拒并写审计"。
  • 重登段 11--12：11 网页前端→身份与组织服务"重新登录并换取新会话"；12 回"新会话生效且敏感操作需重认证"，链路在重认证要求上收口。

为什么这么设计："登录不等于授权"和"凭证变更会杀掉旧会话"是实现里最容易被合并的两条规则，画在同一条时间线上才看得出各自的重校验点。

  • 归域依据：守 D1\.24（登录建立身份会话不等于业务授权）、D1\.25（会话与设备可查可撤）、D1\.26（凭证与风险变更使会话按范围失效）、D1\.27（身份状态与异步操作结果可查询收敛）。
  • 关键决策与备选：否掉"登录即授权"------会话有效只保证身份链成立，能力放行由授权运行时服务逐次重校验；否掉"改密后靠会话自然过期"------撤销是显式消息且返回失效清单；否掉"全端强制登出"------按范围撤销，影响范围在消息 9 上可核对。
  • 部署口径：与"D1 启动授权校验与epoch降级协作"的分工：那张图管每请求 epoch 比对与故障保守降级，本图管会话的建立、按范围撤销与重登；两者都以鉴权内嵌 saas\-core 用户域为前提，图上没有独立鉴权网关这条生命线。
  • 承接的硬约束：消息 2 与消息 6 把登录拆成"给会话"和"给能力"两步；消息 8 与消息 10 对应撤权即时生效、不等重新登录；消息 12 的敏感操作需重认证与注销、改绑链路的触发敏感操作重认证同口径。
  • 落地形态：login / listSessions / revokeSession 三条操作，与 changePassword / recoverCredential 成功后的会话撤销联动；会话侧用状态（有效/已退出/已超时/已撤销）、撤销时间与绝对有效期承载，设备侧以设备摘要支撑"可查可撤"的展示。
  • 取舍与代价：会话失效范围粒度与绝对有效期时长属安全参数，首期按保守值实现并标注建议待确认，图上只写"按范围"不落数字。
权限组初始化与角色资源展开流程

图上内容描述：D1 权限组初始化与角色资源展开活动图：三条泳道从建租户触发走到展开落库与审计，符号 21 / 连线 15。

  • 看图口径：符号 21 = 泳道 1 \+ 泳道头 3 \+ 泳道格 3 \+ 活动节点 10 \+ <<判断节点>> 2 \+ <<活动起点>> 1 \+ <<活动终点>> 1；15 条连线全部是 ControlFlow、无对象流，分支出边上的文字即守卫条件。
  • 泳道分工：三条泳道为平台运营、身份与组织服务、租户与空间服务。平台运营段两格------"创建租户或触发权限初始化"与失败支"补齐权限组资源后重新触发"；租户与空间服务段两格------"受理建租户请求并声明所选权限组""回传展开与跳过条数，初始化结果可查"；其余十格全在身份与组织服务段，<<活动起点>> 落在平台运营列、<<活动终点>> 落在身份与组织服务列。
  • 服务端段：身份与组织服务段依次做"读取权限组及其资源清单（平台级定义）→ 按适用层级展开为角色资源授权行 → 写入缺失授权行并记录创建人与时间 → 平台角色授权保持租户标识为 0 → 全过程写审计日志，可按角色与资源回溯"。
  • 判断与守卫：两个 <<判断节点>>：「权限组已配置资源？」否：组内无资源 → 回到平台运营泳道补齐资源；「同角色同资源同租户已有授权？」是：已存在 → "跳过已有行，只补缺失项（幂等）"，否：缺失 → "写入缺失授权行并记录创建人与时间"。
  • 关键连线："跳过已有行"与"写入缺失授权行"两支都汇入"平台角色授权保持租户标识为 0"，幂等分支与写入分支在授权归属上走同一收口；"补齐权限组资源后重新触发"以"补齐后重试"接回展开节点，是图上唯一的回边。
  • 起止与规模：<<活动起点>> 1 个、<<活动终点>> 1 个，无 fork/join；可选哪个权限组、初始化失败是否回滚整租户不出现在图面（D1\.41 取逐行幂等，不做跨行事务回滚）。

为什么这么设计：把"权限组展开"画在建租户链路上，是为了让"运行时不 JOIN 模板"这条口径在图上就有出处：展开只发生在初始化那一刻，之后每次请求只读授权表。

  • 归域依据：守 D1\.41（建租户或初始化权限时把组内资源逐条展开为角色资源授权、展开幂等、运行时只读授权表）与 D1\.42（同一张授权表用租户列区分平台角色与本租户角色，0 表示平台角色授权）；D1\.38/D1\.39 保证被展开的资源与权限组是平台级定义、组内不重复挂同一资源。
  • 关键决策与备选：否掉"运行时按权限组实时判定"------请求链路上多一次模板 JOIN，且权限组一改就穿透全部租户，无法核对某次请求当时生效的是哪一份；否掉"重复初始化即报冲突"------已存在的授权只补齐缺失项，以（角色, 资源, 租户, 软删除）唯一键幂等收敛；否掉"平台角色授权写实际租户 id"------平台角色授权对租户只读，租户标识必须保持 0。
  • 承接的硬约束：读取的是平台级定义的权限组与资源清单，租户不得新增、改写或删除（D1\.38）；写入行带创建人与时间（D1\.45）；收口节点是"全过程写审计日志"，图上不存在不留痕的展开路径。
  • 落地形态：对应 initTenantRoleResources 一条操作：读 role\_template 与 role\_template\_resource、写 role\_resource；回传的展开与跳过条数来自图上"写入缺失授权行"与"跳过已有行"两个分支。
  • 验收与留痕：验收样本是"同一租户重复初始化两次 → 授权行数不变"与"平台角色授权行 tenant\_id = 0 → 租户侧不可改"；审计按角色与资源可回溯到展开时刻。
  • 取舍与代价：展开式授权的代价是资源清单变更后要重新初始化才进入生效集合，不做隐式同步；图上把补齐资源留在平台运营泳道，就是要求这一步由运营显式发起，而不是后台自动补。
接口与页面访问按权限资源鉴权协作

图上内容描述：D1 接口与页面访问按权限资源鉴权协同时序图：三条生命线 12 条消息排开"路径命中才放行"与"前端隐藏不算访问控制"，符号 24 / 连线 12。

  • 看图口径：符号 24 = 生命线 3 \+ 生命线头 3 \+ 消息端点 18；12 条连线含 CallMessage 6 条、ReplyMessage 6 条，沿生命线纵向位置读时间先后。
  • 片段情况：清单中无 CombinedFragment，本图没有 alt/opt 条件片段，放行、拒绝与页面渲染三段结果只靠消息标签文字区分。
  • 生命线点名：三条 <<生命线>> 依序为网页端、saas\-core 鉴权切面（内嵌）、身份与组织服务；鉴权切面是 saas\-core 的内部件而不是独立网关，图上没有第四条网关生命线（鉴权内嵌 saas\-core 的定版口径）。
  • 放行段 1--4：1 网页端→鉴权切面"请求接口：携带会话、空间、实际路径与 HTTP 方法"；2 切面→身份与组织服务"取该主体在当前空间生效的角色资源授权集合"；3 回"只读授权表返回资源清单（运行时不 JOIN 权限组）"；4 回网页端"路径模式与方法命中：放行到业务处理"。
  • 拒绝段 5--8：5 网页端→切面"请求未授权的路径或方法"；6 切面→身份与组织服务"按同一份授权集合再次匹配"；7 回"未命中：不区分资源不存在与无权限"；8 回网页端"统一拒绝并写审计，不泄露接口清单"。
  • 渲染段 9--12：9 网页端→切面"拉取本人可见的页面与操作资源"；10 切面→身份与组织服务"读取该主体已授权的资源清单"；11 回"返回已授权的页面与操作资源"；12 回网页端"按清单渲染菜单与按钮；前端隐藏不构成访问控制"。
  • 关键连线：消息 3 与消息 11 是同一份只读授权集合的两次读取，图上没有任何指向权限组的生命线；消息 4 与消息 8 构成放行与拒绝的唯一分叉，两支都回到网页端，不存在绕过切面的第二条通道。

为什么这么设计：接口访问判定与页面可见性画在同一张时间线上，是为了让"体验层"和"访问控制"各落在不同消息上，避免实现时把菜单隐藏当成鉴权。

  • 归域依据：守 D1\.43（每次请求以实际路径与 HTTP 方法在服务端匹配生效的接口类资源授权集合）、D1\.44（页面与操作类只决定渲染，服务端独立按权限资源判定）、D1\.42（生效集合取自角色资源授权表，租户标识 0 为平台角色授权）、D1\.40（功能权限点并入权限资源同一张表，按 type 分流各管可见性与访问判定）。
  • 关键决策与备选：否掉"响应用 404 与 403 区分"------状态码差异等于把平台接口清单交给探测者，统一按无权访问返回；否掉"前端隐藏即可"------隐藏只用于减少误操作，直接调用未授权资源同样拒绝；否掉"在请求链路上 JOIN 权限组"------只读授权集合，模板展开留在初始化那一刻。
  • 部署口径：第二条生命线是 saas\-core 内嵌的鉴权切面，与"启动授权校验与epoch降级协作""登录与会话撤销协作"同一套前提：没有独立鉴权网关。三张图的分工是------本图管按资源的访问判定，另两张管 epoch 比对与会话的建立、撤销。
  • 承接的硬约束：消息 1 携带实际路径与方法，判定输入不由前端声明的接口名代替；消息 2 与 10 限定在"当前空间生效"的授权集合，跨空间不继承；消息 8 的拒绝写审计，与 D1\.45 的变更可追溯共用一套日志；鉴权只拒绝请求，不吊销既有会话本身（D1\.45）。
  • 落地形态：对应 checkResourceAccess（放行与拒绝判定）、listVisiblePages 与 listVisibleActions（页面与操作清单）三条操作，读 role\_resource 与 resource（type 取接口 / 页面 / 操作 / 功能权限点，接口类带 path\_pattern 与 method）；运行时判定只走 role\_resource 这一条链路，功能权限点只决定菜单与按钮可见性，两类判据同表按 type 分流（D1\.40）。
  • 验收与留痕：验收点是"同一未授权路径反复请求 → 响应一致且审计有记录"与"已隐藏菜单对应的接口直接调用 → 仍被拒绝"；拒绝与放行结果都可在审计里按角色、资源与请求时刻还原。
  • 取舍与代价：每请求一次授权集合匹配的代价是缓存与失效策略留给实现（图上不出现缓存节点）；权限组变更需重新初始化才进入生效集合，运行时看不到模板侧的即时变化。
团队邀请与接受流程

图上内容描述：D1 团队邀请与接受流程：邀请人发起、受邀人验证接受、租户平台生成成员身份与世代，旧链接重发即失效。符号 15 / 连线 7，3 条泳道、6 个活动节点。

  • 看图口径：泳道头 <<邀请人>>、<<受邀人>>、<<租户平台>>；节点是活动动作，连线全部是控制流，分支出边上的文字即守卫条件。
  • 动作清单：登记待核实邀请意图、发出一次性邀请链接、受邀人本人验证并接受、生成成员身份与世代、重发邀请使旧链接失效、过期或撤销不得再接受。
  • 承接的判据：本图守 D1\.49\~D1\.51（R20）；图上每一步都对应层 5 同名操作或层 4 字段写入点。
  • 本轮状态：活动与活动图是本轮按《SaaS 需求中心》新建，模型里泳道与动作齐备；配图待客户端导出后补入本节。

为什么这么设计：成员资格的取得必须有一次可验证的接受动作；重发与旧链接失效画在同一条链上，才能证明"旧链接不再可用"不是口头约定。

  • 归域依据：本流程的判定与写入都落在本域的数据与状态机上，跨域只在动作里引用对象标识（不跨域画泳道），否则同一条链要同时改两个域的表，故障时无法判定归属。
  • 关键决策与备选：被否的备选是把这一段并入既有主流程------并入后守卫条件要跨泳道复用，判据失效时无法定位是哪一步放宽了。
  • 验收与留痕：过程事实写进 team\_invitation（state、intent\_id、supersedes\_id、version）与 membership；结果未知一律按原 operation\_id 回查，不给重复占额、重复返还或重复投递留路径。
受控治理访问流程

图上内容描述：D1 受控治理访问流程：治理人员申请，身份平台签发带对象引用与时效的上下文，业务模块逐请求校验并留痕。符号 14 / 连线 6，3 条泳道、5 个活动节点。

  • 看图口径：泳道头 <<治理人员>>、<<身份平台>>、<<业务模块>>；节点是活动动作，连线全部是控制流，分支出边上的文字即守卫条件。
  • 动作清单：核实治理人员身份与用途、签发带对象引用与时效的治理上下文、逐请求校验用途与版本、消费或过期撤销、治理动作全程留痕。
  • 承接的判据：本图守 D1\.46\~D1\.48（R19）；图上每一步都对应层 5 同名操作或层 4 字段写入点。
  • 本轮状态：活动与活动图是本轮按《SaaS 需求中心》新建，模型里泳道与动作齐备；配图待客户端导出后补入本节。

为什么这么设计：治理访问借业务会话通行是权限提升的入口，图上把签发、逐请求校验、消费/撤销三段分开，受限账号的动作面才被圈死。

  • 归域依据：本流程的判定与写入都落在本域的数据与状态机上，跨域只在动作里引用对象标识（不跨域画泳道），否则同一条链要同时改两个域的表，故障时无法判定归属。
  • 关键决策与备选：被否的备选是把这一段并入既有主流程------并入后守卫条件要跨泳道复用，判据失效时无法定位是哪一步放宽了。
  • 验收与留痕：过程事实写进 governance\_context（action、object\_ref、scope\_version、state）；结果未知一律按原 operation\_id 回查，不给重复占额、重复返还或重复投递留路径。

D2 商品与权益

试用激活与双重去重流程

图上内容描述：D2 试用激活与双重去重活动图：两道去重判断串出三条出口，符号 22 / 连线 14。

  • 看图口径：三条 <<分配>> 泳道、9 个活动节点、2 个 <<判断节点>>、1 个 <<活动起点>>、3 个 <<活动终点>>；14 条连线全是控制流，无对象流，出边文字即守卫标签。
  • 泳道点名：三条泳道依序为用户、租户平台、权益服务；用户段只有入口"主动激活试用（个人包或团队包）"。
  • 平台段：承担两次读取与两个阻止节点------"读取团队维度已消耗记录""读取人员维度已消耗记录"、"阻止获取：团队维度去重""阻止获取：人员维度去重（不限于创建人）"。
  • 权益服务段：做"绑定时点最新版本的配置与能力 → 按\[A,次日00:00\+N自然日\)算失效时点 → 生成TRIAL权益包并写入消耗记录 → 立即可用并展示到期时间"。
  • 判断与守卫："该团队已获取过团队试用？"的"是：团队已消耗"进团队维阻止、"否"进读取人员维度已消耗记录；"该人员已获取过团队试用？"的"是：人员已消耗"进人员维阻止、"否"继续绑定版本。
  • 关键连线：14 条控制流中成功链 9 段（激活→团队维读取→判断→人员维读取→判断→绑定版本→算失效时点→生成权益包→立即可用），两个阻止节点各指一个终点，起点另接一条。
  • 起止与规模：3 个 <<活动终点>> 对应两条阻止出口加一条成功出口，是双重去重的图面直证；两判串行（团队维在前），无 fork 并行判定。

为什么这么设计：试用是免费发放的资损口子，去重判定必须在写入之前完成，判定主体又跨用户、平台、权益三方。

  • 归域依据：D2\.4（R4\.4）双重去重、D2\.2（R4\.2）激活时绑定最新版本、D2\.5（R4\.5）区间算法三件事同入参同判定时点，故同图；S00\-AC\-11 要求两个维度分别阻止重复获取。
  • 关键决策与备选：否掉"只校验团队创建人"，节点标签直书"不限于创建人"，防止把已消耗人员拉进新团队再领一次；否掉"激活时冻结配置快照"，未激活资格取届时最新版，只有付费在成交时锁 order\.snapshot\_json。
  • 承接的硬约束：节点"按\[A,次日00:00\+N自然日\)算失效时点"即 DEC\-04 区间口径，右端点不含、统一北京时间（9 月 21 日 15:00 激活 7 天，9 月 29 日 00:00 失效）。
  • 去重机制：去重与发放否掉 Redis 锁或缓存计次，靠 trial\_consumption 与 trial\_consumed\_member 两张表的 DB 唯一键；换团队、重复建团队、版本更新都不重置，符合 BR\-005 的重复处理语义。
  • 落地形态：对应试用接口的 checkTrialEligibility 与 activateTrial 两个操作，配置取 TRIAL 包 plan\_version 的席位、项目数、存储三类配额字段。
  • 取舍与代价：个人试用一次性（D2\.3）没有独立分支，两判都指向团队试用维度；3 席绑定动作不在本图，由 D1 席位绑定与释放协作承担，两图合读才是完整试用链路。
席位降额与保留名单确认流程

图上内容描述：D2 席位降额与保留名单确认流程：租户平台检出超限并拉起写围栏，团队所有者确认保留名单后才应用降额。符号 12 / 连线 6，2 条泳道、5 个活动节点。

  • 看图口径：泳道头 <<租户平台>>、<<团队所有者>>；节点是活动动作，连线全部是控制流，分支出边上的文字即守卫条件。
  • 动作清单：检测到额度低于已占席位、暂停该产品团队写入与新专业导出、向当前所有者发起保留名单确认、零额度只确认可空名单、应用降额并递增席位配额版本。
  • 承接的判据：本图守 D2\.6\~D2\.8（R23）；图上每一步都对应层 5 同名操作或层 4 字段写入点。
  • 本轮状态：活动与活动图是本轮按《SaaS 需求中心》新建，模型里泳道与动作齐备；配图待客户端导出后补入本节。

为什么这么设计：降额不是平台单方面改额度：谁被留在席位上是客户的商业决定，图上有"所有者确认"这一步，实现里才不能拿默认名单顶替。

  • 归域依据：本流程的判定与写入都落在本域的数据与状态机上，跨域只在动作里引用对象标识（不跨域画泳道），否则同一条链要同时改两个域的表，故障时无法判定归属。
  • 关键决策与备选：被否的备选是把这一段并入既有主流程------并入后守卫条件要跨泳道复用，判据失效时无法定位是哪一步放宽了。
  • 验收与留痕：过程事实写进 seat\_reduction（retained\_ids 与两个集合版本、gate）；结果未知一律按原 operation\_id 回查，不给重复占额、重复返还或重复投递留路径。

D3 交易与履约

下单支付与履约授予流程

图上内容描述：这张活动图把一次成交画成下单、支付、履约授予三段接力，24 个符号、15 条连线。

  • 看图口径：四条 <<分配>> 泳道为客户、交易服务、支付渠道、权益服务；连线全为控制流，箭头即执行顺序，守卫标签原文是 SUCCESS、UNKNOWN、FAILED、核实为成功。
  • 交易段节点：①选择权益包版本与付费周期 → ②创建订单并锁定价格能力额度费率快照 → ③生成支付尝试记录 → ④渠道支付并回调（读在支付渠道列）。
  • 履约段节点：⑤核实为成功并标记订单已付款 → ⑥生成履约记录 → ⑦按幂等键授予Grant与权益（读在权益服务列）→ ⑧次日00:00起算完整周期并即时生效 → ⑨查看订阅详情与额度。
  • 判断与守卫：唯一 <<判断节点>>「支付结果？」三支------SUCCESS→⑤；UNKNOWN→⑩「结果UNKNOWN：转核实，不重复扣款」，其出边守卫「核实为成功」汇入⑤；FAILED→⑪「结果FAILED：允许重新发起支付」。
  • 起止与图上没有的：起点接①，主流程止于⑨后的终点，⑪走第二个终点；⑪虽写允许重新发起支付，但图面无回到②③的连线，重发属客户再走一遍流程；createOrder、grantEntitlement 等操作名在接口层而非本图。规模：11 活动节点 \+ 9 泳道图元 \+ 1 判断 \+ 1 起点 \+ 2 终点 = 24。

为什么这么设计：拆成订单、支付尝试、履约三段各写一条事实，是为了让钱与权能分开核实、分开重放。

  • 承接的硬约束 ：BR\-003 与 D7\.12 要求订单、支付、履约分开、结果未知时核实而不重复扣退款；图上②写 order（snapshot_json 锁价格/能力/额度/费率）、③写 payment_attempt、⑥写 fulfillment、⑦写 grant，四表按 order_id 串成可回放链。
  • 关键决策与备选：被否方案是下单即支付一步到位、回调到账直接改权益------那样订单与权益之间没有中间事实，渠道迟到或重复推送时既不能重放也不能对账，故支付结果只落③④，权益变更必须走⑤⑥⑦。
  • 幂等与失败处置 ：⑦按 grant.idempotency_key 唯一键授予，重复回调不重复授予（D7\.14/BR\-005）；⑪不自动重新扣款，与 D3\.8「首期仅手动购买续购」一致。
  • 时间口径：⑧固定为核实成功即时生效、次日 00:00 起算完整周期，保留日期锚点、短月不漂移（D3\.1），试用转付费复用同一句不另立规则。
  • 落地形态与验收：交易与履约服务在 saas\-core 的 trade 模块，首期渠道只有支付宝、回调经接入层进 core 验签；取证看四表能否按订单号对齐，UNKNOWN 支细节由下一张时序图承担。
升级替换与旧单退款流程

图上内容描述：升级换单并处理旧单退款的活动图，22 个符号、13 条连线，一条主干加一次退款结果二分。

  • 看图口径：四条 <<分配>> 泳道为客户、交易服务、权益服务、财务；连线为控制流，判断出边守卫只有「是」「否」两个标签。
  • 升级主干：①发起升级（新套餐全额下单付款）→ ②校验：有效期内允许升级不允许降级 → ③核实新订单支付结果 → ④切换权益：旧权益停止新权益生效 → ⑤以同一停止时点计算旧单可退基数 → ⑥财务审核退款范围与版本费率快照。
  • 判断与两支：唯一 <<判断节点>>「退款执行成功？」------「是」→ ⑦记录退款留痕并联动权益撤销；「否」→ ⑧转独立补偿处理：不回退权益不重复付款。
  • 汇合与起止：⑦⑧两支在⑨「新周期自次日重新起算且不继承旧锚点」合流为一条，再经⑩获得升级后的能力与额度 到唯一活动终点；起点接①，主干无中途出口。
  • 规模核对：10 活动节点 \+ 9 泳道图元（4 顶项/4 内容项/1 框）\+ 1 判断 \+ 1 起点 \+ 1 终点 = 22；13 条控制流 = 主干 6 \+ 进判断 1 \+ 守卫 2 \+ 汇入⑨ 2 \+ ⑨→⑩ 1 \+ 起止 2。

为什么这么设计：升级用换单而非补差，并把退款排在切权益之后，唯一目的是客户权益不断档。

  • 归域依据：D3\.4/D3\.5（S00 R5\.4/R5\.5）------有效期内可升不可降、升级不补差而是新订单完整付款＋原订单按时间比例退款，故首节点即全额下单，②只判可升不可降。
  • 关键决策与备选：顺序必须是③核实新单→④切权益→⑤⑥退旧款；被否走法有「先退旧款再切」（渠道退款时延不可控，客户两头无权益）与「先切再核实」（新单未确认就撤销旧权益）。
  • 退款失败为什么不回退：④后新权益已生效、旧权益已停止，回退等于把平台侧资损风险转成客户权益反复；规则为 D3\.6/R5\.6，⑧进独立补偿且不要求重复付款。
  • 计算与留痕 ：⑤的同一停止时点即 D4\.2 的 C，B=P×R÷D、D=E−S 按秒计、费率取购买时版本快照（⑥），升级退款不扣手续费；落 upgrade_record 与 refund_application。
  • 落地与验收 ：trade/aftersale 模块配退款补偿任务，旧 entitlement 置 REPLACED、新行按⑨重设锚点；验收看当天只赠一次剩余时长、不继承旧到期日，退款单能否用 stop_entitlement_id 追回同一时点。
支付结果UNKNOWN核实协作

图上内容描述：支付结果 UNKNOWN 的核实协作时序图，4 条生命线、10 条消息，23 个符号、10 条连线。

  • 看图口径：生命线头部带 <<生命线>> 构造型，自上而下按时间读；实线 CallMessage 为请求、虚线 ReplyMessage 为回信，箭头即发送方→接收方。
  • 生命线点名（4 条）：客户、交易服务、支付渠道适配器、财务与运营。
  • 消息 1\-5（先核实）：1 客户→交易服务：确认订单并发起支付；2 交易服务→支付渠道适配器：创建支付尝试并跳转渠道；3 支付渠道适配器→交易服务：回调超时：结果UNKNOWN；4 交易服务→支付渠道适配器：主动查询渠道交易号；5 支付渠道适配器→交易服务：返回明确支付结果。
  • 消息 6\-8（放行履约）：6 交易服务→财务与运营：核实期间冻结重复扣款与重复退款；7 财务与运营→交易服务：允许继续履约；8 交易服务→客户：通知开通结果。
  • 消息 9\-10（人工支路）：9 交易服务→支付渠道适配器：仍为UNKNOWN：转人工核实；10 财务与运营→客户：核实后补记履约不丢弃迟到收款------第 10 条发送方是财务与运营而非交易服务。
  • 规模核对：4 条 Lifeline \+ 4 个生命线头部 \+ 15 个 MessageOccurrence = 23；图上无判断框与循环框。

为什么这么设计：超时只说明结果未知，图上的唯一动作是去核实，判成功或判失败都是错的。

  • 承接的硬约束：BR\-003/D7\.12 规定未知结果核实、不盲目重复扣款或退款；S00 对支付尝试的定义即「超时不自动等于支付失败」，故第 3 条超时后不结清状态，只转第 4 条向适配器主动查单。
  • 被否方案：超时判失败：若第 3 条直接判 FAILED 并关单，渠道随后到账就成了钱收了、单已关、权益未授予，只能靠客户投诉触发纠错------图上没有关单消息，正是这个原因。
  • 被否方案：超时判成功：判 SUCCESS 即触发授予等于凭空造一次收款，渠道最终未收款便是资损与虚假权益；故第 6 条先冻结重复扣款与重复退款、第 7 条经财务与运营放行才继续履约。
  • 被否方案：自动重新扣款：核实期间不补发第 2 条、图上无任何再次发起支付的消息，否则一次 UNKNOWN 会变成两次收款，D3\.8 首期仅手动也排除自动重扣。
  • 人工支路的代价：第 9\-10 条承认自动核实可能仍无结论，转人工并补记履约、不把迟到收款当不存在（DEC\-11），代价是开通时效从秒级退化为人工时长，属已知取舍。
  • 落地形态 ：查询走订单与支付接口的 queryPaymentAttempt，周期核实由支付对账定时任务驱动（调度侧实现约定，图上只画到向适配器查询）；幂等由 channel_trade_no 与 grant.idempotency_key 两层唯一键兜住。

D4 售后与财务

对账批次与差异处理流程

图上内容描述：D4 对账批次与差异处理流程：运营与财务锁定窗口建批，租户平台判完整性并派生差异工单，未结不得结案。符号 13 / 连线 7，2 条泳道、6 个活动节点。

  • 看图口径：泳道头 <<运营与财务>>、<<租户平台>>；节点是活动动作，连线全部是控制流，分支出边上的文字即守卫条件。
  • 动作清单：锁定渠道商户币种与时间窗口、校验批次输入完整性、缺页或未知判为不完整待核实、生成差异工单并指派责任、未结差异不得结案、异常实收按流水上限返还。
  • 承接的判据：本图守 D4\.7\~D4\.9（R24）；图上每一步都对应层 5 同名操作或层 4 字段写入点。
  • 本轮状态：活动与活动图是本轮按《SaaS 需求中心》新建，模型里泳道与动作齐备；配图待客户端导出后补入本节。

为什么这么设计：对账的第一问是批次完不完整，第二问才是差异多不多；缺页时若直接判"无差异"，财务结论就是假的，故完整性判断必须在差异生成之前。

  • 归域依据：本流程的判定与写入都落在本域的数据与状态机上，跨域只在动作里引用对象标识（不跨域画泳道），否则同一条链要同时改两个域的表，故障时无法判定归属。
  • 关键决策与备选：被否的备选是把这一段并入既有主流程------并入后守卫条件要跨泳道复用，判据失效时无法定位是哪一步放宽了。
  • 验收与留痕：过程事实写进 reconciliation\_batch 与 reconciliation\_discrepancy（state、owner\_id、resolution\_ref）；结果未知一律按原 operation\_id 回查，不给重复占额、重复返还或重复投递留路径。

D5 数据生命周期

到期保留与数据清理流程

图上内容描述：到期后保留、宽限到受控清理的活动图，20 个符号、12 条连线，主干一条加一次最终检查。

  • 看图口径：三条 <<分配>> 泳道为调度任务、租户平台、运营与用户；连线为控制流，判断守卫只有「有阻止条件」「无阻止条件」。
  • 保留段节点：①检测权益到期 → ②进入90天到期保留：只读与原始数据取回 → ③停止新建编辑与导入新增数据 → ④向所有者与成员提醒到期与取回方式。
  • 宽限段与判断：⑤进入30天待清理宽限并通知预计删除日 → <<判断节点>>「最终检查：已续费或经授权暂停清理？」：「有阻止条件」→ ⑥取消本次到期清理并保留数据；「无阻止条件」→ ⑦执行业务清理并留审计记录。
  • 删除后置段：⑦ → ⑧备份随轮换在实际删除后30天内清除 → ⑨灾备恢复重放删除记录不复活已删项目 → 活动终点；⑥单独通向第二个终点，取消支不回插主干。
  • 规模核对：9 活动节点 \+ 7 泳道图元（3 顶项/3 内容项/1 框）\+ 1 判断 \+ 1 起点 \+ 2 终点 = 20；12 条控制流 = 顺序 9 \+ 守卫 2 \+ 起点边 1。

为什么这么设计：到期不等于删除，把保留与宽限画成可判停的状态机，删除才成为受控动作。

  • 归域依据：D5\.1/D5\.2（S00 R6\.1/R6\.2）------到期保留数据、允许授权查看与取回原始项目数据并停新建/编辑保存/导入，90 天保留 \+ 30 天宽限（合计约 120 天）后才业务清理，本图即该政策的时间轴。
  • 关键决策与备选：被否方案是到期即删，以及一个定时任务到期直接删除------两者都表达不了「只读但可取回」这段中间语义，也放不下一个能被续费改写的判断点。
  • 最终检查为什么单独一步：⑤后不直接删，⑦前只认两个守卫值；保留期内续费或经授权暂停都在这一点收敛为⑥取消支。删除因暂停而推迟时，备份清除从实际删除时间起算，不能笼统承诺到期后第 150 天物理清除。
  • 留存轨道要分开：⑧备份随轮换在实际删除后 30 天内清除、⑨灾备恢复重放删除记录不复活已删项目；订单、退款与必要审计记录不随项目内容删除（D5\.6），图上不出现它们正是为把商业留痕排除在清理范围外。
  • 落地与验收 ：生命周期服务写侧 \+ 定时任务执行器批侧（到期扫描、状态推进、清理执行、备份核验），策略 lifecycle_policy、状态 lifecycle_state（stage/purge\_due\_at/paused\_reason）、留痕 purge_record；验收按状态机与备份期限有任务留痕可抽查。注销/解散的 30 天撤回窗口是另一条政策，本图未画。
配额预占写入与结算流程

图上内容描述：D5 配额预占写入与结算流程：主体软件发起、租户平台判定，两泳道走完预占---写入---结算三段，未知结果只回查不重算。符号 13 / 连线 7，2 条泳道、6 个活动节点。

  • 看图口径：泳道头 <<主体软件>>、<<租户平台>>；节点是活动动作，连线全部是控制流，分支出边上的文字即守卫条件。
  • 动作清单：写入前申请配额预占、原子校验已用加预占加增量不超上限、主产品保存数据并回报结果、按实际增量结算预占、明确失败释放预占、结果未知只查原操作不得重复占额。
  • 承接的判据：本图守 D5\.7\~D5\.9（R21）；图上每一步都对应层 5 同名操作或层 4 字段写入点。
  • 本轮状态：活动与活动图是本轮按《SaaS 需求中心》新建，模型里泳道与动作齐备；配图待客户端导出后补入本节。

为什么这么设计：额度判定发生在写入之前，不写进流程就等于没有：预占、结算、释放三种结果与"结果未知只能查原操作"必须画成不同出口，才验收得了同键幂等。

  • 归域依据：本流程的判定与写入都落在本域的数据与状态机上，跨域只在动作里引用对象标识（不跨域画泳道），否则同一条链要同时改两个域的表，故障时无法判定归属。
  • 关键决策与备选：被否的备选是把这一段并入既有主流程------并入后守卫条件要跨泳道复用，判据失效时无法定位是哪一步放宽了。
  • 验收与留痕：过程事实写进 quota\_reservation（含 idempotency\_key 与 state）与 capacity\_guard\_record；结果未知一律按原 operation\_id 回查，不给重复占额、重复返还或重复投递留路径。

D7 平台运营治理

License高版本导入替换流程

图上内容描述：独立部署侧 License 高版本导入并整体替换的活动图，18 个符号、10 条连线。

  • 看图口径：三条 <<分配>> 泳道为签发方、交付与授权人员、独立部署实例；连线为控制流，判断守卫原文是「是」与「否：失败或旧版本重放」。
  • 签发与导入段：按节点语义归栏------①签发含全部应保留权益的高版本License（签发方）→ ②受控导入License或撤销凭证（交付与授权人员）→ ③本地完整校验实例与租户绑定及签名（独立部署实例）。
  • 判断与两支：唯一 <<判断节点>>「校验通过且版本更高？」------「是」→ ⑤整体替换当前有效完整快照；「否：失败或旧版本重放」→ ④保留原授权快照不做任何变更。
  • 成功段与起止：⑤ → ⑥重复导入不增权且旧版不回退 → ⑦记录导入审计并保留期限不受影响 → 活动终点；④通向第二个终点，图上无重试回边。
  • 规模核对：7 活动节点 \+ 7 泳道图元（3 顶项/3 内容项/1 框）\+ 1 判断 \+ 1 起点 \+ 2 终点 = 18；10 条控制流 = 前置 3 \+ 守卫 2 \+ 成功支 3 \+ 失败支到终点 1 \+ 起点边 1。

为什么这么设计：一份实例只留一份当前有效完整快照，授权更新与撤销才能共用同一条受控导入通道。

  • 归域依据：D7\.1 实例与租户绑定 \+ D7\.3（S00 R9\.3）：增购、续期、调整一律重新签发含全部应保留权益的高版本 License，先完整校验再整体替换，故⑤替换对象是完整快照而非单张权益。
  • 一条通道为何两用：D7\.4 承认完全离线无法实时吊销，撤销只能经高版本快照或撤销凭证导入------新快照不再列出的权益即被撤销，与新增权益走同一校验与替换动作，故②写作「受控导入License或撤销凭证」。
  • 关键决策与备选：被否方案一是增量补丁式 License 叠加（同一实例出现两份冲突快照、重复导入即重复增权）；被否方案二是旧版本 License 可回退（客户可用旧凭证恢复已撤销权益），故守卫写成「校验通过且版本更高？」，旧版重放落④。
  • 失败为什么不动现场：④保留原授权快照不做任何变更，使导入永不弄坏客户环境；期限授权到期只停新增编辑、保留只读与取回、不自动删数据（D7\.2/D5\.5），⑦「保留期限不受影响」即此意。
  • 落地与验收 ：License 接口提供 issueLicense/importLicense/validateLicense/revokeLicense，签发私钥只在云端密钥管理（KMS）内、不入交付包（D1\.10）；取证看 license 的 snapshot\_version 与 status（ACTIVE/SUPERSEDED/REVOKED）、license_import_record 的 result/failure\_reason，算例 S00\-AC\-08。时钟回拨不在本图，由部署侧时钟比对与 clock_anomaly_record 承担。
合同核销与人工配置授予流程

图上内容描述：合同轨从签约核销到人工配置授予的活动图，本组最大的一张：25 个符号、16 条连线。

  • 看图口径：四条 <<分配>> 泳道为客户、财务、运营与交付、租户平台；连线为控制流，守卫原文为「否：金额或信息不符」「是：已核销」「否：配置不完整」「是：校验通过」「补齐后重新校验」。
  • 到账核对段：①签订线下合同并约定权益范围与期限 → ②核对公转账到账结果 → <<判断节点>>「到账金额与合同一致？」：「否：金额或信息不符」→ ③退回补付或更正合同：暂不授予；「是：已核销」→ ④核销合同并登记商业授予依据。
  • 配置与校验段：④ → ⑤按商业权益版本配置空间期限席位与容量 → <<判断节点>>「配置完整性与合法性校验通过？」：「否：配置不完整」→ ⑥阻止生效并回填缺失参数（不取默认值）。
  • 授予与收尾段：「是：校验通过」→ ⑦生成MANUAL\_CONFIG来源Grant与权益 → ⑧立即可用，周期自次日00:00起算 → ⑨记录操作者原因与结果留痕 → ⑩收到开通通知并进入团队空间。
  • 回环与终点：⑥有两条出边------标「补齐后重新校验」回到⑤（本组 6 张流程图中唯一的回环），另一条通向第二个活动终点；③、⑩各接一个终点，共 3 个终点，起点接①。
  • 规模核对：10 活动节点 \+ 9 泳道图元 \+ 2 判断 \+ 1 起点 \+ 3 终点 = 25；16 条控制流 = 守卫 4 \+ 回⑤ 1 \+ 到终点 3 \+ 顺序与起止 8。

为什么这么设计：合同只作财务与交付留痕，开通动作收敛到与线上轨同一个 grant 入口，下游只有一套代码。

  • 归域依据 ：蓝图定版口径明确合同轨不作为独立授予来源------contract 保留为留痕实体，核销后产生 grant.source_type=MANUAL_CONFIG，属 S00 四种 Grant 来源（订单/试用/人工配置/License）之一，故⑦画的仍是授予动作。
  • 为何收敛到同一入口 ：被否方案是合同直变订阅，即 contract 后另起一条订阅与权益链路；那样席位校验、到期扫描、鉴权快照、退款各要写两套，两轨也无法在同一处合流。
  • 核销与授予分两步：②③④回答钱到没到、金额与合同是否一致（财务口径），⑤⑥回答给哪个空间、哪个版本、多少席位与容量（交付口径），两问各自留痕才能对账；金额不符只退回补付、暂不授予，不允许先授予后补差。
  • 不取默认值是硬规则：D7\.15/BR\-006 禁止以原型或框架默认值代替运营参数，故⑥的语义是阻止生效并回填而非缺省补齐；⑨对应 D7\.10 关键操作留痕（操作者、原因、结果）。
  • 落地与取舍 ：登记与核销在租户与运营管控接口（registerContract/verifyContractPayment），操作面是独立的运营后台，授予写 grant、留痕进 audit_log；代价是 B 端开通含人工时延、首期不做合同解析自动发放。时间口径与线上轨一致：立即可用、次日 00:00 起算。
通知意图与投递流程

图上内容描述：D7 通知意图与投递流程：业务模块发意图，运营平台去重套模板并投递，接收者回写已读，失败沿原意图重试。符号 15 / 连线 7，3 条泳道、6 个活动节点。

  • 看图口径：泳道头 <<业务模块>>、<<运营平台>>、<<接收者>>；节点是活动动作，连线全部是控制流，分支出边上的文字即守卫条件。
  • 动作清单：业务方发布通知意图、按事件版本与接收者去重、套用现行模板版本、投递并记录状态、明确失败沿原意图受控重试、接收者已读或批量已读。
  • 承接的判据：本图守 D7\.17\~D7\.19（R25）；图上每一步都对应层 5 同名操作或层 4 字段写入点。
  • 本轮状态：活动与活动图是本轮按《SaaS 需求中心》新建，模型里泳道与动作齐备；配图待客户端导出后补入本节。

为什么这么设计：通知失败不能回滚业务事实：意图与投递分两段画，重试沿原意图走，接收者的已读状态才可能成为独立可验收的事实。

  • 归域依据：本流程的判定与写入都落在本域的数据与状态机上，跨域只在动作里引用对象标识（不跨域画泳道），否则同一条链要同时改两个域的表，故障时无法判定归属。
  • 关键决策与备选：被否的备选是把这一段并入既有主流程------并入后守卫条件要跨泳道复用，判据失效时无法定位是哪一步放宽了。
  • 验收与留痕：过程事实写进 notification\_intent（dedup\_key）与 notification\_delivery（state、read\_state）；结果未知一律按原 operation\_id 回查，不给重复占额、重复返还或重复投递留路径。
  • 为什么这么设计：治理面与业务面分泳道------凡「谁批准、谁核验、谁留痕」都单列一条泳道，使「未知只查原操作号」「失败不产生副作用」这类判定落在明确的执行方上；14 条流程的活动图本轮已按 siderBarDrop 装配并逐条与规格对账（缺泳道 无、缺动作 无）。
  • 配图状态 ：这 14 张活动图是新画的，文档里尚无对应的原生导出图，需在客户端批量导出后补贴。

OPS v1\.9 新增 14 条流程（模型 03\.2业务流程设计/D7，每条一张活动图，泳道与动作已上图）：

  • D7 后台人员邀请与激活流程｜泳道：超级管理员、受邀本人、身份底座、运营平台｜动作：校验治理身份与手机号合法性 → 创建一次性邀请并绑定职责与原因 → 生成二十四小时有效的不透明链接 → 受邀人本人短信核验 → 接受邀请并激活后台身份 → 旧链接与旧令牌即时失效 → 过期或撤销只重新邀请不延长截止
  • D7 后台人员禁用与恢复流程｜泳道：超级管理员、本人、运营平台｜动作：填写原因按稳定标识禁用 → 撤销后台会话与后续命令资格 → 提交有期限恢复申请 → 本人重新验证绑定手机号 → 验证通过签发新会话旧会话不复活 → 失败撤回或到期保持禁用 → 最后有效管理员拒绝禁用
  • D7 受控初始化超级管理员流程｜泳道：部署授权责任人、运营平台｜动作：按预先核验的稳定身份发起初始化 → 校验仅允许成功一次 → 写入不可篡改的执行人依据与时间 → 结果未知用原操作号查询 → 禁止用第二次初始化猜测结果
  • D7 权限模板发布与影响预览流程｜泳道：超级管理员、授权运行时、运营平台｜动作：基于现行发布版创建草稿 → 校验动作均在可信目录内且身份不变 → 计算新增与撤销动作及受影响账号 → 展示其他角色仍允许与本次真正失权 → 确认发布不可变版本 → 原子切换现行指针并读回 → 版本变化非法动作或职责越权阻止发布
  • D7 通用字典维护与引用保护流程｜泳道：超级管理员、引用方、运营平台｜动作：创建字典与条目并填原因 → 提交期望版本与幂等键 → 周期语义由基本单位与倍率显式给出 → 发布不可变来源版本 → 被引用条目拒绝删除只能停用或出新版本 → 旧引用按快照读取不被改名重算
  • D7 运营管控建模用户账号流程｜泳道：平台运营、身份底座、运营平台｜动作：按稳定用户标识读取账号状态 → 校验动作理由与来源版本 → 提交限制或解除命令绑定原因与操作号 → 未知只查同一操作号 → 成功后重读状态与审计 → 已注销身份不提供复活入口
  • D7 运营管控空间生命周期流程｜泳道：平台运营、空间服务、运营平台｜动作：读取空间生命周期与版本 → 分区读取权益席位与商业存储 → 来源失败显示待核实不清零其它分区 → 按授权提交暂停或恢复命令带期望版本 → 执行后重读状态与操作号 → 运营不代建认领或关闭团队
  • D7 商品三段校验发布流程｜泳道：平台运营、商品目录、运营平台｜动作：取最新版本生成页面工作副本 → 逐字段校验三段与政策引用 → 核对差异并确认发布 → 原子追加不可变版本并切换现行指针 → 任一校验失败整次拒绝且不落草稿 → 停售仅清空销售指针不改成交快照 → 重新上架发布新版本而非恢复旧版
  • D7 赠送商品受众校验与领取流程｜泳道：用户、平台运营、商品目录、权益服务｜动作：选择受众类型并分页挑选稳定标识 → 发布时锁定名单与版本与摘要 → 边界值零与上限与超限分别校验 → 工作台按当前空间读取可领取与阻止原因 → 同商品同空间至多成功领取一次 → 零元订单不发支付尝试 → 权益确认后展示生效且未知只查原操作
  • D7 跨产品主套餐升级流程｜泳道：用户、交易服务、权益服务、财务服务｜动作：选定唯一旧主套餐与目标产品 → 目标已有有效主套餐则拒绝 → 确认报价并创建同一操作号意图 → 交易核实新支付终态 → 支付确认后权益只替换所选主套餐 → 财务按成交条款免手续费退旧余款 → 任一未知沿同一操作查询且不重复扣款退款
  • D7 订单查询与原支付核实流程｜泳道：平台运营、交易服务、支付渠道｜动作：按三主体与商品名组合筛选 → 同一订单多关联只出一行并标注依据 → 读取订单支付尝试与履约三套事实 → 支付未知只查原尝试号 → 迟到收款不复活已取消订单
  • D7 订单内运营发起普通退款流程｜泳道：平台运营、财务服务、权益服务、支付渠道｜动作：在订单详情核对商品项与已退待处理金额 → 填写原因并确认发起标记运营发起 → 资格不满足拒绝且无副作用 → 请求权益来源停止并取回实际停止时点 → 按停止时点重算基数手续费与可退额 → 核算零分完成不出款 → 预留余额后提交原渠道尝试 → 渠道未知保留预留只查原尝试 → 退款完成权益停止与票据调整各自留存事实
  • D7 发票开具事实与原件流程｜泳道：客户、具发票资格的运营人员、发票与附件平台｜动作：校验订单资格与申请资料与邮箱格式 → 资料不全退回且原订单事实不变 → 线下真实开具登记票号日期身份与依据 → 先持久化开具事实 → 沿同一附件任务上传原件并扫描校验 → 首次就绪才标记已开具并允许下载 → 附件失败或未知保留事实与原任务 → 已开具后原件损坏只修同一附件不改历史
  • D7 协议实例发布与明确恢复流程｜泳道：平台运营、协议服务、用户端｜动作：从启用协议类型创建唯一实例 → 创建草稿并校验类型内版本唯一与隐私清单 → 预览适用范围与切换影响 → 发布不可变版本并切换类型现行指针 → 取消发布清空指针不自动回退 → 授权后显式重发同一不可变正文 → 用户端读取现行版本且同意快照独立保留 → 新类型不自动进入客户必选同意集合

详细设计

数据实体设计

本节对应 M\-Design「04详细设计」包：80 个实体 Block、684 个业务字段（另有 180 个关联端点属性）、95 个枚举类型，实体之间 90 条关联、实体到枚举 107 条依赖，按 D1\~D7 六域各一张结构图（BDD），另有一张跨域总览。属性类型收敛为 9 种基元（String/Long/Integer/Decimal/Boolean/DateTime/Date/Enum/Json），枚举取值域在应用层字典管理；图面实体名用汉字表名，物理表名保留英文、建表 DDL 以《ER图与功能点》映射表为准。各域小节末尾的「字段明细」逐表列出字段名、类型、含义、枚举取值与键口径，字段名与顺序取自层 4 模型。本轮按《SaaS 需求中心》补齐的 17 张表分属五域：身份与组织（受控治理上下文、团队邀请）、商品与权益（席位降额）、售后与财务（对账批次、对账差异）、数据生命周期（配额预占、清理保全）、平台运营治理（通知模板/意图/投递、验收用例、验收执行、验收证据件、缺陷单、性能基线项、负载画像、容量保护记录）。

全域总览

图上内容描述：全域目录式总览结构图：20 个图元、0 条连线，只放 6 个域包与 2 个锚点模块，不画任何关系。

  • 看图口径：6 个 <<包>> 框即六个域编号------D1 身份与组织、D2 商品与权益、D3 交易与履约、D4 售后与财务、D5 数据生命周期、D7 平台运营治理，与 5\.1 后续六张分域结构图一一对应；本图只承担目录职责，连线为 0 不是缺项。
  • 锚点块点名：图上仅有的 2 个 <<模块>> 是成员身份（id、tenant\_id、user\_id、status、joined\_at）与角色定义（id、code、name、scope\_type），各带属性面板------它们是被人均引用最频繁的跨域挂载点，放在总览只为定位。
  • 面板信息：属性清单只列字段名；类型口径统一为 9 种基元（String/Long/Integer/Decimal/Boolean/DateTime/Date/Enum/Json），枚举取值域在应用层字典管理，图面用中文表名、物理表名以《ER图与功能点》映射表为准。
  • 本图不画什么：本图不承载 space 挂载点，也不画 contract/order→grant→entitlement 授予主干------空间、交易、权益实体均不在本图上，跨域关系一律以各域结构图为准。

为什么这么设计：总览只回答"域切在哪、锚点是谁"，把每条关系钉死在唯一归属域图上，杜绝图与图两张皮。

  • 归域依据：六包口径即 S00 蓝图 §5 的六域------原 D6 独立部署与 License 不单独成包，是 2026\-09\-23 定版把其 5 实体（部署实例、授权凭证、凭证导入记录、凭证撤销、时钟异常记录）并入 D7 的结果，总览如实反映该包结构。
  • 关键决策与备选：被否方案是"把约 46 条跨域关系全画进一张总览"------单图不可读，且每条边与分域图重复一份，改关系要同步两张图必漂移；现方案每条 Association 只在归属域出现一次，跨域端以引用块出现。
  • 承接的硬约束：0 连线守住"域 = 关系唯一归属"的建模纪律；成员身份、角色定义两个锚点块在总览露出，提醒评审一人多团队、角色作用域（scope\_type）是跨域公共语义。
  • 验收与留痕：评审时拿总览 6 包对照蓝图域清单，逐包块数拿各域 BDD 头部符号数核验（<<模块>>\+<<枚举>> 符号数 D1 50、D2 30、D3 18、D4 17、D5 19、D7 62；实体块 23、16、8、6、7、35 共 95，与各域「字段明细」的表数一一对应，实测无实体漏上图），总览本身不承诺任何关系证据。
  • 图面核验尺子：六张分域结构图按几何口径实测------压框 0、斜段 0、线框越界 0、标签越界 0、标签相交 0、标签压框 0；剩余项为共线重叠 4、标签压他边 7、线交叉 141（合计 196 个符号、226 条连线）。
  • 交叉数上升的取舍：OPS v1\.9 这轮结构图从 80 实体涨到 95、枚举从 95 涨到 114，D1 符号由 45 涨到 50、D7 由 36 涨到 62，交叉随之由 17 涨到 141；这是"把枚举与新增实体全部画上"换来的代价。取舍口径：宁可交叉多，也不把枚举挪成文字清单------图上每根虚线都是实体与取值域的直接证据，评审可按线核验；若要把交叉压回两位数，只能拆图或加共享枚举带，两者都会破坏"一域一图"。
  • 本轮计数（2026\-10\-12 实测）：层1 42 组 159 叶、层2 89 用例 / 12 参与者、层3 33 条活动流程、层4 95 表 1109 列 114 枚举、层5 六域 45 个接口块 234 条契约操作、全模型 61 张图。
  • 画布状态 ：本轮动过的 19 张画布（需求/用例/结构/接口 \+ 14 张活动图）已逐张排版，顶层图元两两重叠由 26 对收敛到 0 对、越出图框 0；D7 相关配图的原生导出件待重导后再替换。

D1 身份与组织

图上内容描述：身份与组织结构图：22 个本域 <<模块>> 实体 \+ 28 个 <<枚举>>，符号 50 / 连线 56（关联 25、依赖 31）；账号生命周期此前已新增 9 实体与 15 枚举，权限管控再加四块与两个枚举，本轮按《SaaS 需求中心》补受控治理上下文（GovernanceState）与团队邀请（InvitationState）两表两枚举，枚举逐一连回归属实体。

  • 看图口径：<<模块>> 块下挂属性面板（只列字段名，类型按 9 基元口径），<<枚举>> 列出枚举量（图上以 <<值类型>> 构造型渲染）；实线 Association 读实体间关系，虚线 Dependency 只出现在"实体 → 状态/类型枚举"上。
  • 存量身份组织簇：用户、租户、空间、成员身份、角色定义、角色授权、所有权转让共 7 块；其中用户新增 domain\_id、region\_code、dial\_code、national\_number、password\_status、reauthenticated\_at，username 仍是稳定主身份。
  • 账号簇（凭证侧）：部署身份域（domain\_code、domain\_type、name）、身份操作尝试（attempt\_no、domain\_id、user\_id、phone\_digest、attempt\_type、status、idempotency\_key、agreement\_snapshot、old\_proof\_flag、new\_proof\_flag、started\_at、finished\_at、expires\_at）、验证凭证（attempt\_id、purpose、code\_digest、credential\_status、fail\_count、consumed\_at）、人机校验票据（attempt\_id、ticket\_digest、ticket\_status、expires\_at）。
  • 账号簇（会话侧）：会话（user\_id、device\_id、auth\_method、session\_status、last\_verified\_at、revoked\_at、absolute\_expiry\_at）、设备（device\_summary、platform、first\_seen\_at、last\_active\_at）、账号注销申请（closure\_status、blockers\_summary、withdrawal\_until、cleaned\_at）；找回与改绑的双侧证明标记（old\_proof\_flag、new\_proof\_flag）与幂等键都在身份操作尝试同一行内成立。
  • 账号簇（协议侧）：协议版本（agreement\_type、scope、locale、version、content\_digest、version\_status、published\_by）与同意事件（interaction\_id、consent\_scene、auth\_method、agreement\_version\_ids、content\_digests、outcome、request\_id、server\_received\_at）。
  • 权限簇（资源与授权）：资源（code、type、path\_pattern、method、description）、权限组（code、name、scope\_type、description）、权限组资源项（role\_template\_id、resource\_id）、角色资源授权（role\_id、resource\_id、tenant\_id）四块，各带创建人/修改人/时间与软删除标记；前两块是平台级定义，后两块分别是组的成员与运行时生效的授权行。
  • 枚举侧：新增 16 个：AccountStatus、RegistrationAttemptStatus、VerificationPurpose、CredentialStatus、CaptchaTicketStatus、SessionStatus、PasswordStatus、IdentifierChangeType、AsyncOperationStatus、AccountClosureStatus、AgreementType、AgreementVersionStatus、ConsentScene、ConsentOutcome、DeploymentDomainType、ClientPlatform（设备 platform 的取值域）；本轮权限管控新增 ResourceType（接口 / 页面 / 操作）与 HttpMethod（GET / POST / PUT / DELETE / PATCH）；连同存量 8 个共 26 个。
  • 关键连线：25 条关联里存量 7 条：用户---空间、租户---空间、租户---所有权转让、用户---成员身份、租户---成员身份、用户---角色授权、角色定义---角色授权；账号侧 11 条：部署身份域---用户、部署身份域---身份操作尝试、身份操作尝试---验证凭证 / 人机校验票据 / 用户 / 同意事件、用户---会话、会话---设备、用户---账号注销申请、协议版本---同意事件、用户---同意事件；权限侧 4 条：权限组---权限组资源项、权限资源---权限组资源项、角色定义---角色资源授权、权限资源---角色资源授权。
  • 依赖覆盖：31 条 Dependency 里有 30 条把本域 28 个枚举连到取值方实体（一个枚举可被多块共用），另 1 条是权限组→角色资源授权的展开依赖：存量 8 条（用户→UserStatus、成员身份→MemberStatus、角色定义→RoleScopeType、所有权转让→TransferStatus、空间→SpaceType 与 SpaceStatus、租户→TenantType 与 TenantStatus）；账号侧 16 条（用户→AccountStatus 与 PasswordStatus、部署身份域→DeploymentDomainType、身份操作尝试→AttemptType 与 AttemptStatus、验证凭证→CredentialStatus 与 VerificationPurpose、人机校验票据→CaptchaTicketStatus 与 VerificationPurpose、会话→SessionStatus、设备→ClientPlatform、账号注销申请→AccountClosureStatus、协议版本→AgreementType 与 AgreementVersionStatus、同意事件→ConsentScene 与 ConsentOutcome）；权限侧 3 条（权限资源→ResourceType、权限资源→HttpMethod、权限组→RoleScopeType）；本轮 3 条（受控治理上下文→GovernanceState、团队邀请→InvitationState、设备→AdmissionState）。VerificationPurpose 被验证凭证与人机校验票据两块共用，以绕行虚线连入；RoleScopeType 被角色定义与权限组两块共用。关联线与依赖线都不再压住实体框。

为什么这么设计：U01 的可判据------一次性凭证、幂等建号、会话可撤、同意只追加------与本轮的访问判定------路径命中、方法匹配、授权成行------都落在校验"值"而非"文本"上，所以状态与类型必须成枚举，账号动作与资源授权必须有独立行。

  • 空间唯一锚点（DEC\-01）：space 仍从 tenant 独立成表，权益、席位、授权水位挂 space\_id；账号侧新实体一律挂 user\_id 或 attempt\_id 而不挂 tenant\_id，改绑与注销因此不动团队资产。
  • 身份键选择：主身份仍是 username；手机号拆成 domain\_id \+ region\_code \+ dial\_code \+ national\_number 四列，去重只比 phone\_digest（身份操作尝试与人机校验票据同口径）。被否方案是"phone 单列当唯一键"------国际区号与改绑会互相打架（D1\.18、D1\.29）。
  • 凭证与票据独立成表：验证凭证与人机校验票据各带状态、失败次数与过期时间并挂 attempt\_id，一次性消费与"先验票据后发短信"才是可校验的行级事实；把码写进身份操作尝试字段被否。
  • 会话与设备分离：会话持状态、最后校验时间、撤销时间与绝对有效期；设备只存设备摘要与平台等观测值。D1\.25 的"可查可撤"因此落在会话行上，而不是浏览器的登录态上。
  • 同意是事件不是布尔：同意事件记录场景、版本 id 列表、内容摘要、结果、请求号与服务端接收时间，并与身份操作尝试、协议版本相连；在用户表加一个"已同意隐私政策"字段被否------版本变更时无法判定同意过哪一版。
  • 幂等与异步：身份操作尝试与账号注销申请两张表都带 idempotency\_key，配合身份操作尝试的九态状态（待验证 / 验证完成 / 已受理 / 处理中 / 成功 / 失败 / 已过期 / 冲突 / 依赖不可用）支撑幂等建号与结果查询收敛。
  • 资源与权限组分列定义：权限资源以 code 供代码引用、以 path\_pattern \+ method 供访问判定，权限组按适用层级聚合一组权限资源供整体引用；把路径写进功能权限点的描述字段被否------功能权限点降级为权限资源的一种 type，与接口 / 页面 / 操作同表分流，各自决定可见性与访问判定（D1\.40）。
  • 授权是行不是集合：角色资源授权每行一个（role\_id, resource\_id, tenant\_id），运行时判定读行集合而不读权限组模板，模板只在初始化时被读一次（D1\.41）；图上因此有一条独立的 权限组→角色资源授权 展开依赖，与枚举取值依赖分开画。
  • 承接的硬约束：账号注销申请只有状态与阻止项摘要，删除动作不在身份域表结构里（清理不级联）；协议版本带版本状态与内容摘要，已发布版本锁定、纠错出新版本。
  • 落地形态：本轮再增两表------受控治理上下文 governance\_context（11 列）与团队邀请 team\_invitation（13 列），各带 GovernanceState、InvitationState 两个枚举上图并连回归属实体；物理表新增 deployment\_domain / identity\_attempt / verification\_credential / captcha\_ticket / session / device / account\_closure\_request / agreement\_version / consent\_event；user 表增部署身份域与电话分区列；本轮再新增 resource（权限资源）/ role\_template / role\_template\_resource / role\_resource 四张物理表（权限管控），存量表字段口径不变。
字段明细

下面按域逐表列出每个实体/物理表的全部字段：列名、类型、含义、枚举取值与键口径。字段名与类型、枚举取值取自 M\-Design「04详细设计」层 4 模型（枚举取值以「0\.数据类型」包为准）；含义一列以模型字段用途 \+ 需求/业务规则条款（D1\.xx、DEC\-xx、R7\.x、BR\-003 等）为准，无条款出处的按字段名与类型推导，不引入未经确认的数值参数（此类以"建议待确认"标注）。共 22 张表 / 202 列。

成员身份 （物理表 membership，5 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
status MemberStatus 成员关系状态；离职/移除只改本行，不动 user 与空间资产 待接受、正常、已停用、已退出 已退出为终态，席位回收由 seat\_allocation 侧观察
joined\_at DateTime 加入本租户的时间
tenant\_id Long 所属租户 FK→tenant\.id
user\_id Long 关联的稳定用户身份 FK→user\.id

角色定义 （物理表 role_def，4 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
code String 角色编码，全平台稳定，授权与权限展开都按 code 引用 发布后不改语义，改语义走新 code
name String 角色显示名
scope\_type RoleScopeType 角色作用域层级 平台级、租户级、空间级 决定授权时 space\_id / tenant\_id 哪个必填

用户 （物理表 user，15 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
username String 登录主身份，稳定不随手机号改绑与租户变化而变 主身份唯一键
email String 联系邮箱，仅用于通知与找回沟通 D1\.1/D1\.18：不作为注册、登录、找回或认证绑定标识
phone String 注册手机号（展示用规范化串） D1\.18：注册与登录的唯一标识；去重按部署身份域内手机号摘要比
password\_hash String 口令散列 不保存明文（D1\.36 不得记录可重放凭证）
nickname String 昵称
status AccountStatus 账号生命周期状态 待验证、有效、受限、注销撤回期、注销清理中、已注销 受限/撤回期/清理中由 D1\.30\~D1\.31 链路驱动
created\_at DateTime 注册时间
last\_login\_at DateTime 最近一次登录成功时间
domain\_id Long 账号所属部署身份域 FK→deployment\_domain\.id；D1\.18：不同部署不按标识自动合并
region\_code String 国家/地区代码 与 dial\_code 一起标识号码归属地
dial\_code String 国际电话区号 改绑与去重按区号\+国内号组合比
national\_number String 不含区号的国内号码 与 domain\_id 组合作为域内唯一键
password\_status PasswordStatus 是否已设置口令 未设置、已设置 D1\.23：验证码自动注册的新账号为未设置，不生成默认口令
reauthenticated\_at DateTime 最近一次敏感操作重认证时间 D1\.26：敏感操作不得只依赖长寿命令牌，窗口参数建议待确认

租户 （物理表 tenant，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
tenant\_no String 对外稳定的租户编号 用于展示、对账与客服定位，非主键
name String 租户名称
type TenantType 租户类型 个人、团队、企业 个人账号即单人租户，与企业主用同一套模型
status TenantStatus 租户状态 待认领、正常、已冻结、已解散
owner\_user\_id Long 租户所有人（创建者） FK→user\.id；移交走 owner\_transfer
claimed\_at DateTime 团队租户被认领的时间 未认领的团队租户为空
created\_at DateTime 创建时间

空间 （物理表 space，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
type SpaceType 空间类型 个人空间、团队空间 DEC\-01：个人空间与团队空间同为权益/席位挂载点
user\_id Long 个人空间的归属用户 FK→user\.id；团队空间为空
tenant\_id Long 所属租户 FK→tenant\.id
name String 空间名称
status SpaceStatus 空间状态 正常、已冻结、已归档、已清理 已归档/已清理由 D5 数据生命周期域驱动
created\_at DateTime 创建时间

角色授权 （物理表 role_assignment，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
role\_code String 被授予的角色编码 FK→role\_def\.code
principal\_user\_id Long 被授权的用户 FK→user\.id
space\_id Long 空间级角色作用的空间 FK→space\.id；非空间级为空
tenant\_id Long 作用租户 FK→tenant\.id
granted\_by Long 执行授权的操作者 FK→user\.id；审计留痕
assigned\_at DateTime 授权生效时间

所有权转让 （物理表 owner_transfer，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
tenant\_id Long 被移交所有权的所有人所在的租户 FK→tenant\.id
from\_user\_id Long 移交方 FK→user\.id
to\_user\_id Long 接收方 FK→user\.id
status TransferStatus 转让状态 待接受、已完成、已取消、已过期 D1\.30：注销前必须完成所有权交接，否则为阻止项
initiated\_at DateTime 发起时间
accepted\_at DateTime 接收方确认时间 未接受为空

部署身份域 （物理表 deployment_domain，5 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
domain\_code String 部署身份域编码 域内唯一，标识账号归属的那一套部署
domain\_type DeploymentDomainType 部署类型 公共SaaS身份域、独立部署身份域 D1\.18：公共 SaaS 与独立部署之间不按标识自动合并
name String 显示名
created\_at DateTime 创建时间

验证凭证 （物理表 verification_credential，9 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
attempt\_id Long 所属身份操作尝试 FK→identity\_attempt\.id；D1\.19 凭证绑定尝试
purpose VerificationPurpose 凭证用途 注册、验证码登录、找回、改密核验、旧手机号验证、新手机号验证 与所属尝试的 attempt\_type 一致，不跨用途消费
code\_digest String 验证码摘要 不落明文（D1\.36），校验时比对摘要
credential\_status CredentialStatus 凭证状态 有效、已使用、已过期、已撤销 D1\.19：成功、过期、重复使用、撤销、风险拦截可区分
fail\_count Integer 已发生的校验失败次数 D1\.21：限制错误次数，阈值属建议待确认
sent\_at DateTime 短信发送时间 D1\.20：票据校验通过后才发送
expires\_at DateTime 凭证有效期截止 限时有效，具体时长属建议待确认
consumed\_at DateTime 消费时间 成功校验只消费一次，此后重复使用判失败

人机校验票据 （物理表 captcha_ticket，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
attempt\_id Long 所属身份操作尝试 FK→identity\_attempt\.id
phone\_digest String 绑定手机号摘要 D1\.20：号码变化即票据失效
purpose VerificationPurpose 绑定用途 注册、验证码登录、找回、改密核验、旧手机号验证、新手机号验证 D1\.20：用途变化即票据失效
ticket\_digest String 票据摘要 服务端签发并校验，不采信客户端自报的通过标记
ticket\_status CaptchaTicketStatus 票据状态 有效、已消费、已过期、已拒绝 取消、未完成、超时、校验服务不可用均不发送短信
issued\_at DateTime 签发时间
expires\_at DateTime 票据有效期截止

会话 （物理表 session，10 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
user\_id Long 会话归属用户 FK→user\.id；D1\.24 登录只建立身份会话，不等于业务授权
device\_id Long 会话所在设备 FK→device\.id
auth\_method String 本次登录方式 取值随接口契约：验证码 / 口令；不建枚举以保持与契约同词
session\_status SessionStatus 会话状态 有效、已退出、已超时、已撤销 D1\.25：撤销后为已撤销；重复撤销返回已撤销不报错
created\_at DateTime 会话建立时间
last\_active\_at DateTime 最近活动时间 空闲超时判定依据，阈值属建议待确认
last\_verified\_at DateTime 最近一次重验证时间 D1\.26 敏感操作按此判窗口
revoked\_at DateTime 撤销时间 D1\.25 可查可撤的落点
absolute\_expiry\_at DateTime 绝对有效期截止 D1\.26：长寿命令牌不得越过此点，数值建议待确认

设备 （物理表 device，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
user\_id Long 设备归属用户 FK→user\.id
device\_summary String 设备/客户端摘要 浏览器与系统等等观测值，不含可重放凭证（D1\.36）
platform ClientPlatform 客户端平台 Windows、Linux、macOS 建模客户端侧取值域；网页端按摘要记录
first\_seen\_at DateTime 首次出现时间
last\_active\_at DateTime 最近活跃时间
client\_instance\_id String 客户端实例标识 同机型多实例可分辨；准入与释放按本列与 admission\_state 联合判定
admission\_state AdmissionState 设备准入状态 已准入、待释放、已撤销 已准入、待释放、已撤销；已撤销设备不得再建立新会话

账号注销申请 （物理表 account_closure_request，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
user\_id Long 申请注销的账号 FK→user\.id
closure\_status AccountClosureStatus 注销流程状态 前置检查中、存在阻止项、撤回期内、清理中、已注销、已撤回 D1\.30/D1\.31：清理只处理账号责任范围，不级联
blockers\_summary String 前置检查阻止项摘要 所有权未交接、未结订单/退款/取回等进行中事项；有阻止项不进入撤回期
idempotency\_key String 幂等键 重复提交返回同一申请
requested\_at DateTime 申请时间
withdrawal\_until DateTime 撤回期截止 D1\.30：默认 30 天，期内本人可撤回；天数属建议待确认
cleaned\_at DateTime 清理完成时间 D1\.31：未知结果不得当作已注销

协议版本 （物理表 agreement_version，11 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
agreement\_type AgreementType 协议类型 基础服务协议、隐私政策、账号服务专项协议、其他法定文本 同一适用范围每类型只保留一个当前版本（D1\.35）
scope String 适用部署身份域范围 D1\.33：服务端按适用范围校验最新版本
locale String 语言 如 zh\-CN；同一类型各语言独立成版本
version String 版本号 已发布版本不可改，纠错复制为新草稿再发布
title String 协议标题
content\_digest String 正文内容摘要 同意事件比对摘要，正文变更即版本已变更
change\_summary String 相对上一版的变更说明 用于披露
version\_status AgreementVersionStatus 版本生命周期状态 草稿、已发布、已替代、已停用 D1\.35：已发布与已替代版本正文不可改不可删
published\_at DateTime 发布时间
published\_by Long 发布操作者 FK→ops\_account\.id；发布事务固定操作者

同意事件 （物理表 consent_event，12 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
interaction\_id String 交互标识 D1\.34：同一次披露串联注册与登录两条事件
attempt\_id Long 匿名期关联的尝试 FK→identity\_attempt\.id；认证成功前先挂此列
user\_id Long 已登录场景的关联用户 FK→user\.id；匿名尝试为空
consent\_scene ConsentScene 同意场景 注册、登录、自动注册、找回、手机号变更 D1\.32：逐流程各自采集，不从其他流程承接
auth\_method String 当次认证方式 与登录方式同词，便于串联审计
agreement\_version\_ids String 本次同意的协议版本 id 列表 D1\.33：服务端逐个核验标识、版本与摘要
content\_digests String 对应正文摘要列表 与版本 id 列表一一对应，防快照串版
action String 用户动作 勾选/确认/拒绝等，只追加不覆盖
outcome ConsentOutcome 事件结果 成功、处理中、失败 D1\.32：失败与处理中同样留痕
request\_id String 请求关联号 D1\.34：重试同一请求不产生重复事件
server\_received\_at DateTime 服务端接收时间 以服务端时钟为准，作为同意时间

权限资源 （物理表 resource，12 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
code String 资源编码，供代码引用 全局唯一（D1\.38）；平台级定义，租户不得新增改写删除；与 deleted 组成唯一键，软删除后同码可重建
type ResourceType 资源类别 接口、页面、操作、功能权限点 D1\.37：接口 / 页面 / 操作 / 功能权限点四类。接口类参与路径鉴权，页面与操作类只决定可见性与可点性，功能权限点作为本列的一种类型同表管理（模式 A）
path\_pattern String URL 路径模式 以 URL 编码存储，通配段只允许出现在末尾（如 /api/spaces/\{id\}/projects/\*\*）；页面与操作类同样填本列用于前端路由与控件匹配
method HttpMethod HTTP 方法 GET、POST、PUT、DELETE、PATCH 仅 type=接口 时有效；页面与操作类留空，且留空不得被当作放行（D1\.37/D1\.43）
description String 资源说明 写清管控的是哪个入口，供运营与审计阅读
created\_at DateTime 创建时间 D1\.45：变更留时间
updated\_at DateTime 最后修改时间
created\_by Long 创建人 FK→ops\_account\.id；平台侧操作者
updated\_by Long 最后修改人 FK→ops\_account\.id
deleted Boolean 软删除标记 0=正常 1=已删除；参与唯一键，历史授权行不因资源删除而物理消失
module String 归属模块 功能权限点按能力模块归类（对应功能点目录），用于运营侧分组展示与按能力开关放行；接口/页面/操作三类可空，不作为运行时鉴权依据

权限组 （物理表 role_template，10 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
code String 权限组编码 全局唯一，与 deleted 组成唯一键；建租户与初始化权限按此编码整体引用（D1\.39）
name String 权限组显示名
scope\_type RoleScopeType 适用层级 平台级、租户级、空间级 平台级 / 租户级 / 空间级，决定展开成角色资源授权时挂到哪种角色上
description String 用途说明 D1\.39：权限组只是资源的复用集合，不直接授予用户
created\_at DateTime 创建时间
updated\_at DateTime 最后修改时间
created\_by Long 创建人 FK→ops\_account\.id
updated\_by Long 最后修改人 FK→ops\_account\.id
deleted Boolean 软删除标记 0=正常 1=已删除；参与唯一键。权限组本体由所给 role\_template\_resource 外键与审计列约定推导，字段以现网落地为准

权限组资源项 （物理表 role_template_resource，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
role\_template\_id Long 所属权限组 FK→role\_template\.id
resource\_id Long 组内资源 FK→resource\.id；同一组内不得重复挂同一资源
created\_at DateTime 创建时间
updated\_at DateTime 最后修改时间
created\_by Long 创建人 FK→ops\_account\.id
updated\_by Long 最后修改人 FK→ops\_account\.id
deleted Boolean 软删除标记 0=正常 1=已删除；与组标识、资源标识共同构成唯一键（D1\.39）。本表只在初始化时被读取，运行时判定不查它（D1\.41）

角色资源授权 （物理表 role_resource，9 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
role\_id Long 被授权的角色 FK→role\.id；建租户或初始化权限时由权限组展开写入（D1\.41）
resource\_id Long 授予的资源 FK→resource\.id
tenant\_id Long 授权归属租户 冗余跟随 role\.tenant\_id：0=平台角色授权（对租户只读），非 0=该租户自定义角色的授权（D1\.42）
created\_at DateTime 授权时间
updated\_at DateTime 最后修改时间
created\_by Long 授权操作人 FK→ops\_account\.id 或 user\.id；D1\.45 要求可追溯谁在何时授了哪个资源
updated\_by Long 最后修改人
deleted Boolean 软删除标记 0=正常 1=已撤销；与角色、资源、租户共同构成唯一键，撤权只置位不物理删，运行时判定只读本表（D1\.41）

身份操作尝试 （物理表 identity_attempt，14 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
attempt\_no String 对外尝试标识 D1\.27：结果查询按此收敛，超时不假定失败；不暴露自增主键
domain\_id Long 本次尝试所在的部署身份域 FK→deployment\_domain\.id；D1\.18 域内去重与防枚举以此为界
user\_id Long 已识别的操作主体 FK→user\.id；注册与找回前段可为空（主体尚未确定），有值时用于串起同主体的多次尝试
phone\_digest String 手机号摘要 比摘要不存明文；注册按摘要判重，冲突不建号也不合并（D1\.22）
attempt\_type AttemptType 本次尝试的用途类型 注册、验证码登录、密码找回、密码修改、改密核验、手机号变更 枚举 AttemptType；D1\.19：凭证绑定用途，跨用途使用即拒绝
status AttemptStatus 尝试状态 待验证、验证完成、已受理、处理中、成功、失败、已过期、冲突、依赖不可用 枚举 AttemptStatus；D1\.27：受理或处理中都不代表业务完成，成功/失败/已过期/冲突/依赖不可用为终态
idempotency\_key String 业务幂等键 D1\.22：同键重试不产生重复账号或重复改写；同键不同主体返回冲突
agreement\_snapshot String 本次确认的协议版本快照 D1\.32：默认不选、逐次采集；JSON 存类型/版本/摘要
old\_proof\_flag Boolean 旧侧控制权是否已证明 D1\.28/D1\.29：找回与改绑未证明即不改凭证
new\_proof\_flag Boolean 新侧验证是否已通过 D1\.29：任一侧失败保留原绑定
started\_at DateTime 尝试开始时间 受理即记录
finished\_at DateTime 终态时间 未收敛为空
expires\_at DateTime 尝试有效期截止 超时后凭证与票据一并失效

受控治理上下文 （物理表 governance_context，11 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
user\_id Long 治理访问主体 FK→user\.id；受限账号只能在治理上下文内动作（D1\.48）
domain\_id Long 部署身份域 FK→deployment\_domain\.id，治理上下文不跨身份域复用
action String 授权的具体动作 动词串，与 resource 的操作类口径一致；一上下文只绑一类用途（D1\.46）
object\_ref String 治理对象引用 指向被治理的租户/空间/数据集，避免"全量放行"
scope\_version String 授权范围版本 范围变更即失效，逐请求校验（D1\.47）
state GovernanceState 上下文状态 有效、已消费、已过期、已撤销 已消费/已过期/已撤销均不得再放行
verified\_at DateTime 身份核实时间 签发前须已完成二次核验，本列留痕
expires\_at DateTime 失效时间 时效由策略下发，数值参数建议待确认
operation\_id String 关联的异步操作号 治理动作全程留痕按本号串联（D1\.47）
created\_at DateTime 签发时间

团队邀请 （物理表 team_invitation，13 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
tenant\_id Long 目标租户 FK→tenant\.id
inviter\_user\_id Long 邀请人 FK→user\.id，须是本租户有权成员
target\_phone String 受邀手机号 规范化串；与 user\.phone 同口径，不落明文以外的可重放信息
target\_user\_id Long 接受后绑定的用户 FK→user\.id，接受前为空
role String 邀请授予的角色 按 role\_def\.code 引用，不接受自由文本
state InvitationState 邀请状态 待接受、已接受、已拒绝、已过期、已撤销、已被取代 先有邀请接受后才有资格（D1\.49）；过期/撤销不得再接受
intent\_id String 邀请意图号 重发同意图只生成新记录并取代旧链接，不延长截止（D1\.50）
supersedes\_id Long 被本条取代的旧邀请 自引用 FK→team\_invitation\.id；旧链接随之失效
expires\_at DateTime 邀请截止时间 截止只可提前不可延长（D1\.50）
accepted\_at DateTime 接受时间 接受即生成成员身份与新一代世代（D1\.51）
created\_at DateTime 邀请创建时间
version String 成员世代号 重新加入生成新世代，旧回调只结旧绑定（D1\.51）

部署身份域 （物理表 deployment_domain，6 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
domain\_code String 身份域编码 部署内唯一；手机号去重与登录判定都按本码划界（D1\.18 的部署身份域边界）
domain\_type DeploymentDomainType 身份域类型 公共SaaS身份域、独立部署身份域 公有云共享身份域与独立部署身份域分列
name String 身份域显示名
created\_at DateTime 登记时间
device\_limit Integer 该身份域的设备数上限 数值参数建议待确认；超限按准入策略拒绝新设备，不静默挤掉旧设备

协议类型实例 （物理表 agreement_instance，11 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
type\_item\_id Long 冻结的协议类型字典条目 FK
type\_version Integer 锁定的协议类型版本
type\_semantic\_json Json 协议类型语义快照（改名不影响历史实例）
current\_version\_id Long 现行版本 FK
pointer\_state 枚举·AgreementPointerState 指针状态
republish\_operation\_id String 明确重新发布的受控操作号 FK
created\_at DateTime 创建时点（MP 自动填充）
updated\_at DateTime 最后更新时点（MP 自动填充）
协议版本 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「协议版本」
字典条目 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「字典条目」
  • OPS v1\.9 本域新增表：协议类型实例（业务对象归本域，治理入口在 D7）。

D2 商品与权益

图上内容描述：商品与权益结构图：符号 30 / 连线 30（关联 17、依赖 13），30 个符号＝13 个本域实体＋13 个枚举＋4 个跨域锚点（空间、用户、权益授予、授权凭证）；本轮新增席位降额一块与 ReductionScope、SeatReductionState、CommercialWriteGate 三个枚举。

  • 商品簇（一）·可售版本：权益包（code、name、kind、status）、权益包版本（plan\_id、version\_no、status、price\_cents、billing\_cycles、seat\_count、project\_quota、storage\_quota\_bytes、refund\_rate、capabilities、published\_at、published\_by、integrity\_check\_ok）。
  • 商品簇（二）·能力与路径：版本能力项（plan\_version\_id、feature\_code、quota\_value）、版本升级关系（from\_version\_id、to\_version\_id、relation\_type 显式声明升级路径）、功能点（code、module、name、is\_extra\_purchasable）。
  • 权益簇（一）·生效事实：权益（space\_id、plan\_version\_id、kind=MAIN/MODULE/CAPACITY/TRIAL、source\_type=ORDER/TRIAL/MANUAL\_CONFIG/LICENSE、anchor\_at/start\_at/end\_at、seat\_limit、project\_limit、storage\_limit\_bytes、status、snapshot\_json）、权益能力项（entitlement\_id、feature\_code、quota\_value）。
  • 权益簇（二）·持有与席位：订阅（space\_id、plan\_version\_id、anchor\_at、start\_at、end\_at、last\_renew\_at）、席位分配（entitlement\_id、space\_id、user\_id、status、allocated\_at、released\_at，实名绑定）。
  • 试用与计量簇：试用消耗（kind、user\_id、tenant\_id、consumed\_at，人维与人×团队维双去重）、试用消耗成员（trial\_consumption\_id、user\_id、consumed\_at）、用量快照（space\_id、storage\_used\_bytes、project\_count、measured\_at）。
  • 跨域锚点：空间、用户（D1 引用块，带各自属性面板）、权益授予（grant，D3）、授权凭证（license，原 D6）只在本图作端点出现，其域内连线在归属域图上。
  • 关键连线：17 条关联------本轮新增席位降额---空间（降额目标空间）与席位降额---席位分配（保留席位名单）两条；权益包 1---0\.\.\* 权益包版本 1---0\.\.\* 版本能力项、功能点 1---0\.\.\* 版本能力项、权益包版本 1---0\.\.\* 版本升级关系/权益（按版本授予）、空间 1---0\.\.\* 权益/订阅、权益 1---0\.\.\* 权益能力项/席位分配、用户 1---0\.\.\* 席位分配、订阅 1---0\.\.\* 权益（订阅产生权益）、试用消耗 1---0\.\.\* 试用消耗成员、空间 1---1 用量快照、权益授予 1---1 权益（授予生成权益）、授权凭证 1---0\.\.\* 权益（License 来源权益）。

为什么这么设计：本域把 DEC\-11 版本化、DEC\-03 实名席位、DEC\-04 双重去重一次性钉进表结构，权益成为全平台唯一生效事实。

  • 全部可售能力版本化（DEC\-11）：权益包版本带 version\_no、integrity\_check\_ok、published\_at/published\_by，已发布不可原地改；订单与激活各自锁快照，运营改配置永不追溯存量。被否方案是能力直挂 plan 的旧表（plan\_feature），改价即污染存量租户。
  • 权益独立成表：被否"把权益塞进订单表"------订单是商业承诺（可关单、可退款），权益是生效事实（ACTIVE/EXPIRING/EXPIRED/REPLACED/REVOKED），一单可多次授予、续费顺延只动 end\_at，两语义混列则退款与到期链路无法判断。
  • 席位实名（DEC\-03）：seat\_allocation 绑 space\_id\+user\_id、带 allocated\_at/released\_at------被否方案是席位绑 tenant\_member\_id（席位随团队关系漂移、无法表达"人离队席位即回收"），成员/席位/项目三资格分离要求席位只认稳定用户身份。
  • 试用双重去重（DEC\-04）：trial\_consumption（kind 分人维/人×团队维，user\_id、tenant\_id 各建 DB 唯一键）\+ trial\_consumed\_member------被否方案用缓存锁/计数器去重，重启丢缓存就把资格重置给客户；换团队不重置由"人已被记名"守住。
  • 归域依据：usage\_snapshot 留在本域（蓝图 §5 域数口径：计量是配额判定的从属能力，不立"计量域"）；anchor\_at 起算字段守 \[激活日次日 00:00, \+N 自然日\) 且日期锚点不漂移（DEC\-05）。
字段明细

下面按域逐表列出每个实体/物理表的全部字段：列名、类型、含义、枚举取值与键口径。字段名与类型、枚举取值取自 M\-Design「04详细设计」层 4 模型（枚举取值以「0\.数据类型」包为准）；含义一列以模型字段用途 \+ 需求/业务规则条款（D1\.xx、DEC\-xx、R7\.x、BR\-003 等）为准，无条款出处的按字段名与类型推导，不引入未经确认的数值参数（此类以"建议待确认"标注）。共 13 张表 / 91 列。

权益包 （物理表 plan，5 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
code String 权益包编码 如 FREE/TEAM\_STANDARD/TEAM\_PRO，对外稳定，改语义走新包
name String 显示名
kind PlanKind 包类型 试用包、正式包、增购包 试用包不参与续费；增购包只叠加能力不独立成主套餐
status PlanStatus 上下架状态 草稿、已上架、已下架 DEC\-11：下架不追溯已发布版本与存量权益

权益包版本 （物理表 plan_version，14 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
plan\_id Long 所属权益包 FK→plan\.id
version\_no Integer 包内递增版本号 DEC\-11：能力变更即新版本，不原地改已发布版本
status PlanVersionStatus 版本状态 草稿、待发布、已发布、已下架 只有已发布版本可被下单与授予
price\_cents Integer 定价 以分为单位的整数，避免小数误差
billing\_cycles Json 该版本支持的计费周期 JSON 数组，如月/季/年及对应周期数
seat\_count Integer 席位数上限 DEC\-03：席位实名分配给 user
project\_quota Integer 项目数配额 主体软件侧项目能力的平台配额口径
storage\_quota\_bytes Long 存储配额 字节数；判额以 usage\_snapshot 用量比对
refund\_rate Decimal 退款比例 升级换单时按此比例折算旧单剩余价值
capabilities Json 能力清单快照 JSON；授予时整体复制进 entitlement\.snapshot\_json
published\_at DateTime 发布时间
published\_by Long 发布人 FK→ops\_account\.id
integrity\_check\_ok Boolean 发布前完整性校验是否通过 DEC\-11/R11\.2：校验通过才允许发布，非人工审批

版本能力项 （物理表 plan_version_capability，4 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
plan\_version\_id Long 所属版本 FK→plan\_version\.id
feature\_code String 功能点编码 FK→feature\_item\.code
quota\_value Long 该能力的配额值 \-1 表示不限；布尔型能力用 0/1

版本升级关系 （物理表 plan_version_relation，4 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
from\_version\_id Long 源版本 FK→plan\_version\.id
to\_version\_id Long 目标版本 FK→plan\_version\.id
relation\_type UpgradeRelationType 关系类型 升级、降级、平迁 升级/降级/平迁；未声明的路径下单时判为不可换购

功能点 （物理表 feature_item，4 列）

字段 类型 含义 枚举取值 键与取值口径
code String 功能点编码，主键 如 sysml\.modeling、simulation，与权限 code 的模块段同构
module String 一级功能归类
name String 功能点名称
is\_extra\_purchasable Boolean 是否可单独增购 false 时只能随套餐授予

订阅 （物理表 subscription，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
space\_id Long 订阅所在空间 FK→space\.id
plan\_version\_id Long 订阅锁定的版本 FK→plan\_version\.id；续费不静默升版
anchor\_at DateTime 计费/有效期锚点 DEC\-05：自锚点次日起算，锚点一经确定不漂移
start\_at DateTime 生效时间
end\_at DateTime 到期时间 续费只顺延此列，不改版本与锚点
status SubscriptionStatus 订阅状态 生效中、已到期、已取消
last\_renew\_at DateTime 最近一次续费时间

权益 （物理表 entitlement，14 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
space\_id Long 权益挂载空间 FK→space\.id；DEC\-01 权益只认 space
plan\_version\_id Long 来源版本 FK→plan\_version\.id；人工配置可为空
kind EntitlementKind 权益类别 试用、正式、补偿 试用/正式/补偿；补偿权益用于故障赔付期
source\_type EntitlementSourceType 授予来源 订单支付、合同核销、License导入、人工配置 BR\-003：四种来源统一收敛到 grant 一个入口
source\_ref\_id Long 来源单据 id 按 source\_type 分别指向 grant / license / contract，不做跨表外键
anchor\_at DateTime 有效期锚点 DEC\-05：起止为 \[锚点次日 00:00, \+N 自然日\)
start\_at DateTime 生效时间
end\_at DateTime 到期时间 到期只改状态，不删数据（清理属 D5）
seat\_limit Integer 席位上限 席位分配数不得超过此值
project\_limit Integer 项目数上限
storage\_limit\_bytes Long 存储上限
status EntitlementStatus 权益状态 待生效、生效中、已到期、已撤销、已替换 已替换由升级换单产生；已撤销不回收交易与审计
snapshot\_json Json 授予时冻结的能力快照 DEC\-11：运营改配置永不追溯存量权益

权益能力项 （物理表 entitlement_capability，4 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
entitlement\_id Long 所属权益 FK→entitlement\.id
feature\_code String 功能点编码 FK→feature\_item\.code；运行时放行按此判定
quota\_value Long 配额值 从版本快照复制，\-1 不限

席位分配 （物理表 seat_allocation，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
entitlement\_id Long 占用哪份权益的席位 FK→entitlement\.id
space\_id Long 席位所在空间 FK→space\.id
user\_id Long 实名占位的用户 FK→user\.id；DEC\-03 席位绑人不绑成员关系
status SeatStatus 席位状态 已占用、已释放 已释放即回收，可再分配
allocated\_at DateTime 分配时间
released\_at DateTime 释放时间 离队即回收，人重加入需重新占位

试用消耗 （物理表 trial_consumption，5 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
kind TrialKind 试用维度 个人试用、团队试用 DEC\-04：人维 / 团队维两条去重线
user\_id Long 试用主体用户 DEC\-04：人维按 user\_id \+ kind 建 DB 唯一键，换团队不重置
tenant\_id Long 团队试用时的租户 人维试做为空；人×团队维按 user\_id \+ tenant\_id 唯一
consumed\_at DateTime 消耗时间 只追加，撤销试用不回收资格

试用消耗成员 （物理表 trial_consumed_member，4 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
trial\_consumption\_id Long 所属试用消耗记录 FK→trial\_consumption\.id
user\_id Long 被记名的成员 FK→user\.id；用于个人试用与团队内去重
consumed\_at DateTime 记名时间

用量快照 （物理表 usage_snapshot，5 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
space\_id Long 空间 FK→space\.id；一空间一行当前值
storage\_used\_bytes Long 已用存储 与 entitlement\.storage\_limit\_bytes 比对判额
project\_count Integer 现存项目数 与 project\_limit 比对
measured\_at DateTime 测量时间 计量任务写入，判额只读快照不实时统计

席位降额 （物理表 seat_reduction，13 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
space\_id Long 降额目标空间 FK→space\.id，一空间同一时刻只允许一条待确认降额
plan\_version\_id Long 降额后的版本 FK→plan\_version\.id，席位额度取该版本值
scope ReductionScope 降额适用范围 团队试用、正式席位、License席位 团队试用、正式席位、License 席位三类分开走，不共用一套判据
state SeatReductionState 降额流程状态 无需确认、待确认名单、已应用、已过期、结果未知 待确认名单未确认前不应用；已过期需重新发起
seat\_limit Integer 降额后的席位上限 与版本额度一致写入，避免运行时二次换算
retained\_ids Json 保留席位的成员名单快照 Json；只能由当前所有者确认，零额度只可确认空名单（D2\.8）
membership\_set\_version String 确认时的成员集合版本 集合已变则确认失效，须重新选择，防名单漂移
assignment\_set\_version String 确认时的席位绑定集合版本 同上；两次版本同时命中才可应用
gate CommercialWriteGate 商业写围栏状态 开放、待选名单阻止、零额度阻止、未知阻止 未确认前只停该产品团队写入与新专业导出（D2\.7）
operation\_id String 异步应用操作号 应用结果按本号回查，未知不得重复应用
created\_at DateTime 降额发起时间
confirmed\_at DateTime 所有者确认时间 无需确认的降额本列为空

商品现行发布指针 （物理表 plan_publication_pointer，8 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
product\_id String 商品 FK
latest\_published\_version Integer 最新已发布版本
sales\_state 枚举·ProductSalesState 销售状态（在售 / 停售）
expected\_latest\_version Integer 提交时带的期望版本（CAS 依据）
switch\_operation\_id String 切换现行指针的受控操作号 FK
updated\_at DateTime 最后更新时点（MP 自动填充）
权益包 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「权益包」

受众名单快照 （物理表 audience_snapshot，10 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
plan\_version\_id Long 商品版本 FK
audience\_type 枚举·AudienceType 受众类型
eligible\_user\_ids\_json Json 名单内的稳定用户标识集合
audience\_version Integer 受众名单版本号
list\_digest String 名单摘要（发布时锁定，改名单即换版）
account\_state\_check\_json Json 名单成员的账号状态核验结果
boundary\_case String 边界值判定：零 / 达上限 / 超限三种分别记
created\_at DateTime 创建时点（MP 自动填充）
权益包版本 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「权益包版本」

席位定义 （物理表 seat_definition，12 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
plan\_version\_id Long 商品版本 FK
seat\_type\_id String 席位类型（取字典条目，不写死枚举） FK
seat\_name String 席位名称（展示用，不参与计算）
role\_code String 角色稳定码
role\_version Integer 被引用的角色版本号
quantity Integer 席位数量
scope 枚举·SeatScope 平台范围（建模/运营）
dict\_snapshot\_id Long 本行引用的字典快照（发布时冻结语义） FK
created\_at DateTime 创建时点（MP 自动填充）
权益包版本 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「权益包版本」
运营角色 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「运营角色」
  • OPS v1\.9 本域新增表：席位定义、受众名单快照、商品现行发布指针（业务对象归本域，治理入口在 D7）。

D3 交易与履约

图上内容描述：交易与履约结构图：符号 18 / 连线 17（关联 8、依赖 9），18 个符号＝6 个本域实体＋9 个枚举＋3 个跨域锚点（空间、权益包版本、租户）；本域结构本轮未新增实体。

  • 下单簇：订单（order\_no 唯一、space\_id、payer\_user\_id、operator\_user\_id、beneficiary\_type/beneficiary\_id、plan\_version\_id、type=NEW/RENEW/UPGRADE/ADDON/EXPANSION、amount\_cents、snapshot\_json、quote\_expire\_at、status 六态）、订单明细（order\_id、item\_type、plan\_version\_id、quantity、amount\_cents、billing\_cycle）。
  • 支付与履约簇：支付尝试（attempt\_no 唯一、order\_id、channel、request\_at、amount\_cents、result=SUCCESS/FAILED/UNKNOWN、channel\_trade\_no、confirmed\_at）、履约记录（order\_id、status、started\_at、finished\_at、failure\_reason）、权益授予（idempotency\_key 唯一、source\_type、source\_ref\_id、space\_id、plan\_version\_id、granted\_at、operator\_id）。
  • 合同簇：合同（contract\_no 唯一、customer\_name、tenant\_id、amount、sign\_date、period\_start/period\_end、status、file\_store\_key 扫描件对象存储键），只作交付/财务留痕，不是一种独立授予来源。
  • 跨域锚点：空间（D1，受益空间）、权益包版本（D2，下单锁定版本）、租户（D1，签约主体）以引用块出现；本图引用面板还列出用户、权益、订阅、发票申请、生命周期状态、授权水位等下游块名，提示授予的辐射面但不画边。
  • 关键连线：8 条关联------权益包版本 1---0\.\.\* 订单（下单版本）、空间 1---0\.\.\* 订单（受益空间订单）、订单 1---1\.\.\* 订单明细（成交明细）、支付尝试 0\.\.\*---1 订单、订单 1---1 履约记录（履约处理）、订单 1---0\.\.\* 权益授予（来源事实）、租户 1---0\.\.\* 合同（签约）、合同 1---0\.\.1 权益授予（人工配置授予）。

为什么这么设计：交易三段分离（BR\-003）在表上就是三张表，四种授予来源收敛进 grant 一个幂等入口，重放安全是底线。

  • 三段分离落地：order 管承诺（quote\_expire\_at 内锁价锁条款）、payment\_attempt 管每次尝试（超时≠失败，UNKNOWN 是合法稳态，必须走 queryPaymentAttempt 核实）、fulfillment\+grant 管结果------被否"下单即支付一步"旧模型（旧 payment 流水表已核验 metaclass 删除），一步表无法证明"未重复扣款、未重复授予"。
  • grant 唯一入口：idempotency\_key 唯一键让订单回调、合同核销、License、试用四种 source\_type 共用同一授予动作，重复通知不重复授予（R12\.4）；权益落 space\_id\+plan\_version\_id，与 D2 的"按版本授予"边闭合。
  • contract 只指向 grant：S00 定版口径------合同核销后产生 grant\.source\_type=MANUAL\_CONFIG，不直连 subscription/entitlement。被否方案是"contract 1---1 subscription（依据合同）"，那会让合同绕过授予审计面，每份人工权益无法回溯到核销凭据与操作者。
  • 承接的硬约束：首期支付渠道只有支付宝，payment\_attempt\.channel 与 beneficiary\_type/beneficiary\_id 分开记"谁付钱"与"权益归谁空间"（代付场景）；operator\_user\_id 非空即合同轨人工建单留痕位。
  • 验收与留痕：评审取证靠 attempt\_no 对渠道流水、idempotency\_key 重放测试（同键两次只生效一次）、fulfillment\.failure\_reason 与审计日志（contract\.verify 动作）三面对账。
字段明细

下面按域逐表列出每个实体/物理表的全部字段：列名、类型、含义、枚举取值与键口径。字段名与类型、枚举取值取自 M\-Design「04详细设计」层 4 模型（枚举取值以「0\.数据类型」包为准）；含义一列以模型字段用途 \+ 需求/业务规则条款（D1\.xx、DEC\-xx、R7\.x、BR\-003 等）为准，无条款出处的按字段名与类型推导，不引入未经确认的数值参数（此类以"建议待确认"标注）。共 6 张表 / 53 列。

订单 （物理表 order，13 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
order\_no String 订单号 对外唯一，支付与发票都按此定位
space\_id Long 下单发生的空间 FK→space\.id；受益方另看 beneficiary\_\*
payer\_user\_id Long 付款人 FK→user\.id
operator\_user\_id Long 下单操作者 FK→user\.id；代下单时与付款人不同
beneficiary\_type BeneficiaryType 受益主体类型 个人空间、团队空间 决定权益落到个人空间还是团队空间
beneficiary\_id Long 受益主体 id 按 beneficiary\_type 指向 space 或 user
plan\_version\_id Long 下单锁定的版本 FK→plan\_version\.id；BR\-003 成交即锁快照
type OrderType 订单类型 新购、续购、升级、增购 升级单会伴随旧单折算退款
amount\_cents Integer 成交金额 以分为单位的整数
snapshot\_json Json 下单时的报价与能力快照 与版本当前配置解耦，运营改价不影响本单
quote\_expire\_at DateTime 报价有效期 超时需重新报价，不按旧价成交
status OrderStatus 订单状态 待支付、支付中、已支付、已履约、已取消、已关闭 交易三段分离：订单状态不等于履约与授予状态

订单明细 （物理表 order_item，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
order\_id Long 所属订单 FK→order\.id
item\_type ItemType 明细类型 权益包、功能模块、扩容包 权益包 / 功能模块 / 扩容包
plan\_version\_id Long 明细锁定的版本 FK→plan\_version\.id
quantity Integer 购买数量 扩容包为增量席位或存储数
amount\_cents Integer 明细金额 以分为单位；明细合计等于订单金额
billing\_cycle String 计费周期 与 plan\_version\.billing\_cycles 允许的取值一致

支付尝试 （物理表 payment_attempt，9 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
attempt\_no String 支付尝试号 对外唯一，渠道回调查单用
order\_id Long 对应订单 FK→order\.id
channel PaymentChannel 支付渠道 微信支付、支付宝、对公转账、线下合同 首期线上轨只接支付宝；对公汇款走合同轨，不落本表
request\_at DateTime 发起时间
amount\_cents Integer 本次尝试金额 以分为单位
result PaymentResult 结果 处理中、成功、失败、已关闭 处理中/未知不得当作失败重发，须先核实（BR\-003 幂等底线）
channel\_trade\_no String 渠道流水号 对账与退款依据
confirmed\_at DateTime 确认时间 回调或主动查询确认后写入

履约记录 （物理表 fulfillment，6 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
order\_id Long 履约的订单 FK→order\.id；一单一行，重放不改状态
status FulfillmentStatus 履约状态 待履约、履约中、已完成、已失败 支付成功与授予成功之间有异步窗口
started\_at DateTime 开始时间
finished\_at DateTime 完成时间
failure\_reason String 失败原因 供运营重试与客服定位，不返回给终端用户明文

权益授予 （物理表 grant，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
idempotency\_key String 授予幂等键 重放安全底线：同键只产生一次授予
source\_type EntitlementSourceType 来源类型 订单支付、合同核销、License导入、人工配置 四种来源统一进这一个入口（BR\-003）
source\_ref\_id Long 来源单据 id 按 source\_type 指向 payment / contract / license 等，不做跨表外键
space\_id Long 授予目标空间 FK→space\.id
plan\_version\_id Long 授予版本 FK→plan\_version\.id
granted\_at DateTime 授予时间 权益锚点由此起算（DEC\-05）
operator\_id Long 操作者 FK→ops\_account\.id；人工配置时必填

合同 （物理表 contract，10 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
contract\_no String 合同编号 对外唯一
customer\_name String 签约主体名称
tenant\_id Long 关联租户 FK→tenant\.id；合同轨的开通对象
amount Decimal 合同金额 单位为元，Decimal 存储
sign\_date Date 签约日期
period\_start Date 生效期起
period\_end Date 生效期止 到期只作留痕与提示，权益到期由 D2 状态机判
status ContractStatus 合同状态 已签订、生效中、已到期、已终止 已核销表示对公汇款到账并完成财务确认
file\_store\_key String 扫描件对象存储键 只做交付与财务留痕，不是一种独立授予来源

主套餐升级换绑 （物理表 main_plan_upgrade，14 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
actor\_user\_id Long 发起本次操作的用户 FK
space\_id Long 空间 FK
source\_plan\_id Long 被换下的旧主套餐 FK
target\_sales\_product\_id String 目标产品下的销售商品 FK
target\_plan\_version\_id Long 目标套餐版本 FK
state 枚举·UpgradeSwapState 状态
payment\_operation\_id String 新支付的受控操作号 FK
switch\_operation\_id String 切换现行指针的受控操作号 FK
refund\_operation\_id String 退旧余款的受控操作号 FK
fee\_waived Boolean 是否免手续费（按成交条款）
created\_at DateTime 创建时点（MP 自动填充）
confirmed\_at DateTime 用户确认时点
退款申请 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「退款申请」

赠送领取资格 （物理表 gift_claim_eligibility，15 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
offer\_id String 被领取的赠送商品 FK
offer\_version Integer 赠送商品版本（领取时锁定）
beneficiary\_space\_id Long 受益空间 FK
claim\_key String 领取幂等键：同商品同空间至多成功一次
state 枚举·GiftClaimState 状态
eligibility 枚举·GiftEligibility 领取资格判定
current\_main\_state 枚举·MainPlanState 领取方当前主套餐状态
actor\_user\_id Long 发起本次操作的用户 FK
display\_state 枚举·GiftDisplayState 展示态（生效 / 未知 / 阻止等，只用于显示）
order\_id Long 订单 FK
operation\_id String 受控操作号：同键幂等、结果未知只查这个号 FK
created\_at DateTime 创建时点（MP 自动填充）
consumed\_at DateTime 资格被消耗的时点
权益包版本 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「权益包版本」
  • OPS v1\.9 本域新增表：赠送领取资格、主套餐升级换绑（业务对象归本域，治理入口在 D7）。

D4 售后与财务

图上内容描述：售后与财务结构图：符号 17 / 连线 16（关联 8、依赖 8），17 个符号＝5 个本域实体＋8 个枚举＋4 个跨域锚点（订单、订单明细、权益、空间）；本轮新增对账批次与对账差异两块及 BatchCompleteness、DiscrepancyKind、DiscrepancyState、RefundKind 四个枚举，退款申请并补 refund\_kind 等五列。

  • 退款单（一）·受理与审批字段：application\_no 唯一、order\_id、order\_item\_id、space\_id、applicant\_user\_id、accepter\_id、finance\_reviewer\_id、status 七态------受理人、财务审核人分列，首期人工审核边界落在列上。
  • 退款单（二）·公式摊平字段：把退款公式整排摊成列------p\_amount\_cents、s\_at、e\_at、c\_at、d\_seconds、r\_seconds、b\_amount\_cents、rate\_snapshot、fee\_amount\_cents、refund\_amount\_cents，再加 stop\_entitlement\_id 与 channel\_refund\_no。
  • 升级换单：upgrade\_record（new\_order\_id、old\_order\_id、old\_entitlement\_id、space\_id、switched\_at、refund\_application\_id、compensation\_status），一行的语义就是"新单顶替旧单旧权益，并挂一张退款单"。
  • 发票申请：application\_no 唯一、order\_id、space\_id、applicant\_user\_id、title、tax\_no、reviewer\_id、status、invoice\_file\_key、applied\_at、issued\_at------只有申请与文件键，没有票面明细表。
  • 跨域锚点：订单、订单明细（D3）、权益（D2）、空间（D1）以引用块出现，其完整属性面板挂在各归属域图上；图面连线为源→目标方向，重数按蓝图口径。
  • 关键连线：8 条关联全点名------本轮新增对账批次---对账差异（批次含差异）与对账差异---订单（差异关联订单）两条；订单 1---0\.\.\* 退款申请（退款申请）、订单明细 1---0\.\.\* 退款申请（按项退款）、权益 1---0\.\.1 退款申请（停止权益）、订单 1---0\.\.\* 升级换单（升级替换）、订单 1---0\.\.\* 发票申请（开票申请）、空间 1---0\.\.\* 发票申请（空间开票）。

为什么这么设计：售后三单据全部以"可复核、可对账"为标准设计：公式摊平、换单独立留痕、发票只留人工轨迹。

  • 退款公式摊平（DEC\-07）：D=E−S 按秒、R=max\(0, E−max\(S,C\)\)、B=P×R÷D、F=B×r------P/S/E/C/D/R/B/r/F 全部列成字段并冻结 rate\_snapshot（费率购买时锁定），审核人与财务不重算即可复算核对；被否方案是只存 refund\_amount 结果值，那样审计上永远无法回答"这个金额怎么来的"。
  • 计算时点取停止时点：stop\_entitlement\_id 显式挂住被停权益（R7\.2），审核期间的使用时长不算未使用，s\_at/c\_at 分开记，权益撤销与退款动作可关联、不重复（R7\.5）。
  • 升级换单独立成表："新单全额付款---权益切换---旧单按比例退"三段可能跨天且各有失败分支（R5\.5/R5\.6），compensation\_status 挂退款失败的独立补偿态；被否方案是复用 order 加个 upgrade 标志位------那等于把权益替换和退款两条异步链路塞进一列，失败分支无处留痕。
  • 发票只建申请单：首期线上申请、人工开具回传文件（invoice\_file\_key\+issued\_at），不建开票系统对接表；已开票退款走发票调整不删原记录（R7\.6）。
  • 取舍与代价：人工受理审核意味着客服吞吐是瓶颈（R7\.1 首期不自动批准），换来的是金额可解释与费率快照可追溯；自动退款回滚不做，代价在单量上来后按公式字段自动化重算。
字段明细

下面按域逐表列出每个实体/物理表的全部字段：列名、类型、含义、枚举取值与键口径。字段名与类型、枚举取值取自 M\-Design「04详细设计」层 4 模型（枚举取值以「0\.数据类型」包为准）；含义一列以模型字段用途 \+ 需求/业务规则条款（D1\.xx、DEC\-xx、R7\.x、BR\-003 等）为准，无条款出处的按字段名与类型推导，不引入未经确认的数值参数（此类以"建议待确认"标注）。共 5 张表 / 70 列。

退款申请 （物理表 refund_application，26 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
application\_no String 退款申请号 对外唯一，客服与渠道对账用
order\_id Long 退款来源订单 FK→order\.id
order\_item\_id Long 退款的订单项 FK→order\_item\.id；R7\.4 项内不拆退部分席位或容量
space\_id Long 权益所在空间 FK→space\.id
applicant\_user\_id Long 申请人 FK→user\.id；个人本人、团队所有者或账单管理员（R7\.1）
accepter\_id Long 受理客服 FK→ops\_account\.id
finance\_reviewer\_id Long 财务审核人 FK→ops\_account\.id；首期不自动批准
status RefundStatus 申请状态 待受理、受理中、财务审核中、已退款、已驳回、已撤销 R7\.5：结果未知先核实，重复处理不重复退款
p\_amount\_cents Integer P·原项实付金额 以分为单位
s\_at DateTime S·原项服务开始时点 计算基准，取订单权益锚点
e\_at DateTime E·原项到期时点
c\_at DateTime C·退款确认时点 C \&lt; S 属赠送期内，按实付全额退
d\_seconds Long D·总服务秒数 D = E − S
r\_seconds Long R·剩余服务秒数 R = max\(0, E − max\(S, C\)\)
b\_amount\_cents Decimal B·按比例折算基数 B = P × R ÷ D，Decimal 存中间值，落账时精确到分四舍五入
rate\_snapshot Decimal r·退款费率快照 购买时锁定的费率，事后改配置不追溯本单
fee\_amount\_cents Integer F·手续费 F = B × r；升级换单路径不扣手续费（F=0）
refund\_amount\_cents Integer 实际退款金额 = B − F，升级退款为 B 全额
stop\_entitlement\_id Long 退款后停止的权益 FK→entitlement\.id；置为已撤销，不动交易与审计
channel\_refund\_no String 渠道退款流水号 与支付尝试的渠道流水对应，可追踪不重复
refund\_kind RefundKind 退款种类 权益退款、异常收款返还 权益退款与异常收款返还分列，后者不套普通费率（D4\.9）
receipt\_ref String 渠道流水号 异常收款按逐笔定位，与对账差异同口径
verified\_received\_cents Integer 核实的实收金额 以分为单位，须与渠道流水一致才可返还
returned\_cents Integer 已返还金额 受逐笔上限约束，超限转人工（D4\.9）
in\_flight\_cents Integer 在途金额 在途未定不得计入已退，防止重复返还

升级换单 （物理表 upgrade_record，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
new\_order\_id Long 新订单 FK→order\.id；DEC\-05 新单须全额付款
old\_order\_id Long 被替换的旧订单 FK→order\.id
old\_entitlement\_id Long 被替换的旧权益 FK→entitlement\.id；切换后置已替换
space\_id Long 升级发生的空间 FK→space\.id
switched\_at DateTime 切换时间 先核实新单支付成功再切换（R5\.5）
refund\_application\_id Long 随附的旧单退款申请 FK→refund\_application\.id；F=0 不扣手续费
compensation\_status CompensationStatus 补偿状态 无需补偿、待补偿、已补偿 R5\.6：退款失败不回退权益，进入独立补偿

发票申请 （物理表 invoice_application，12 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
application\_no String 开票申请号 对外唯一
order\_id Long 开票订单 FK→order\.id
space\_id Long 申请空间 FK→space\.id
applicant\_user\_id Long 申请人 FK→user\.id
title String 发票抬头
tax\_no String 纳税人识别号 个人抬头可为空
reviewer\_id Long 财务审核/开具人 FK→ops\_account\.id；R7\.6 人工开具
status InvoiceStatus 发票状态 待审核、已开具、已驳回、已作废 已开票的订单发生退款走发票调整，不删原记录
invoice\_file\_key String 发票文件存储键 用户上传下载入口，不落明文票面
applied\_at DateTime 申请时间
issued\_at DateTime 开具时间

对账批次 （物理表 reconciliation_batch，12 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
channel PaymentChannel 对账渠道 微信支付、支付宝、对公转账、线下合同 与 payment\_attempt\.channel 同一套渠道口径，跨渠道不得合并成一批
merchant\_id String 商户号 同一渠道可多商户，按商户分别成批
currency String 币种 与订单币种一致，跨币种不得合并成一批
window\_start DateTime 对账窗口起点 窗口右开，避免跨日重复计入
window\_end DateTime 对账窗口终点
source\_digest String 渠道对账单摘要 原文留档在对象存储，本列只做完整性校验
input\_version String 批次输入版本 同一窗口重跑生成新版本，不覆盖旧版
completeness BatchCompleteness 完整性判定 完整、不完整待核实 缺页或含未知交易即判不完整待核实，不得称无差异（D4\.7）
diff\_count Integer 差异条数 由明细汇总，仅作展示，判定以明细为准
created\_at DateTime 批次生成时间
closed\_at DateTime 结案时间 存在未结差异时禁止写入（D4\.8）

对账差异 （物理表 reconciliation_discrepancy，12 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
batch\_id Long 所属批次 FK→reconciliation\_batch\.id，一批多差异
kind DiscrepancyKind 差异类型 长款、短款、状态不一致、流水缺失、流水重复 长款/短款/状态不一致/流水缺失/流水重复，五类各自的处置路径不同
order\_id Long 关联订单 FK→order\.id；流水缺失类可为空
receipt\_ref String 渠道流水号 与 payment\_attempt 的渠道凭证同口径，逐笔可定位
amount\_cents Integer 差异金额 以分为单位，正为长款负为短款，不用浮点
state DiscrepancyState 工单状态 待核实、处理中、已结清、挂起 未结不得结案（D4\.8）
owner\_id Long 处置责任人 FK→ops\_account\.id，运营侧必须落到人
resolution\_ref String 处置凭证引用 返款单/补单号等外部凭证，不写自由文本结论
version String 工单版本 重开走新版本，保留上一版处置记录
created\_at DateTime 工单生成时间
closed\_at DateTime 工单关闭时间

退款渠道尝试 （物理表 refund_attempt，15 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
refund\_application\_id Long 所属退款申请 FK
attempt\_no Integer 操作号
initiator\_kind 枚举·RefundInitiator 发起方类型
operator\_user\_id Long 经办人（运营发起时记运营身份） FK
source\_stop\_ref String 权益来源停止的回执引用
actual\_stop\_at DateTime 权益实际停止时点（重算基数据此）
amount\_fen Integer 本次退款金额（分）
case\_state 枚举·OpsRefundCaseState 案件状态
channel\_ref String 渠道退款流水号
operation\_id String 受控操作号：同键幂等、结果未知只查这个号 FK
reserved\_fen Integer 已预留的余额（分），渠道未知时保留不回滚
created\_at DateTime 创建时点（MP 自动填充）
confirmed\_at DateTime 用户确认时点
退款申请 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「退款申请」
  • OPS v1\.9 本域新增表：退款渠道尝试（业务对象归本域，治理入口在 D7）。

D5 数据生命周期

图上内容描述：数据生命周期结构图：符号 19 / 连线 18（关联 9、依赖 9），19 个符号＝7 个本域实体＋9 个枚举＋3 个跨域锚点（空间、权益、调度任务记录）；本轮新增配额预占与清理保全两块及 ResourceClass、ReservationState、HoldReason、HoldState 四个枚举。

  • 政策与状态分表：生命周期策略（scope、retention\_days、grace\_days、backup\_purge\_days、updated\_by、updated\_at------90 天保留＋30 天宽限＋备份 30 天全部参数化）与生命周期状态（space\_id、stage 当前态、entitlement\_end\_at、purge\_due\_at、paused\_reason、updated\_at）各一张，政策是配置、状态是事实。
  • 单据簇：注销申请（subject\_type/subject\_id、applicant\_user\_id、status、requested\_at、withdraw\_deadline\_at 即 30 天撤回窗、completed\_at）、数据取回申请（space\_id、applicant\_user\_id、scope\_json、status、expired\_at）。
  • 清理留痕：数据清理记录（space\_id、executed\_at、operator\_id、audit\_ref\_id、backup\_purged\_at），每一次销毁都是一行可回溯事实。
  • 跨域锚点：空间（D1，状态唯一持有者）、权益（D2，到期触发源）、调度任务记录（D7：job\_code、biz\_key、next\_fire\_at）在本图作端点，提醒"到期→保留→宽限→清理"由定时任务驱动而非人肉推进。
  • 关键连线：9 条关联------本轮新增配额预占---空间（额度预占）与清理保全---空间（保全所属空间）两条；生命周期策略 1---0\.\.\* 生命周期状态（适用政策）、空间 1---1 生命周期状态、权益→生命周期状态（到期触发）、生命周期状态 1---0\.\.\* 数据清理记录（清理执行）、空间 1---0\.\.1 注销申请（注销或解散申请）/1---0\.\.\* 数据取回申请、调度任务记录→生命周期状态（定时驱动）。

为什么这么设计："政策与事实分表、单据与执行分表"让 90\+30、30 天撤回窗、备份 30 天三条硬时限各自有唯一落点和唯一证据链。

  • 政策不写进状态：retention\_days/grace\_days/backup\_purge\_days 独立成生命周期策略行------被否方案是把保留期直接做成 lifecycle\_state 的字段或代码常量，那样调整政策参数要么重写存量状态行、要么无法回答"当时依据哪版政策"。
  • 一个状态只有一个持有者：space 1---1 lifecycle\_state，stage 单列当前态；被否"多张表存同一状态"（注销单里存 stage、清理单里再存 stage），多副本必然漂移，到期取回遇故障时（R12\.6 保守降级优先）无权威可读。
  • 清理记录挂生命周期状态：图面边是 lifecycle\_state→purge\_record（清理执行），不是 S00 原稿草案的 closure\_request 1---0\.\.1 purge\_record------解散、到期、仅超额清理共用同一条执行链，注销单只是触发来源之一，这样 purge\_due\_at 推进到哪都能解释。
  • 承接的硬约束：withdraw\_deadline\_at 钉 30 天撤回期且注销不叠加 90\+30（R6\.4）；audit\_ref\_id 把每次清理反链审计日志（operator\_id\+动作），能回答"依据哪条政策、谁批准、何时执行"；paused\_reason 承接续费可取消（R6\.2）。
  • 取舍与代价：商业订单与审计记录不进本域清理链路（R6\.6 不随项目内容删除），数据政策与财务合规各走各的留存轨道；代价是平台需长期双轨对账，换来到期客户永远能取回自己的数据。
字段明细

下面按域逐表列出每个实体/物理表的全部字段：列名、类型、含义、枚举取值与键口径。字段名与类型、枚举取值取自 M\-Design「04详细设计」层 4 模型（枚举取值以「0\.数据类型」包为准）；含义一列以模型字段用途 \+ 需求/业务规则条款（D1\.xx、DEC\-xx、R7\.x、BR\-003 等）为准，无条款出处的按字段名与类型推导，不引入未经确认的数值参数（此类以"建议待确认"标注）。共 7 张表 / 56 列。

生命周期策略 （物理表 lifecycle_policy，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
scope PolicyScope 策略生效层级 平台级、租户级、空间级 平台级为默认值，租户/空间级可覆盖；不追溯缩短已承诺期限
retention\_days Integer 到期保留天数 自权益到期时点起，期内只读与取回可用（默认 90）
grace\_days Integer 待清理宽限天数 保留期后再 30 天，期内继续通知且续费可取消
backup\_purge\_days Integer 备份清除窗口 从实际删除时间起算，不按到期日一概推算
updated\_by Long 最近修改人 FK→ops\_account\.id
updated\_at DateTime 最近修改时间

生命周期状态 （物理表 lifecycle_state，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
space\_id Long 空间 FK→space\.id；一空间一行当前状态
stage LifecycleStage 当前阶段 正常使用、到期保留、宽限期、已清理 停止新建/编辑/导入发生在进入到期保留时，不删数据
entitlement\_end\_at DateTime 权益到期时点 保留期与宽限期的起算锚点
purge\_due\_at DateTime 预计清理时点 有效暂停会推迟此值并留原因
paused\_reason String 暂停清理的原因 如维权、法务保全、续费争议；为空表示未暂停
updated\_at DateTime 状态更新时间

数据清理记录 （物理表 purge_record，6 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
space\_id Long 被清理的空间 FK→space\.id
executed\_at DateTime 实际删除时间 业务数据删除的时点，备份清除从此起算
operator\_id Long 执行者 FK→ops\_account\.id；定时任务记系统操作者
audit\_ref\_id Long 对应审计日志 FK→audit\_log\.id；清理必留痕可查
backup\_purged\_at DateTime 备份清除时间 在 backup\_purge\_days 窗口内完成

注销申请 （物理表 closure_request，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
subject\_type ClosureSubjectType 注销对象类型 个人空间、团队 个人空间 / 团队；账号注销另见 D1 的 account\_closure\_request
subject\_id Long 注销对象 id 按 subject\_type 指向 space 或 tenant，不做跨表外键
applicant\_user\_id Long 申请人 FK→user\.id；团队须所有者或授权管理员
status ClosureStatus 申请状态 待审核、待生效、已完成、已撤回 待生效即处于撤回期
requested\_at DateTime 申请时间
withdraw\_deadline\_at DateTime 撤回截止时点 默认 30 天，不叠加到期保留的 90\+30；期满再复核才清理
completed\_at DateTime 完成时间 撤回不恢复已到期的商业权益

数据取回申请 （物理表 data_takeaway_request，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
space\_id Long 取回来源空间 FK→space\.id；到期保留期内允许授权取回
applicant\_user\_id Long 申请人 FK→user\.id；取回不绕过授权（DEC\-06）
scope\_json Json 取回范围 JSON：项目/文件清单；增值导出不随基础取回开放
status TakeawayStatus 取回状态 待生成、已生成、已下载、已过期 已生成后提供下载链接，过期需重新申请
created\_at DateTime 申请时间
expired\_at DateTime 取回包有效期 超时未下载即失效

配额预占 （物理表 quota_reservation，12 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键 自增 id 仅内部使用，跨域引用一律走 operation\_id
space\_id Long 预占归属的空间 FK→space\.id；预占按空间计量，不按用户
plan\_version\_id Long 按哪个权益包版本判定上限 FK→plan\_version\.id，额度上限取自该版本的容量口径
resource\_class ResourceClass 被预占的资源种类 原始模型、历史版本、备份、临时包、运行日志、访问流量 六类分列，计费量与物理量不得互称（D5\.9）
reserved\_bytes Integer 本次预占的字节数 仅 resource\_class 为占用类时有值；单位与套餐容量口径一致
reserved\_projects Integer 本次预占的项目数 仅 resource\_class 为项目类时有值
state ReservationState 预占状态 预占中、已结算、已释放、结果未知 结果未知不得重复占额，只能查原操作（D5\.7）
idempotency\_key String 同键幂等 唯一键；同键重复提交返回原预占，不新增占额（D5\.7）
operation\_id String 对应的异步操作号 结算与释放都按本号回查，不重新计算额度
expires\_at DateTime 预占到期时间 到期未结算由后台任务释放；数值参数建议待确认
settled\_at DateTime 结算时间 按实际增量结算后置值；与 created\_at 差即预占驻留时长
created\_at DateTime 预占创建时间 写入即记录，供容量核对与审计

清理保全 （物理表 purge_hold，9 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
space\_id Long 被保全数据所属空间 FK→space\.id
dataset\_ref String 被保全的数据集标识 指向具体数据集而非整空间，恢复时按本列定位
reason HoldReason 保全原因 交易争议、法定保全、归属不明、依赖不可核实 归属不明的数据集不得自动清理（D5\.11）
affected\_scope Json 受影响范围快照 Json：记录项目、文件、派生任务的边界，避免误停范围扩大
holder\_id Long 保全责任人 FK→user\.id；法定保全须可追到人
state HoldState 保全状态 保全中、已解除 已解除后才允许重新进入清理队列
created\_at DateTime 保全生效时间 保全期间清理任务只跳过不删除（D5\.10）
released\_at DateTime 保全解除时间 解除原因走 audit\_log 留痕，本表不存备注

D7 平台运营治理

图上内容描述 ：平台运营治理结构图：符号 70 / 连线 67（关联 30、依赖 37），70 个符号＝35 个本域实体＋32 个枚举＋3 个跨域锚点（租户、权益包版本、空间）。OPS v1\.9 这轮本域实体由 27 涨到 35（新增后台人员邀请单、后台恢复申请、可信功能动作目录、通用字典、字典条目、字典引用快照、角色引用记录、权限模板影响预览），有名关联补 7 条；本轮 19 个新枚举只进了 0\.数据类型 包，尚未画到结构图上。

  • 运营 RBAC 簇：运营账号（username、real\_name、password\_hash、status，与 C 端用户隔离）、运营角色（code、name）、运营角色授予（account\_id\+role\_id）。
  • 内容与版本簇：公告（title、content、target、status、publish\_at、created\_by）、公告已读（announcement\_id、user\_id、read\_at）、客户端版本（version、platform、channel、store\_key、release\_note、status、published\_at）、发布校验记录（plan\_version\_id、check\_type、passed、detail、operator\_id、checked\_at）。
  • 授权运行时簇：授权水位（space\_id 唯一、epoch、updated\_at）、授权变更事件（epoch、space\_id、event\_type、emitted\_at、delivered\_at、latency\_ms）、授权降级事件（space\_id、reason、blocked\_actions、started\_at、recovered\_at）。
  • 独立部署凭证簇（一）：部署实例（instance\_code、tenant\_id、env\_type、status、registered\_at）、授权凭证（license\_no 唯一、instance\_id、tenant\_id、type=TERM/PERPETUAL、snapshot\_version、valid\_from/valid\_to、entitlement\_snapshot、signature、issuer\_id、issued\_at、imported\_by、imported\_at、status）。
  • 独立部署凭证簇（二）：凭证导入记录（license\_id、instance\_id、result、failure\_reason、imported\_at、imported\_by）、凭证撤销（license\_no、revoked\_at、revoked\_by、reason）、时钟异常记录（instance\_id、detected\_at、offset\_seconds、action、recovered\_at、reviewed\_by）。
  • 留痕与调度：审计日志（actor\_id、actor\_type、action、target\_type、target\_id、detail、ip、created\_at）、调度任务记录（job\_code、biz\_key、status、next\_fire\_at）；审计日志全域共用、主责归本域，不单列审计域。
  • 关键连线：23 条关联------本轮新增 8 条：通知意图---通知模板（套用模板）、通知投递---通知意图（投递记录）、验收执行---验收用例（用例执行）、验收证据件---验收执行（执行证据）、缺陷单---验收执行（执行缺陷）、缺陷单---验收用例（缺陷归属用例）、负载画像---性能基线项（画像支撑基线）、容量保护记录---部署实例（实例容量保护）；租户 1---0\.\.\* 部署实例 1---0\.\.\* 授权凭证，凭证 1---0\.\.\* 凭证导入记录/凭证撤销，部署实例 1---0\.\.\* 时钟异常记录；运营账号/运营角色 1---0\.\.\* 运营角色授予，客户端版本 0\.\.\*---1 运营账号（版本维护），权益包版本 1---0\.\.\* 发布校验记录；公告 1---0\.\.\* 公告已读；空间 1---1 授权水位→1---0\.\.\* 授权变更事件，空间 1---0\.\.\* 授权降级事件/审计日志，运营账号→审计日志（操作留痕）。

为什么这么设计：本域一张图装下"运营后台 \+ 授权运行时 \+ 离线凭证"三种性质不同的块，靠分簇与留痕字段而非拆分域来治理。

  • 域 ≠ 部署单元：授权三件套（authz\_state/authz\_change\_event/authz\_incident）模型上计入 D7，运行时是横切基础设施、内嵌在 saas\-core 用户域（2026\-09\-23 定版，纠正早期"独立鉴权网关"遗留写法）；画在 D7 图上单列一簇，就是提醒评审别把它并进运营后台进程。
  • epoch 与事件表分开：状态一行的 space\_id 唯一 \+ epoch 单调（水位），事件 append\-only 带 emitted\_at/delivered\_at/latency\_ms------被否"多张表存同一状态"与"只存事件无水位"（后者每次鉴权都要回放事件流算当前态，守不住撤权 5 秒验收）；5 秒时效直接读 authz\_change\_event\.latency\_ms 取数验收（R10\.2）。
  • 降级与异常只限权不删数：授权降级事件的 blocked\_actions 是动作清单白名单反转，时钟异常记录只登记 offset\_seconds 与处置（R9\.5：暂停新增编辑、保留只读与取回），离线环境无法实时吊销，故撤销必须经凭证撤销\+高版本完整快照这条可信通道。
  • 原 D6 并入本域（归域依据）：License 签发、导入、撤销与运营治理共用同一套审计与凭证设施（蓝图 §5 域数口径：不设独立 License 图），图面把 5 块挂在同一 BDD 上、以租户/部署实例两条边衔接。
  • 发布无审批但必有校验（DEC\-11/R11\.2）：publish\_check\_record 以 check\_type/passed/detail/operator\_id 把系统校验留痕成行------被否方案是"发布仅置 status=PUBLISHED 不留痕"，那 DEC\-11 的"配置完整即发布、无需审批"就失去唯一证据；运营账号与 C 端 user 分表，边界即 R2\.4 的交付签发隔离。
字段明细

下面按域逐表列出每个实体/物理表的全部字段：列名、类型、含义、枚举取值与键口径。字段名与类型、枚举取值取自 M\-Design「04详细设计」层 4 模型（枚举取值以「0\.数据类型」包为准）；含义一列以模型字段用途 \+ 需求/业务规则条款（D1\.xx、DEC\-xx、R7\.x、BR\-003 等）为准，无条款出处的按字段名与类型推导，不引入未经确认的数值参数（此类以"建议待确认"标注）。共 27 张表 / 212 列。

部署实例 （物理表 deployment_instance，6 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
instance\_code String 部署实例编码 独立部署环境的稳定标识，License 绑定此码
tenant\_id Long 对应客户租户 FK→tenant\.id
env\_type InstanceEnvType 环境类型 生产、预发、测试、开发 同一客户可并存生产与测试实例，凭证只在匹配环境生效
status InstanceStatus 实例状态 已注册、在线、离线、已注销 离线只影响心跳观测，不据此自动删数据
registered\_at DateTime 注册时间

授权凭证 （物理表 license，16 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
license\_no String 凭证编号 对外唯一，撤销与导入记录都按此定位
instance\_id Long 绑定的部署实例 FK→deployment\_instance\.id；同实例同租户只留一份当前有效快照
tenant\_id Long 客户租户 FK→tenant\.id
type LicenseType 凭证类型 试用凭证、正式凭证、临时凭证 试用/正式/临时；临时凭证用于交付期过渡，须约定到期
snapshot\_version Integer 快照版本号 递增；导入只接受不低于当前的高版本（DEC\-08）
valid\_from DateTime 生效时间 期限授权按明确起止生效
valid\_to DateTime 到期时间 到期限制新增与编辑，保留只读与取回，不自动删数据
entitlement\_snapshot Json 权益内容快照 JSON：席位、容量、能力清单，运行时按此判定
signature String 凭证签名 防篡改；签名校验失败即拒绝导入
issuer\_id Long 签发人 FK→ops\_account\.id
issued\_at DateTime 签发时间
imported\_by Long 最近导入操作者 FK→ops\_account\.id；交付或支持人员
imported\_at DateTime 最近导入时间
status LicenseStatus 凭证状态 草稿、已签发、已生效、已过期、已撤销、已替换 已替换由新版本导入产生；已撤销不再放行且不可复用了结
generation Long License 高水位代号 单调递增的生成号，导入替换按本列比高低

凭证导入记录 （物理表 license_import_record，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
license\_id Long 导入的凭证 FK→license\.id
instance\_id Long 导入到哪个实例 FK→deployment\_instance\.id
result LicenseImportResult 导入结果 导入成功、签名校验失败、已过期、版本冲突、重复导入 DEC\-08：先完整校验再整体替换，失败保留原授权
failure\_reason String 失败原因 供交付侧定位，不返回给客户明文
imported\_at DateTime 导入时间
imported\_by Long 导入人 FK→ops\_account\.id
accepted\_generation Long 本次接受的代号 低于现行高水位即判版本过低拒绝，不覆盖

凭证撤销 （物理表 license_revocation，5 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
license\_no String 被撤销的凭证编号 按编号撤销，凭证行仍保留以便追溯
revoked\_at DateTime 撤销时间 撤销即时生效，运行侧下一轮校验即拒
revoked\_by Long 撤销操作者 FK→ops\_account\.id
reason String 撤销原因 如合同终止、泄露风险；审计留痕

时钟异常记录 （物理表 clock_anomaly_record，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
instance\_id Long 异常实例 FK→deployment\_instance\.id
detected\_at DateTime 检出时间 以本地时钟记录，配合偏移量还原
offset\_seconds Integer 时钟偏移秒数 负值即回拨；检测阈值属技术设计验收项
action ClockAnomalyAction 处置动作 仅记录、告警、限制功能、冻结凭证 DEC\-09：不直接认定永久失效，也不自动延长有效期
recovered\_at DateTime 恢复时间 环境修正或导入恢复凭证后回填
reviewed\_by Long 核验人 FK→ops\_account\.id；授权交付或支持人员

运营账号 （物理表 ops_account，5 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
username String 登录名 与 C 端 user 完全隔离，不同表不同认证链
real\_name String 真实姓名 审计与工单定位用
password\_hash String 口令散列 不保存明文
status OpsAccountStatus 账号状态 正常、已停用 停用即时失效，历史留痕不删账号

运营角色 （物理表 ops_role，3 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
code String 角色编码 如 SUPER\_ADMIN/OPS/CS/FINANCE，按最小职责划分
name String 角色名称

运营角色授予 （物理表 ops_role_grant，2 列）

字段 类型 含义 枚举取值 键与取值口径
account\_id Long 运营账号 FK→ops\_account\.id；与 role\_id 组成唯一键
role\_id Long 运营角色 FK→ops\_role\.id

发布校验记录 （物理表 publish_check_record，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
plan\_version\_id Long 被校验的版本 FK→plan\_version\.id
check\_type PublishCheckType 校验类型 完整性校验、能力项校验、价格校验 DEC\-11/R11\.2：发布不经人工审批，但必须通过这些数据校验
passed Boolean 是否通过 任一校验未过即不允许发布
detail Json 校验明细 JSON：缺失项、非法项、不一致项清单
operator\_id Long 触发人 FK→ops\_account\.id
checked\_at DateTime 校验时间

公告 （物理表 announcement，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
title String 标题
content String 正文
target AnnouncementTarget 投放范围 全部用户、按租户、按版本 按租户/按版本定向；全员公告不可覆盖协议同意的强制披露
status AnnouncementStatus 公告状态 草稿、已发布、已下线 下线只停止展示，已读记录保留
publish\_at DateTime 发布时间
created\_by Long 创建人 FK→ops\_account\.id

公告已读 （物理表 announcement_read，3 列）

字段 类型 含义 枚举取值 键与取值口径
announcement\_id Long 公告 FK→announcement\.id；与 user\_id 组成唯一键
user\_id Long 已读用户 FK→user\.id
read\_at DateTime 已读时间

审计日志 （物理表 audit_log，9 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
actor\_id Long 操作者 id 按 actor\_type 分别指向 user / ops\_account，系统任务为固定系统身份
actor\_type ActorType 操作者类型 用户、运营、系统 区分人祸与系统误操作，检索必带
action String 动作编码 形如 模块\.动作：subscribe\.expire、tenant\.freeze、contract\.verify
target\_type String 被操作对象类型 与 target\_id 组成可回溯定位
target\_id Long 被操作对象 id
detail Json 操作详情 JSON；不得记录明文口令、验证码等可重放凭证（D1\.36 同口径）
ip String 来源 IP 脱敏策略由安全基线约定
created\_at DateTime 发生时间 审计只追加，不随业务对象删除（R6\.6）

调度任务记录 （物理表 job_record，5 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
job\_code String 任务编码 如到期扫描、试用转正提醒、清理前复核
biz\_key String 业务幂等键 如 租户 id:日期；重复触发不重复执行
status JobStatus 执行状态 待执行、执行中、成功、失败 失败可重试，重试不重复通知
next\_fire\_at DateTime 下次触发时间

客户端版本 （物理表 client_version，8 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
version String 版本号 语义化版本
platform ClientPlatform 平台 Windows、Linux、macOS 建模客户端桌面三平台；网页端不走安装包升级
channel ClientChannel 发布通道 正式、灰度、内测 灰度/内测用于分批放量，正式通道才对全量可见
store\_key String 安装包存储键 对象存储键，不下发裸路径
release\_note String 版本说明
status ClientVersionStatus 版本状态 草稿、已发布、已下架 下架后旧客户端仍可运行，只是不再收到该版本
published\_at DateTime 发布时间

授权水位 （物理表 authz_state，3 列）

字段 类型 含义 枚举取值 键与取值口径
space\_id Long 空间 FK→space\.id；一空间一行，是本表主键
epoch Long 授权水位号 每次权益/席位/撤权变更递增，运行时比对判断本地缓存是否过期
updated\_at DateTime 水位变更时间 运营侧据此看变更时刻与降级的时间关系

授权变更事件 （物理表 authz_change_event，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
epoch Long 本事件对应的水位 与 authz\_state\.epoch 一致，消费方按序处理不重复生效
space\_id Long 空间 FK→space\.id
event\_type AuthzEventType 事件类型 权益授予、权益撤销、席位变更、降级恢复 降级恢复用于故障后回补
emitted\_at DateTime 发出时间
delivered\_at DateTime 确认消费时间 R12\.3/DEC\-10：正常运行下页面与协同连接须在 5 秒内响应，此列即验收依据
latency\_ms Integer 端到端延迟 毫秒；超阈值进告警，不作为放行旧权限的宽限

授权降级事件 （物理表 authz_incident，6 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
space\_id Long 受影响空间 FK→space\.id
reason String 降级原因 如权限服务不可用、事件消费超时
blocked\_actions Json 被拦动作清单 JSON：保守降级只放通只读与取回类动作
started\_at DateTime 降级开始时间
recovered\_at DateTime 恢复时间 为空表示仍在降级中

通知模板 （物理表 notification_template，11 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
type NotificationType 通知类别 订阅提醒、模型治理案件、售后进度、资料取回 与 notification\_intent\.type 同一套类别，类别下才有版本唯一性
locale String 语言 如 zh\-CN；同一类别同一渠道同一语言只一个现行版本
channel NotificationChannel 投递渠道 站内、邮件、短信 站内/邮件/短信；模板与渠道绑定，不允许运行时改渠道
version String 模板版本号 发布即锁定不可改写，纠错走新版本（D7\.18）
title String 标题模板 含变量占位，正文里不写业务硬编码文案
summary String 摘要模板 列表页与推送用的短文案
state TemplateState 模板状态 草稿、已发布、已停用 只有已发布且现行版本可被意图套用
content\_digest String 模板内容摘要 投递记录留摘要，事后能证明当时发的是哪一版
published\_at DateTime 发布时间 每类通知每部署责任域只一个现行版本（D7\.18）
published\_by Long 发布人 FK→user\.id，发布动作入审计

通知意图 （物理表 notification_intent，12 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
business\_event\_id String 业务事件号 由业务模块给出，通知侧不回查业务表
event\_version String 业务事件版本 与事件号共同构成去重键的两元（D7\.17）
type NotificationType 通知类别 订阅提醒、模型治理案件、售后进度、资料取回 决定套用哪一类模板
recipient\_id Long 接收者 FK→user\.id，去重按接收者分列
tenant\_id Long 租户上下文 FK→tenant\.id，责任域归属
space\_id Long 空间上下文 可为空；有对象级上下文时便于跳转
object\_ref String 业务对象引用 只存引用不存内容，避免通知正文与业务数据两张皮
dedup\_key String 去重键 唯一键：同事件版本同接收者只一条意图（D7\.17）
template\_id Long 套用的模板 FK→notification\_template\.id，取发布时的现行版本
occurred\_at DateTime 业务事件发生时间 以业务侧时间为准，不用入队时间
created\_at DateTime 意图写入时间

通知投递 （物理表 notification_delivery，9 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
intent\_id Long 所属意图 FK→notification\_intent\.id，失败重试沿原意图（D7\.19）
recipient\_id Long 接收者 与意图一致，冗余存储便于按人查未读
channel NotificationChannel 实际投递渠道 站内、邮件、短信 继承意图套用的模板渠道
state DeliveryState 投递状态 排队、已发送、已送达、明确失败、待核实 明确失败才重试；待核实不得报已送达（D7\.19）
attempt\_count Integer 尝试次数 受控重试上限的参数建议待确认
last\_attempt\_at DateTime 最近一次尝试时间
read\_state ReadState 已读状态 未读、已读、批量已读失败、结果未知 批量已读部分失败即整体结果未知，不返回伪成功
read\_at DateTime 已读时间

验收用例 （物理表 acceptance_case，15 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
code String 用例编号 全局唯一，评审与执行都按本列引用
title String 用例标题
module String 归属模块 与部署模块同名口径，便于按模块汇总
requirement\_refs Json 覆盖的需求条款 Json 数组，存 Dn\.x 编号；六层证据分别出结论（D7\.22）
risk\_refs Json 关联风险项 Json 数组
steps Json 步骤 Json 数组，一步一项，禁止用散文串
expected Json 预期结果 Json 数组，与步骤一一对应
status AcceptanceStatus 用例状态 设计、阻塞、待执行、执行中、通过、失败、豁免 设计/阻塞/待执行/执行中/通过/失败/豁免；豁免须带 waiver\_ref
executor\_id Long 执行人 FK→user\.id
reviewer\_id Long 复核人 FK→user\.id，执行与复核可同人但须留痕
started\_at DateTime 最近一次执行开始时间
finished\_at DateTime 最近一次执行结束时间
waiver\_ref String 豁免凭证 外部审批单号；无凭证不得置豁免
blocked\_by String 阻塞原因 文本\+编号，阻塞项不计入通过率分母

验收执行 （物理表 acceptance_run，15 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
case\_id Long 所属用例 FK→acceptance\_case\.id
run\_no String 执行号 用例内递增，复测必新建执行（D7\.20）
previous\_run\_id Long 上次执行 自引用 FK→acceptance\_run\.id，失败记录必须保留（D7\.20）
source\_revision String 来源修订标识 需求/代码的修订号，执行须绑定来源（D7\.21）
dirty\_digest String 工作副本摘要 非干净构建时必填，防止"本地过了"
build\_id String 构建号
artifact\_digest String 构建产物摘要 与证据件 digest 同算法可互证（D7\.21）
environment\_ref String 环境引用 指向部署实例，不用自由文本
clock\_ref String 时钟基准 时间敏感用例须记录，避免时钟回拨影响判读
data\_fixture\_ref String 数据夹具引用 可重放同一数据集
actual\_inputs Json 实际输入 Json，记录真实参数
result RunResult 执行结果 通过、失败、阻塞、未执行 通过/失败/阻塞/未执行；未执行不得填通过
executed\_at DateTime 执行时间
executor\_id Long 执行人 FK→user\.id

验收证据件 （物理表 evidence_artifact，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
run\_id Long 所属执行 FK→acceptance\_run\.id
kind EvidenceKind 证据种类 需求文档、原型截图、接口报文、测试记录、安全证据、性能数据、专业审核结论 六层证据分类，文档/原型/接口/测试/安全/性能/专业审核
object\_ref String 证据指向对象 需求条款或接口名，与用例 requirement\_refs 对齐
digest String 证据摘要 与执行记录 artifact\_digest 同算法，防证据被替换
storage\_uri String 存放位置 对象存储 URI，不存二进制入表
captured\_at DateTime 取证时间

缺陷单 （物理表 defect_record，9 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
run\_id Long 发现该缺陷的执行 FK→acceptance\_run\.id
case\_id Long 归属用例 FK→acceptance\_case\.id，与 run 冗余便于按用例统计
severity DefectSeverity 严重级别 阻断、严重、一般、轻微 阻断级缺陷不得判通过，直接决定放行
state DefectState 缺陷状态 打开、修复中、待复测、已关闭 待复测必须新建执行验证，不可原执行改判
description String 缺陷描述 复现步骤与现象，不含结论
raised\_by Long 提出人 FK→user\.id
raised\_at DateTime 提出时间
closed\_at DateTime 关闭时间 关闭依据是复测执行通过

性能基线项 （物理表 perf_baseline，10 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
metric\_key String 指标键 如接口 P95、启动时长，全局唯一命名
scenario\_ref String 场景引用 指向负载画像组合，指标不脱离场景存在
target\_value String 目标值 字符串存储以保留单位与统计口径，不定死数值
statistic PerfStatistic 统计口径 平均、P95、P99、最大、吞吐 平均/P95/P99/最大/吞吐，缺口径的目标值无效（D7\.24）
measured\_value String 实测值 由验收执行证据回填
status BaselineStatus 基线状态 候选、已签认、实测达标、实测未达标 候选/已签认/实测达标/实测未达标四态分列（D7\.24）
signed\_by Long 签认人 FK→user\.id，未签认不得进入达标判定
signed\_at DateTime 签认时间
note String 备注 只记录口径说明，不放未经确认的数值

负载画像 （物理表 load_profile，7 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
name String 画像项名称
dimension LoadDimension 所属维度 用户与连接、租户分布、团队与授权、项目与模型、文件与资料包、操作组合、后台任务、环境与网络、缓存与恢复、目标与统计 十维之一，缺维即画像不完整（D7\.23）
value String 取值 字符串存原值与单位
source ProfileSource 来源 实测、估算、待确认 实测/估算/待确认；待确认不得当作已签认（D7\.23）
confirmed\_by Long 签认人 FK→user\.id
confirmed\_at DateTime 签认时间 十维未签认不得填零或无限制（D7\.23）

容量保护记录 （物理表 capacity_guard_record，10 列）

字段 类型 含义 枚举取值 键与取值口径
id Long 主键
resource\_class ResourceClass 资源种类 原始模型、历史版本、备份、临时包、运行日志、访问流量 与配额预占同一套资源分类，两轨不得互称（D5\.9）
guard\_state GuardState 综合保护状态 正常、软告警、硬保护、未知 正常/软告警/硬保护/未知
cpu\_state GuardState CPU 维度状态 正常、软告警、硬保护、未知 分维度记录，便于定位是哪一维触发
queue\_state GuardState 队列维度状态 正常、软告警、硬保护、未知
bandwidth\_state GuardState 带宽维度状态 正常、软告警、硬保护、未知
incident\_id String 关联事件号 与审计日志同键，平台侧保护不写客户数据
operator\_id Long 处置人 FK→user\.id
recovery\_evidence\_ref String 恢复证据 指向验收证据件，无证据不得判恢复
created\_at DateTime 记录时间

权限模板影响预览 （物理表 template_impact_preview，14 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
role\_code String 角色稳定码
draft\_revision Integer 草稿修订号
pointer\_version Integer 现行指针版本
binding\_set\_version String 绑定集版本
added\_actions\_json Json 本次新增动作
removed\_actions\_json Json 本次撤销动作
affected\_account\_count Integer 受影响账号数
still\_allowed\_json Json 其他角色仍允许的动作
actually\_revoked\_json Json 本次真正失权
guard\_blocked Boolean 被守卫条件拦下的动作清单
confirmed\_by Long 确认发布的人（治理身份）
created\_at DateTime 创建时点（MP 自动填充）
运营角色 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「运营角色」

角色引用记录 （物理表 role_reference_record，9 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
role\_code String 角色稳定码
role\_version Integer 被引用的角色版本号
referrer\_type String 引用方类型
referrer\_id String 引用方对象 FK
referrer\_version String 引用方自己的版本号
reference\_checked\_at DateTime 最近一次引用核验时点
unknown\_fact Boolean 核验读不到时留下的未知事实（不得当成「无引用」）
运营角色 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「运营角色」

字典引用快照 （物理表 dictionary_reference_snapshot，10 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
immutable\_id String 引用不变式 itemId@version：历史读取的唯一句柄 FK
item\_id Long dictionary\_item\.id FK
item\_version Integer 被锁定时的条目版本
semantic\_json Json 冻结的语义快照（base\_unit / multiplier / 展示名）
source\_version String 引用方自身版本（商品版本/协议版本），便于回溯
owner\_type String 引用方类型：PLAN\_VERSION 商品版本 / AGREEMENT 协议 / ORDER 订单 ...
owner\_id String 引用方稳定标识 FK
created\_at DateTime 创建时点（MP 自动填充）
字典条目 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「字典条目」

字典条目 （物理表 dictionary_item，17 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
dictionary\_id Long 所属 dictionary\.id FK
item\_code String 条目稳定码（DAY / MONTH / HALFYEAR / SERVICE / PRIVACY ...）
display\_name String 展示名（中英词条走 i18n，展示名不参与任何计算）
base\_unit 枚举·PeriodBaseUnit 周期基本单位：DAY 天 / MONTH 自然月；非周期字典为 NULL
multiplier Integer 正整数倍率：半年=MONTH×6、周=DAY×7；与 base\_unit 同时为空即非周期条目
sort Integer 界面排序号
version Integer 条目版本：改名或改语义都出新版本，旧版本仍可被历史引用
status 枚举·DictionaryItemState ACTIVE 启用 / INACTIVE 停用；停用只挡新引用
change\_reason String 最后一次变更原因（必填才允许写入，OPS v1\.9 §4\.4）
expected\_version Integer 提交时带的期望版本（CAS 依据，界面不展示）
idempotency\_key String 幂等键：同意图重复提交返回原结果
created\_at DateTime 创建时点（MP 自动填充）
updated\_at DateTime 最后更新时点（MP 自动填充）
通用字典 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「通用字典」
字典引用快照 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「字典引用快照」
协议类型实例 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「协议类型实例」

通用字典 （物理表 dictionary，9 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
dictionary\_code String 字典稳定码（AGREEMENT\_TYPE / ENTITLEMENT\_PERIOD ...），客户端不得自造
display\_name String 展示名（中英词条走 i18n，展示名不参与任何计算）
domain 枚举·DictionaryDomainType 用途段：AGREEMENT\_TYPE 协议类型 / ENTITLEMENT\_PERIOD 权益周期 / OTHER 其它业务枚举
current\_version Integer 字典版本号：条目变更递增，供引用方锁定
status 枚举·DictionaryItemState ACTIVE 启用 / INACTIVE 停用；停用只挡新引用
created\_at DateTime 创建时点（MP 自动填充）
updated\_at DateTime 最后更新时点（MP 自动填充）
字典条目 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「字典条目」

可信功能动作目录 （物理表 function_action，11 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
action\_id String 动作稳定码 FK
scope 枚举·RolePlatformScope 平台范围（建模/运营）
display\_name String 展示名（中英词条走 i18n，展示名不参与任何计算）
guard\_json Json 业务守卫引用（需要哪些身份/状态/额度前提），实际准入仍由来源服务判定
resource\_acl\_required Boolean 1=动作允许之外仍要主产品资源 ACL，角色模板不得绕过数据隔离
state 枚举·ActionAvailability 状态
registered\_by String 登记批次标识（研发登记，非运营手填）
version Integer 条目版本：改名或改语义都出新版本，旧版本仍可被历史引用
created\_at DateTime 创建时点（MP 自动填充）
运营角色 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「运营角色」

后台恢复申请 （物理表 staff_restore_request，12 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
staff\_account\_id Long 后台人员账号 FK
reason String 操作原因（必填）
token\_digest String 邀请令牌摘要
state 枚举·InvitationState 状态
expires\_at DateTime 失效时点
verified\_at DateTime 本人重新验证通过的时点
new\_session\_id String 重验通过后新签发的会话（旧会话不复活） FK
failed\_reason String 失败、撤回或到期的原因
operation\_id String 受控操作号：同键幂等、结果未知只查这个号 FK
created\_at DateTime 创建时点（MP 自动填充）
运营账号 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「运营账号」

后台人员邀请单 （物理表 staff_invitation，13 列）

字段 类型 含义 键
id Long 雪花 ID（应用层 ASSIGN\_ID，库侧不自增） PK
staff\_account\_id Long 后台人员账号 FK
target\_phone String 受邀手机号（加密存储）
duties\_json Json 职责清单
reason String 操作原因（必填）
token\_digest String 邀请令牌摘要
state 枚举·InvitationState 状态
expires\_at DateTime 失效时点
accepted\_at DateTime 接受时点
supersedes\_invitation\_id Long 被本条取代的旧邀请 FK
operation\_id String 受控操作号：同键幂等、结果未知只查这个号 FK
created\_at DateTime 创建时点（MP 自动填充）
运营账号 （未标型） 关联导航端点（模型侧引用，非物理列）：指向「运营账号」
  • 本轮新增 15 张表：D7 8 张（后台人员邀请单、后台恢复申请、可信功能动作目录、通用字典、字典条目、字典引用快照、角色引用记录、权限模板影响预览），另有 7 张按业务归属插到各自域的字段明细末尾（D2 席位定义/受众名单快照/商品现行发布指针、D3 赠送领取资格/主套餐升级换绑、D4 退款渠道尝试、D1 协议类型实例）。全模型现 95 表 / 1109 列 / 114 枚举。
  • 本轮新增 19 个枚举 ：ActionAvailability（3 值）、AgreementPointerState（2 值）、AudienceType（2 值）、BusinessRoleState（3 值）、DictionaryDomainType（3 值）、DictionaryItemState（2 值）、GiftClaimState（3 值）、GiftDisplayState（5 值）、GiftEligibility（3 值）、InvoiceAttachmentTaskState（4 值）、InvoiceFactState（5 值）、MainPlanState（4 值）、OpsRefundCaseState（9 值）、PeriodBaseUnit（2 值）、ProductSalesState（3 值）、RefundInitiator（2 值）、RolePlatformScope（2 值）、SeatScope（2 值）、UpgradeSwapState（5 值）。周期语义只认 baseUnit × multiplier（半年 = MONTH×6），中英文标签一律不参与计算。

业务设计

业务设计不另出图：每个业务域"规则是什么"由第 2 章需求图（域编号 D\<n\>\.\<m\> 的叶子需求）钉死，"怎么流转"由 4\.2 流程设计的 24 张活动/协作图承载，实体侧的落点见 5\.1 各域结构图。三处共用同一套六域编号，评审时任一业务决策都能从需求→流程→实体一条线追到底。

部件设计

接口设计

本节对应 M\-Design「04\.4接口设计」包：25 个接口模块（InterfaceBlock）、142 个操作、8 个逻辑服务块，按六域各一张接口设计图（六图合计 43 符号 / 34 连线）。图上两种虚线：Realization＝服务提供该接口（每接口唯一提供者），Dependency＝消费方调用该接口；接口与服务块不带 D 前缀（包名即域口径），跨域引用块（如权益查询接口）按源元素归属出现在相邻域图上。本轮新增 5 个接口组、33 个操作：治理上下文接口、席位降额接口、对账接口、通知模板与投递接口、验收证据与基线接口；另有 13 个操作挂到既有接口组（邀请四件、保全三件、配额预占与结算五件、异常收款返还一件）。新接口组到服务块的 Realization 尚未补画，当前在图上为独立块。

D1 身份与组织

图上内容描述：D1 身份与组织接口设计图：9 个 <<接口模块>> \+ 5 个 <<模块>>，符号 14 / 连线 15（Realization 8、Dependency 7），D1 契约操作合计 62 条。本轮新增 治理上下文接口 共 1 组，尚未画 Realization（提供者归属未定版），图上为无连线块。

  • 看图口径：<<接口模块>> 是契约、<<模块>> 是服务或端；虚线三角箭头 Realization 读"由谁提供"（服务→接口），虚线箭头 Dependency 读"谁用谁"（消费方→接口）。接口块下挂 Operation 子元素，块上不展开签名，下列操作名按模型逐个点名。
  • 认证与账号接口（14）：register / requestOtp / verifyRegistration / login / changePassword / getProfile / recoverCredential / changeLoginIdentifier / requestDeletion / withdrawDeletion / revokeSession / listSessions / queryIdentityState / queryOperationResult，是本图最大的契约。
  • 空间成员与席位接口（15）：claimTeam / switchSpace / transferOwnership / acceptOwnership / inviteMember / removeMember / assignRole / allocateSeat / releaseSeat / reassignSeat / listSeatUsage / acceptInvitation / listInvitations / revokeInvitation / resendInvitation------邀请四操作并入本接口，不另立邀请契约。
  • 授权同步与降级接口（5）：pushAuthzChange / pullAuthzByEpoch / degradeToReadOnly / restoreAuthz / reportAuthzIncident。
  • 协议两接口（4 \+ 4）：协议阅读与同意接口 getActiveAgreements / getAgreementContent / recordConsent / listMyConsents；协议版本运营接口 createAgreementDraft / publishAgreementVersion / listAgreementVersions / retireAgreementVersion。
  • 权限资源与权限组接口（9）：createResource / updateResource / disableResource / listResources / createRoleTemplate / updateRoleTemplate / bindRoleTemplateResources / listRoleTemplates / listRoleTemplateResources。
  • 角色资源授权接口（5）：initTenantRoleResources / grantRoleResources / revokeRoleResources / listRoleResources / listMyEffectiveResources。
  • 接口访问校验接口（3）：checkResourceAccess / listVisiblePages / listVisibleActions。
  • Realization 归属（8 条）：身份与组织服务提供 7 个接口（认证与账号、空间成员与席位、协议阅读与同意、协议版本运营、权限资源与权限组、角色资源授权、接口访问校验），授权运行时服务提供 1 个（授权同步与降级）；本域第 9 个接口（治理上下文接口）尚未画提供方，待服务归属定版后补连线。
  • Dependency 消费（7 条）：网页前端→认证与账号接口、网页前端→协议阅读与同意接口、网页前端→角色资源授权接口、运营管理后台→协议版本运营接口、运营管理后台→权限资源与权限组接口、建模网页端→授权同步与降级接口、授权运行时服务→接口访问校验接口；空间成员与席位接口在本图上仍无任何消费连线。
  • 治理上下文接口（3）：issueGovernanceContext / verifyGovernanceContext / revokeGovernanceContext------签发、逐请求校验、消费或过期撤销三条各一操作，守 D1\.46\~D1\.48。
  • 为何不塞进认证与账号接口：治理凭证的主体是受限账号与治理人员，生命周期与业务会话不同（一次用途、带对象引用、短时效）；塞进 login 会让"凭证隔离"这条判据在契约上消失，验收无从点名。

为什么这么设计：U01 的账号动作要能被审计，就得让每条安全判据都有一条同名操作可点，而不是塞进 login 或 register 的实现里。

  • 归域依据：8 个接口全挂 D1：账号生命周期 14 操作、组织与席位 11 操作、授权同步与降级 5 操作、协议阅读与同意 4 操作、协议版本运营 4 操作、权限资源与权限组 9 操作、角色资源授权 5 操作、接口访问校验 3 操作；授权与鉴权接口留在 D1 是鉴权内嵌 saas\-core 用户域定版的接口侧体现。
  • 关键决策与备选：否掉"一个账号接口包打天下"------协议同意与协议发版分属两接口，因为消费方不同（网页前端与运营管理后台），合成一个会把运营侧写接口暴露给 C 端；否掉"注销=deleteAccount 一把梭"------拆成 requestDeletion 与 withdrawDeletion，撤回期才在契约上存在；否掉"找回时顺带改绑"------recoverCredential 与 changeLoginIdentifier 分开，双侧证明的判据不同；否掉"把鉴权操作塞进认证与账号接口"------资源定义（运营侧）、授权配置（租户侧）、访问校验（服务端切面）三类消费方不同，合并会把运营写接口暴露给 C 端。
  • 承接的硬约束：requestOtp 与 verifyRegistration 分离，落实票据先验后发与一次性消费；revokeSession 与 listSessions 支撑会话与设备可查可撤；改密与找回成功后触发按范围撤销；recordConsent 携带版本标识与内容摘要供服务端比对；degradeToReadOnly 与 pullAuthzByEpoch 守"读不到最新授权就保守降级"；checkResourceAccess 未命中统一按无权访问处理、不区分资源不存在与无权限（D1\.43）；initTenantRoleResources 只在建租户或初始化权限时展开且幂等（D1\.41）。
  • 落地形态：提供方对应 saas\-core 的 identity 模块（含内嵌鉴权过滤器）与授权运行时服务；62 条操作在模型里逐条存在，命名与层 4 表字段一一对应，例如同意事件表对 recordConsent、身份操作尝试表对 changeLoginIdentifier。
  • 验收与留痕：认证与账号接口 14 条、权限三接口 17 条（9 \+ 5 \+ 3）、邀请 4 条与治理上下文 3 条，本域合计 62 条；评审按"每条 MUST 是否有同名操作"核对：注册、发码、验证、登录、找回、改绑、注销、撤回、会话查询与撤销、身份状态、异步结果，以及资源维护、权限组绑定、初始化展开、授权配置、可见清单与访问校验全部有名。
  • 取舍与代价：14 操作的单接口偏大，代价是实现侧还要再分组；被否的备选是拆成"认证接口 \+ 账号接口"，那会让注册与登录共用的票据、凭证语义在两处重复定义。

D2 商品与权益

图上内容描述：D2 商品与权益接口设计图：5 个 <<接口模块>> \+ 5 个 <<模块>>，符号 10 / 连线 8（Realization 4、Dependency 4），D2 契约操作合计 21 条。本轮新增 席位降额接口 共 1 组，尚未画 Realization（提供者归属未定版），图上为无连线块。

  • 看图口径：<<接口模块>> 为契约、「模块」为服务/端/外部块；Realization（虚线三角）＝由谁提供，Dependency（虚线箭头）＝谁用谁；操作签名块上未展开，清单按层 5 契约点名。
  • 接口清单（一）：权益查询接口 4 操作：getEntitlements/checkCapability/getQuotaUsage/getAuthzEpoch；计量上报接口 7 操作：reportUsage/reconcileUsage/reserveQuota/settleQuota/releaseQuota/getQuotaReservation/getCapacityGuard------预占、结算、释放、查预占、查容量保护五条把 D5\.7\~D5\.9 的判据全部有名化。
  • 接口清单（二）：商品版本接口 5 操作：listPlanVersions/configurePlanVersion/publishPlanVersion/retirePlanVersion/setUpgradePath；试用接口 2 操作：checkTrialEligibility/activateTrial。
  • Realization 归属（4 条）：权益与商品服务分别指向权益查询、计量上报、商品版本、试用四个接口------本域提供者唯一，全部集中在一个服务块；本轮新增的席位降额接口尚未画提供方。
  • Dependency 消费（4 条）：网页前端→权益查询（权益额度展示）、运营管理后台→商品版本（配置发布）、建模网页端→计量上报（用量上报）、权益与商品服务→支付渠道适配器（出站调用）。
  • 外部块说明：支付渠道适配器是 <<模块>> 外部依赖块（系统块部件借画本图），服务唯一出站调用记录在提供方同域图上；本图没有接口模块级跨域引用。
  • 逐接口统计：权益查询 1R\+1D、计量上报 1R\+1D、商品版本 1R\+1D、试用 1R\+0D，合计 4R\+4D=8。
  • 席位降额接口（3）：confirmSeatReduction / listSeatReductions / getWriteGate------确认保留名单、查降额单、读当前商业写围栏，守 D2\.6\~D2\.8；确认动作只接受当前所有者，零额度只接受空名单。
  • 逐接口统计：权益查询 1R\+1D、计量上报 1R\+1D、商品版本 1R\+1D、试用 1R\+0D、席位降额 0R\+0D，合计 4R\+4D=8；本域操作合计 21 条。

为什么这么设计：权益只读快照、计量只收数、出站被防腐层收口------域数据主权写进契约。

  • 承接的硬约束：权益查询 4 操作一律读 entitlement 快照，接口里刻意没有「回查订单」类操作------把 SaaS 计费关键不变式（权益生效以快照为准）固化进契约，杜绝实现时偷懒直查交易表。
  • 关键决策与备选：计量上报独立成接口给主体软件（建模网页端）用：平台只收数与对账，用量明细与项目数据不进平台库；「计量与用量独立成域」与「每端各定义一套查询接口」均被否，usage\_snapshot 按蓝图归 D2 从属能力。
  • 归域依据：商品版本 5 操作承载 DEC\-11 版本化发布：发布不审批但必须系统校验（publishPlanVersion）、下架仅停新购（retirePlanVersion）、升级路径显式声明（setUpgradePath）。
  • 落地形态：提供方＝saas\-core module/entitlement（席位降额三操作与配额预占五操作同由该服务承载，写围栏判定留在服务端）；试用双重去重（trial\_consumed\_member 唯一键）藏在 checkTrialEligibility 之后，activateTrial 激活时绑定最新权益版本。
  • 取舍与代价：权益与商品服务→支付渠道适配器这条出站 Dependency 画在权益域图上，代价是接口图混入了外部适配器块；收益是该服务的全部对外出口一图可查，新增渠道只动适配器不动四个接口。

D3 交易与履约

图上内容描述：D3 交易与履约接口设计图：3 个 <<接口模块>> \+ 3 个 <<模块>>，符号 6 / 连线 5（Realization 3、Dependency 2），D3 契约操作合计 13 条。本域接口层本轮无新增接口组。

  • 看图口径：<<接口模块>>＝契约、「模块」＝服务/端；Realization 虚线三角读「由谁提供」，Dependency 虚线箭头读「谁用谁」；操作签名块上未展开，清单按层 5 契约点名。
  • 接口清单（一）：订单与支付接口 5 操作：createOrder/createPaymentAttempt/queryPaymentAttempt/closeOrder/listOrders------下单、每次支付尝试、核实结果、关单、查列表各一枚操作。
  • 接口清单（二）：履约与授予接口 4 操作：fulfillOrder/grantEntitlement/revokeEntitlement/getGrantByIdempotencyKey；续购与升级接口 4 操作：renewSubscription/quoteUpgrade/upgradeSubscription/extraPurchase。
  • Realization 归属（3 条）：交易与履约服务分别指向订单与支付、履约与授予、续购与升级三接口，每接口唯一提供者。
  • Dependency 消费（2 条）：网页前端→订单与支付接口（自助下单入口）；交易与履约服务→权益查询接口（续购、升级报价必须先读当前权益）。
  • 跨域引用块：权益查询接口是 <<接口模块>> 源属 D2 的块，因本域是消费方被借画到 D3 图上；它的 Realization（提供方＝权益与商品服务）仍只画在 D2 图，本图只出现一条消费线。
  • 逐接口统计：订单与支付 1R\+1D、履约与授予 1R\+0D、续购与升级 1R\+0D、权益查询（跨域引用）0R\+1D，合计 3R\+2D=5。

为什么这么设计：三段分离与幂等写进契约；下单与支付各成操作，权益走接口不回查。

  • 承接的硬约束：BR\-003 要求订单、支付、履约分开------createOrder 与 createPaymentAttempt 是两个操作而非「下单即支付」一步；UNKNOWN 是合法稳态，必须 queryPaymentAttempt 核实，不许盲目重复扣款或退款。
  • 关键决策与备选：「合同直连订阅」被否：合同核销后的人工授予同样走 grantEntitlement（grant 表 idempotency\_key UK），接口层不存在合同到订阅的直连通道；「下单履约一步完成」同被否，fulfillOrder 独立成操作。
  • 验收与留痕：getGrantByIdempotencyKey 把幂等键查询做成公开操作，回调重放、人工对账走同一条路，不给「查不到就重发」留空间；成交核对以 grant 的 idempotency\_key UK 与 order\.snapshot\_json 锁定为准------重复通知不重复授予、价格能力不随后续发布漂移。
  • 归域依据：升级换单（upgradeSubscription＝新单全额支付＋旧单按比例退＋权益切换）留在 D3，因交易侧发起；申请与执行退款归 D4 售后接口，续购顺延、不可降配（DEC\-05）。
  • 落地形态：提供方＝saas\-core module/trade（order/payment\_attempt/fulfillment/grant 四表）；升级报价（quoteUpgrade）读 getEntitlements 快照而非交易表。

D4 售后与财务

图上内容描述：D4 售后与财务接口设计图：3 个 <<接口模块>> \+ 2 个 <<模块>>，符号 5 / 连线 3（Realization 2、Dependency 1），D4 契约操作合计 14 条。本轮新增 对账接口 共 1 组，尚未画 Realization（提供者归属未定版），图上为无连线块。

  • 看图口径：三个 <<接口模块>> 加提供方<<模块>>售后服务、消费方<<模块>>运营管理后台；Realization 虚线三角＝由谁提供，Dependency 虚线箭头＝谁用谁；操作清单按层 5 契约点名。
  • 退款接口：6 操作：applyRefund/reviewRefund/calcRefund/executeRefund/listRefunds/refundAbnormalReceipt，前五条是申请→审核→计算→执行→查询，最后一条把异常收款返还单列，不套普通退款费率（D4\.9）。
  • 发票接口：4 操作：applyInvoice/reviewInvoice/uploadInvoiceFile/downloadInvoice，覆盖线上申请、人工审核、回传文件与下载。
  • 连线归属：2 条 Realization：售后服务→退款接口、售后服务→发票接口；1 条 Dependency：运营管理后台→退款接口（人工受理入口）。发票接口与本轮新增的对账接口都无消费连线。
  • 逐接口统计：退款 1R\+1D、发票 1R\+0D、对账 0R\+0D，合计 2R\+1D=3；本图无跨域引用块，本域操作合计 14 条。
  • 对账接口（4）：createReconciliationBatch / listReconciliationBatches / listDiscrepancies / resolveDiscrepancy------建批、查批、列差异、处置差异各一操作，守 D4\.7/D4\.8；建批只接受完整窗口输入，缺页即判不完整待核实。

为什么这么设计：退款五步一步一权限一留痕，把「首期人工受理」落在接口粒度上。

  • 关键决策与备选：退款不做「一键退款」也不做审批流（范围明确不做审批流）：拆五操作对应申请人/受理人/财务审核人各自权限与留痕（refund\_application 的 applicant\_user\_id、accepter\_id、finance\_reviewer\_id 三段字段），首期不自动批准。
  • 承接的硬约束：DEC\-07 退款时间比例公式：calcRefund 独立存在让公式可单独调用复核，审核人先看数再批；P/S/E/C/D\_seconds/R\_seconds/B/r\_snapshot/F 全部输入输出列成字段，复核无需重算。
  • 归域依据：退款与发票分两接口承载两类单据------角色与生命周期不同，合并会把开票混进退款审核；退款失败不回退权益（executeRefund 的失败态保留权益现状）、channel\_refund\_no 回填渠道流水。
  • 落地形态：提供方＝saas\-core module/aftersale；发票不做开票系统对接，四操作就是人工流程的单据流转，invoice\_application 留申请与文件痕迹。
  • 取舍与代价：发票接口未画消费连线是简化：实际入口同样是运营管理后台人工受理，契约先定义完整，图上不再为显而易见的入口补线。

D5 数据生命周期

图上内容描述：D5 数据生命周期接口设计图：1 个 <<接口模块>> \+ 1 个 <<模块>>，符号 2 / 连线 1（Realization 1、Dependency 0），D5 契约操作合计 8 条。本域接口层本轮无新增接口组。

  • 看图口径：一个 <<接口模块>> 加提供方<<模块>>生命周期服务；本图唯一的连线是 Realization（虚线三角，读「由谁提供」），没有任何 Dependency 消费线，也没有跨域引用块。
  • 接口清单：数据生命周期接口 8 操作：getRetentionStatus/requestTakeaway/requestClosure/withdrawClosure/executePurge/putPurgeHold/releasePurgeHold/listPurgeHolds------前四条用户侧动作、executePurge 平台侧受控执行、后三条（挂保全、解保全、查保全）把 D5\.10\~D5\.12 的保全闸门有名化。
  • 连线与统计：生命周期服务→数据生命周期接口，1 Realization \+ 0 Dependency；八操作集中在同一接口模块内定义，本域操作合计 8 条。
  • 读图补充：用户侧动作的消费入口（网页前端）与调度侧（定时任务）都未在本图落块，图面只保留契约与唯一提供方这一组事实。
  • 保全三条：putPurgeHold / releasePurgeHold / listPurgeHolds 不另立接口：保全与清理是同一状态机的两个入口，拆两接口会把「谁能挂保全、谁能解保全」的审计规则分到两处维护。
  • 配额预占为何不在本接口：reserveQuota 等五条挂在 D2 的计量上报接口上------额度上限来自权益包版本，判定与计量同侧；生命周期接口只管到期、取回、保全与销毁，避免两套额度判定。

为什么这么设计：用户动作与受控清理共用一份契约、按权限分开，政策与执行留痕分表。

  • 关键决策与备选：executePurge 不与用户侧四动作分接口而是同接口不同权限：把「谁能调 executePurge」这条审计规则集中写在一处；被否方案是另立「平台侧清理接口」，那会把同一生命周期契约劈成两半、权限规则两处维护。
  • 承接的硬约束：DEC\-06 定住参数口径：到期只读且可取回原始项目数据（requestTakeaway），注销/解散留 30 天撤回窗口（requestClosure/withdrawClosure），清理按 90\+30 执行且受控留痕；参数不取默认值（BR\-006）。
  • 落地形态：写侧＝saas\-core module/lifecycle；executePurge 由 saas\-job\-executor（同镜像、不同 profile）按 XXL\-Job 调度或持权限运营触发，对应 job\_record 定时驱动 lifecycle\_state。
  • 验收与留痕：任何一次数据销毁可回答「依据哪条政策、谁批准、何时执行」------lifecycle\_policy 存参数，purge\_record 记 executed\_at/operator\_id/audit\_ref\_id，closure\_request 的 withdraw\_deadline\_at 钉住撤回期。
  • 取舍与代价：图上零消费线意味着消费方（用户端、调度器）要跨到部署图与 IBD\-SYS 核对；换来的是接口层最干净的一张图，契约演进只动一处。

D7 平台运营治理

图上内容描述：D7 平台运营治理接口设计图：本域接口块 18 个、契约操作合计 116 条。OPS v1\.9 这轮新增 12 个接口块共 92 条操作（后台人员治理、通用字典、可信动作目录、权限模板影响预览、空间生命周期、建模用户账号、商品三段、赠送受众与领取、跨产品主套餐升级、订单查询与原支付核实、订单内退款、协议实例运营）。本轮新增 通知模板与投递接口、验收证据与基线接口 共 2 组，尚未画 Realization（提供者归属未定版），图上为无连线块。

  • 看图口径：本图四个 <<接口模块>> 只有两条连线、且都是 Realization（虚线三角＝由谁提供），没有 Dependency------运营管控接口的提供方就是运营管理后台自己，它同时以 <<模块>> 块出现；与 D2/D4 图上它作为消费方的连线类型不同、语义不同。
  • License 接口：5 操作：issueLicense/importLicense/validateLicense/revokeLicense/reportClockAnomaly，覆盖云端签发、客户侧导入与校验、撤销、时钟与环境异常上报。
  • 租户与运营管控接口：9 操作：listTenants/getTenantDetail/freezeTenant/unfreezeTenant/registerContract/verifyContractPayment/publishAnnouncement/manageClientVersion/queryAuditLog，跨租户管控、合同登记核销、公告与客户端版本、审计只读查询。
  • 连线与统计：2 条 Realization------License 服务→License 接口、运营管理后台→租户与运营管控接口；逐接口统计：License 1R\+0D、租户与运营管控 1R\+0D、通知模板与投递 0R\+0D、验收证据与基线 0R\+0D；本图无跨域引用块，本域操作合计 24 条。
  • 通知模板与投递接口（5）：publishNotificationTemplate / listNotificationTemplates / listMyNotifications / markNotificationRead / markAllNotificationsRead------发布与查询归运营侧模板管理，读取与已读归接收者，两侧共用一套模板版本口径（D7\.17\~D7\.19）。
  • 验收证据与基线接口（5）：recordAcceptanceRun / attachEvidence / listDefects / signPerfBaseline / updateLoadProfile------执行登记与证据挂载分两操作，缺陷只读查询，基线签认与画像维护各一条，判据全部有名（D7\.20\~D7\.25）。
  • 两个新接口尚未画提供方：通知与验收的提供者服务归属（运营平台还是独立通知服务）属未定版口径，模型里只建契约不建 Realization，避免图上先认一个未经确认的服务块。

为什么这么设计：License 一份契约四角色共用、按端裁剪暴露面；运营写操作与授予生效各走一条道。

  • 关键决策与备选：签发、导入、校验、撤销、时钟异常上报定义在同一个接口模块，但部署时按端裁剪可调子集：issueLicense 私钥只在 KMS/签发环境、不入交付包，importLicense/validateLicense 面向客户侧离线实例，reportClockAnomaly 由主体软件上报------否掉「每端各定义一套接口」，契约统一、暴露面分开。
  • 归域依据：registerContract/verifyContractPayment 放运营管控接口而非交易域接口：合同登记与到账核销是运营留痕动作；授予生效仍走 D3 履约与授予的 grantEntitlement 幂等通道，「合同直连订阅」被否。
  • 落地形态：License 服务＝saas\-core module/license；租户与运营管控接口的提供方运营管理后台是独立部署的 saas\-ops\-console（页面\+BFF，业务写操作仍调 core 的 ops API），故图上它在这里是提供方<<模块>>、在 D2/D4 是消费方<<模块>>。
  • 承接的硬约束：freezeTenant/unfreezeTenant 支撑租户级管控，queryAuditLog 只读支撑 D7\.10 关键操作留痕；manageClientVersion/publishAnnouncement 对应版本与公告发布（发布不审批但须校验，DEC\-11 口径）。
  • 验收与留痕：离线有效性核对走 validateLicense＋license\.signature，时钟回拨记 clock\_anomaly\_record，撤销经 revokeLicense 入 license\_revocation 供高版本快照导入时消费。
  • 后台人员治理接口（15）：initializeSuperAdmin、getInitializationOperation、inviteStaff、previewInvitation、verifyInvitationOtp、acceptInvitation、cancelInvitation、resendInvitation、disableStaff、requestStaffRestore、verifyStaffRestore、withdrawStaffRestore、assignStaffDuties、listStaffAccounts、getStaffOperation
  • 通用字典接口（8）：createDictionary、listDictionaries、createDictionaryItem、updateDictionaryItem、disableDictionaryItem、deleteDictionaryItem、listDictionaryReferences、getPeriodSemantics
  • 可信动作目录接口（4）：registerFunctionAction、listFunctionActions、getActionGuards、disableFunctionAction
  • 角色权限模板运营接口（9）：createRoleTemplate、listRoleTemplates、getRoleTemplateDetail、previewTemplateImpact、publishRoleTemplate、switchActiveRoleTemplate、disableRoleTemplate、deleteRoleTemplate、listRoleReferences
  • 运营建模用户管控接口（6）：listOpsUsers、getOpsUserDetail、restrictUserAccount、releaseUserAccount、getUserGovernOperation、listUserRelatedOrders
  • 运营空间管控接口（6）：listOpsSpaces、getOpsSpaceDetail、suspendSpace、resumeSpace、getSpaceLifecycleOperation、listSpaceRoleQuotas
  • 商品目录运营接口（9）：getProductLatestVersion、validateProductDraft、publishProductVersion、retireProduct、relistProduct、listProductVersions、getPublicationPointer、saveAudienceSnapshot、listSeatDefinitions
  • 赠送领取与升级接口（7）：listEligibleGiftOffers、getClaimEligibility、claimGiftOffer、getGiftClaimOperation、quoteMainPlanUpgrade、confirmMainPlanUpgrade、getUpgradeOperation
  • 订单运营查询接口（5）：listOpsOrders、getOpsOrderDetail、listPaymentAttempts、verifyOriginalPaymentResult、getCancelStatus
  • 订单内退款接口（6）：previewOrderRefund、initiateOrderRefund、stopEntitlementSource、submitChannelRefund、getRefundOperation、listRefundAttempts
  • 发票运营接口（7）：listInvoiceApplications、getInvoiceApplicationDetail、recordIssueFact、uploadInvoiceOriginal、repairInvoiceAttachment、getAttachmentTask、downloadInvoiceOriginal
  • 协议实例运营接口（10）：listAgreementInstances、createAgreementInstance、saveAgreementDraft、validateAgreementVersion、publishAgreementVersion、withdrawAgreementVersion、republishLatestAgreementVersion、replaceAgreementVersion、archiveAgreementVersion、getAgreementPublication
  • 现码落地情况 ：其中通用字典 11 条、可信功能动作目录 5 条已在 feat/ops-platform-governance 上实现（详见《接口清单 · D7 平台运营治理》），其余为设计先行。
相关推荐
她的男孩2 天前
租户 A 的验证码，却用了租户 B 的 AccessKey：Forge Admin 修跨租户短信串发
java·spring boot·saas
Newway3217 天前
企业商城系统选型指南：SaaS与私有化如何判断
私有化部署·saas·商城系统·s2b2c·企业商城
VIP_CQCRE10 天前
AI 工具入口不等于独立 SaaS：Studio 分站的配置模型与边界
人工智能·saas·ai工具·技术架构·acedatacloud
zxsz_com_cn11 天前
预测性维护云平台选型：自建还是买SaaS？
saas·工业4.0·预测性维护·云平台选型·自建
D姐聊门店20 天前
门店收银系统断网兜底怎么设计：本地账本、离线续传与日终对账的工程实现
数据库·saas
emmettxu20 天前
用 SDD + OpenSpec + Cursor 开发 SaaS：SoloFlow AI 前三个阶段的实践
saas
做个文艺程序员22 天前
MQ第07篇：Java SaaS多租户消息隔离实战：RabbitMQ VHost+RocketMQ Tag+命名空间架构
spring boot·rabbitmq·rocketmq·saas·多租户
Wonopop22 天前
Figma 席位计费对账建模：从席位审批到发票、卡交易的状态设计
saas·figma·对账系统·mpchat
meiying88381 个月前
模板建站 vs 定制开发：从技术债、TCO 与可维护性算一笔工程账
架构·saas·建站
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02历年考研数学一、数学二、数学三真题试卷及答案PDF03GitHub 镜像站点04几个好用的ip纯净度检测网站05昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战06苹果iPA游戏软件资源下载网站07蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接08如何新建文件夹？ 电脑新建文件夹的4种方法09微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新10Dify：一站式AI应用开发平台全解析与Windows部署指南