#NSIO Next · 商业模型与 Entitlement

状态：商业基线。本文定义商品边界、Entitlement 数据模型和首版强制范围。价格与配额数字放在本文，架构文档只保留能力轴与执行原则。

#0. 本文要解决的问题

首版不建设完整计费平台，但商品边界必须一次设计对：

• 产品能力完整——L3、L4 Service、Grant 和服务发布不做付费阉割；
• 商品结构可扩展——以后增加 Business、Exit Pack、Ephemeral Pack 不改运行时协议；
• 首版计费简单——只对少数几项做可靠强制，其余先计量观察。

判断标准只有一条：调整市场套餐时，NSD、NSGW 和 NS App 的协议与代码不需要跟着改。

本文件定义“卖什么”和运行时怎样获得能力。客户怎样报价、付款、开票、催缴与退款以采购、计费与发票为权威；SLA 的测量、抵扣和事故通报以服务运营规格为权威；认证、数据权利和 Legal Hold 以信任与合规为权威。

#1. 商业权威分离与 Gateway 供给

商业信息不进入运行时。基础套餐与结构化 Managed Edge 商品使用两条平行派生链：

Subscription            套餐当前周期、数量与续订状态
   ↓ 解析（Entitlement Resolver）
Effective Entitlement   运行时能力：features / quotas / limits / service_levels

immutable Order/Contract Events
   ↓ 归并
ProductAllocation       结构化商品当前有效的商业分配
   ↓ provisioning
GatewayAssignment       当前交付给 Organization 的实例/池/区域供给
   ↓ Network Admin 明确启用
CapabilityActivation    Network 业务意图、审批与配额占位
   ↓ 签发
CapabilityLease         NSD 给 NSGW 的短期、具体、可撤销执行授权

**NSD 不认识 resource_pack_10，NSGW 不认识套餐名、订单、价格或 ProductAllocation。**改套餐名、组合包和折扣只动商业层；运行时只消费解析后的 Entitlement、Assignment/Activation revision 和 Lease。

ProductAllocation 不是不可变订单历史。它有稳定 product_allocation_id、单调 allocation_revision 和闭合生命周期 provisioning|active|suspended|terminated；每个 revision 引用造成它的不可变 Order/Contract Event、当前商品/数量/有效期、结构化供给 scope 和 commercial terms reference。续订、扩缩容、退款和终止提升 revision，不覆盖旧事件或旧 revision。suspended 默认停止新增/扩大但保留合同尚承诺的容量；只有 terminated 在生效日到达且依赖 Assignment/Lease 完成收敛后释放 Reservation。

一个 Allocation 可以派生多个 Assignment，例如一个多区域商品；需要组合的商品使用显式依赖：Fixed Region/Residency 与 Relay SLA 引用它约束的供给 Allocation，Reserved Throughput 必须引用一个 Dedicated Relay Pool Allocation。依赖失效不能被 provisioner 猜测为其他共享池或区域。

对托管 Gateway 商品，商业与安全对象按以下顺序闭环：

Effective Entitlement + active ProductAllocation revision
  → 容量/地域 admission（需要时创建 RelayCapacityReservation）
  → Gateway provisioning 创建 commercial/dedicated Assignment（供给已交付）
  → Network Admin 创建 CapabilityActivation（客户明确启用、占配额）
  → Capability Lease（此刻由哪个 Instance 执行）

GatewayAssignment 不保存价格，不替代 Entitlement 或 Allocation；每个 commercial/dedicated Assignment 必须保存 (product_allocation_id, allocation_revision) provenance。CapabilityActivation 不表示已付款，也不替代 AccessGrant。Order webhook 重放必须按 (order_id, product_allocation_id, allocation_revision, assignment_scope) 幂等返回同一 Assignment 集合。共享池 failover 只改变 Lease；不得重复创建 Allocation、Assignment、Activation、Capacity Reservation 或计费占位。

Basic Relay 使用同一对象链但由系统 provisioning：Organization 自动获得 system_default Assignment，Network 自动获得基础 relay Activation/Lease，不要求购买且不消耗付费 Managed Edge quota。客户自建使用 customer_owned Assignment；平台对其 host 无管理权，商品只可覆盖控制面、支持或流量服务，不把实例所有权改成 platform-owned。

#1.1 溯源字段

三层分离的代价是排查"这个组织为什么有 35 个受管资源"需要跨系统查询。Effective Entitlement 携带一个非权威的溯源引用来消除这个代价：

"derived_from": { "subscription_id": "sub_01J...", "revision": 14 }

运行时组件不得对它做任何判断，它只用于支持工单和审计关联。

#2. Effective Entitlement 数据模型

#2.1 四个桶

新增键落哪个桶，按上表两列判定，不靠直觉。典型误判：审计保留期看起来像配额，但它不阻断任何操作、也不按量计费，属于 service_levels。

#2.2 结构

{
  "schema_version": 1,
  "entitlement_id": "ent_01J...",
  "entitlement_revision": 42,
  "subject": { "type": "organization", "org_id": "org_01J..." },
  "deployment_id": "dep_01J...",

  "features": ["l3_mesh", "l4_services", "sso", "scim"],

  "quotas": {
    "human_seats":        { "limit": 10,   "enforcement": "block" },
    "networks":           { "limit": 1,    "enforcement": "block" },
    "managed_resources":  { "limit": 35,   "enforcement": "block" },
    "edge_regions":       { "limit": 0,    "enforcement": "block" },
    "ephemeral_minutes":  { "limit": 5000, "enforcement": "meter" },
    "edge_traffic_bytes": { "limit": null, "enforcement": "meter" }
  },

  "limits": {
    "user_devices_per_seat": 20,
    "services_per_network": 500
  },

  "service_levels": {
    "audit_retention_days": 30
  },

  "derived_from": { "subscription_id": "sub_01J...", "revision": 14 },

  "issued_at": "2026-08-08T00:00:00Z",
  "expires_at": "2026-09-08T00:00:00Z",
  "grace_until": "2026-09-15T00:00:00Z",
  "key_id": "ent-2026-08",
  "signature": "..."
}

quotas 中的数字是已解析的有效总量（Team 25 + Resource Pack 10 = 35）。NSD 只读总量，不做加法，不知道加法的来源。

entitlement_revision 是 (subject, deployment_id) 作用域内由签发方分配的单调递增版本，是防回滚的权威字段。derived_from.revision 仍然只是订单溯源信息，不得用于版本判断。

Community Relay 不使用 community_relay_mbps 之类的单标量 service level。它由 §4.4 的版本化 budget policy 和短期 RelayBudgetLease 同时约束 volume、sustained、burst/bucket、concurrency、本地窗口与 stale fallback；所有具体数字在测量完成前保持未发布。

#2.3 Enforcement 三态

首版即完整实现三态，然后通过签发不同的 Effective Entitlement 来切换。临时节点从观察切到告警再切到强制，是换一份声明，不是发一个版本；也可以先在单个组织上试 warn。

#3. 缺失与未知的处理

这一节决定"签发疏漏会不会锁死客户"，是整个模型最容易出事的地方。

#3.1 缺失 quota

每个 schema_version 必须声明其 required quota 集合。启用某个 feature 时还必须校验它依赖的 quota 存在——例如 managed_edge 必须同时存在 edge_regions，否则 bundle 无效。

不采用"缺失一律取 0"：那样一次签发疏漏就能锁死整个组织，风险不对称。

#3.2 未知字段

未知 enforcement 不降级为 block，因为那会让尚未实现该语义的 Next NSD 突然锁住客户——这与"读不懂 ≠ 拒绝服务"的全局原则冲突。正确路径是拒绝该 bundle、退回最后有效版本、进入 grace 并明确报 unsupported_entitlement_enforcement。

required quota 集合只由 schema major 定义，签发方不能在 bundle 内把新键标成 required。需要新的强制语义时必须提升 schema major；同 major 新增字段只能是 optional。

#3.3 最后有效声明必须可持久化

"使用最后有效版本"只有在它能跨进程重启存活时才成立。要求：

• 最后一次验签通过的 Effective Entitlement 连同其签名一起持久化；
• 同时持久化每个 (subject, deployment_id) 已接受的最高 entitlement_revision 和声明摘要；
• NSD 重启后从持久化副本恢复，而不是回到"无声明"状态；
• 恢复的副本仍受 grace_until 约束，且在管理端显示为"陈旧，最后验证于 T"；
• 若持久化副本本身验签失败（被篡改），按无声明处理并告警，但仍不得拒绝启动。

否则在签发服务故障期间重启一次 NSD，就会掉进本节想避免的那个坑。

#3.4 防回滚与恢复

Entitlement 沿用控制面配置已有的版本回滚拒绝纪律：

• 新声明的 entitlement_revision 低于本地最高已接受版本时，即使签名和有效期都合法也必须拒绝，并报 entitlement_revision_rollback；
• revision 相同但签名覆盖的规范化载荷摘要不同，视为签发冲突或重放攻击，拒绝并报 entitlement_revision_conflict；摘要不得基于会受 JSON 字段顺序或空白影响的原始传输字节；
• 验签成功但因回滚被拒绝的声明不能覆盖最后有效声明、最高版本或 grace 计时依据；
• Capability Lease 必须绑定 entitlement_id 与 entitlement_revision，避免旧 Entitlement 派生的新租约继续扩散；
• 备份恢复、灾难恢复或签发系统重建需要降低 revision 时，必须使用由签发权威签名的独立 recovery/reset 声明，指定组织、部署、目标 revision、原因、批准人和一次性 nonce，并写入审计；不能通过删除本地高水位绕过。

本地高水位能防止单独替换 entitlement 文件，不能独自证明整个 NSD 数据库没有一起回滚。托管云必须把最新接受 revision 的检查点写入独立的 Entitlement Service/审计存储，NSD 恢复后在签发新 Capability Lease 前完成比对。完全离线的企业自建若没有 TPM、外部时间戳或远端签名回执，就无法从密码学上检测整库快照回滚；产品必须把它列为部署边界，不能宣称绝对防回滚。

#3.5 每个组织都有 Effective Entitlement

社区自建不需要联网验签，这既是产品承诺也是可用性要求。

#4. 首发商品

首版不做 Business 档——Team 与 Enterprise 之间的细分等真实客户分布出来再切，切的时候只改 Subscription 层。

#4.1 配额

* 受 limits.user_devices_per_seat 反滥用上限约束，超出触发提示而非账单。

Free 的 managed_resources: 10 只计算服务器、工作负载和显式启用 Route/Connector/Exit/Relay 等基础设施角色的 Membership；普通用户设备、用户所有的 Service Host 和 Service 本身不占该额度。定价页必须同时展示“用户设备与 Service 不计费”，不能把该数字写成含义模糊的“10 台设备”。Free 可以用于小团队商业生产，但不包含合同 SLA、正式支持或企业采购承诺；转化依赖可执行的席位/Network/受管资源和治理边界，不依赖不可执行的“禁止商业使用”条款。

首发所有公开套餐都只创建并展示一个默认 Network，不提供第二个 Network 的自助创建、删除或跨 Network 互通。networks quota 字段仍随 v1 Effective Entitlement 交付并保持可验证；额外隔离 Network 是 P1 Enterprise preview，由平台运营按合同开通以验证真实需求。该预览只增加彼此隔离的作用域，不引入跨 Network ACL、Service 共享或路由桥接。未来把 Team 从 1 放宽到更多 Network 只修改 Product Catalog 与 Entitlement，不修改对象模型。

Posture、Flow Logs、JIT、SIEM streaming 等尚未进入当前发布范围的能力不出现在公开套餐比较表，也不形成前向合同承诺。能力实际交付时再通过 Product Catalog 和 Effective Entitlement 决定档位；保留 feature key 不等于已售能力。

#4.2 计费单位

Human Seat Slot 的释放条件必须确定：User 从 Organization 删除、停用或由 IdP/SCIM deprovision 时释放；仅删除最后一台设备、退出登录或短期离线不释放。因此账单表示组织当前需要的可复用席位容量，不是本周期曾出现过的不同用户总数。

Quota 准入看事务提交时的当前占用数；订阅按购买的槽位容量计费，启用自动扩容时以事件精确计算本周期最高同时占用槽位数。已释放槽位可由另一个 User 或 Membership 在同一周期复用，不能把周期内出现过的不同身份简单累加，也不能用小时采样近似峰值。

Managed Resource Slot 的分类变化必须走同一个资源分类变化事务。下列动作都可能占用或释放槽位，任何 API、同步器或后台任务都不得绕开：

• 创建 owner_type ∈ {service, tagged, organization, workload} 的 Membership；
• 修改现有 Membership 的 owner type；
• 审批、撤销 subnet_router / app_connector / exit_provider / relay_candidate 等基础设施能力；
• 临时 Membership 超过策略阈值转为长期资源；
• 删除 Membership、撤销长期身份或将其重新分类为不计费用户设备。

事务必须在同一数据库提交中完成：锁定当前分类与槽位占用 → 计算变化后总量 → 执行 quota enforcement → 写入权威资源状态 → 写入 outbox 计量事件。审批事件只是其中一种触发，不是唯一入口。用户设备免费仅限未被分类为受管资源的 endpoint + service_host。

CapabilityPolicy 只决定节点是否有资格申请能力，不能直接改变 Managed Resource Slot。每个具体能力必须经过统一 CapabilityActivation 事务；策略自动批准也只是该事务的 auto 分支，仍执行 quota allocation、metering、audit 和短租约签发。

CapabilityActivation 的商业语义与健康状态分离：

暂停必须记录结构化 reason（operator_paused、maintenance、commercial_grace、security_hold）并在管理端明确显示“仍占用额度”。系统不按固定 N 天自动撤销；管理员或策略可在暂停时显式设置 auto_revoke_at，执行前通知、计算影响并审计。策略失去资格不能伪装成 suspended，应走影响预览后的 revoke/管理员确认流程。

#4.3 永不计费

• P2P 直连流量
• 用户个人设备数量
• ACL / Grant 规则数量
• DNS 查询次数
• Service 数量、调用次数、并发连接数
• Node ↔ Service 端到端流量
• 安全撤销、数据导出、资源删除

可设反滥用上限，但上限触发限速和提示，不触发账单。

#4.4 Community Relay 服务等级与成本边界

Community Relay 是困难网络下只转发端到端密文的连接兜底，不是无限吞吐产品。路径选择必须优先 direct → customer-owned Relay → Community Relay → purchased Managed Relay；Community Relay 用量不产生超额账单，购买 Managed Relay 获得的是区域、容量、固定资源、数据地域和 SLA，而不是基础连接资格。

“公平使用”必须解析为一份可执行的 Relay budget policy，不能是自由文本。首版冻结以下命名参数，具体数值统一为 pending_measurement，只能由服务运营 §10.2的可复现实验回填：

每个 Free budget owner 使用持久化、错峰的固定额度周期；周期锚点不得因进程重启、Entitlement 重签、opaque subject 轮换、重新登录或创建另一个归属同一 owner 的 Free Organization 而重置。Team 可在升级后于明确日期对齐正式账单周期，但必须保存已消费量和迁移审计。控制台展示当前档位、周期起止、已用/剩余高速字节、当前速率、预计恢复时间和稳定 reason code。

Relay 使用轮换的 opaque relay_budget_subject_id 聚合预算，不获得 Organization、Membership、Node、WireGuard key 或 Service 目录。subject 的轮换频率与额度周期独立；轮换必须由 Allocator 把同一周期的已用量/剩余量结转，不得产生新额度。首版免费关联只使用“同一 User 直接拥有的多个 Free Organization 共享一个 abuse/billing budget”这一枚举信号；不得擅自引入邮箱域名、注册 IP、设备指纹或支付指纹。更强关联必须先更新信任与合规并完成隐私审查。

实时执行使用分钟级签名 RelayBudgetLease 给 NSGW 分配有界本地份额。Allocator 只在签发/续租时参与，不进入每包或每流路径；budget lease 过期或中央计量陈旧时，NSGW 保留认证连接并回落 fallback profile，不能恢复无限高速。明确滥用、DDoS、安全撤销和平台过载仍可拒绝/终止会话，但必须与商业超额分开记录，不能把商业降速伪装成离线或 unauthorized。

#4.5 Managed Edge 商品目录

Community Relay 在全部套餐中提供相同的加密、安全、可建连和 fail-closed 语义；各套餐的公平使用数值可以由成本证据分别确定，但付费档不能绕过任何安全检查。Managed Edge 收费的是稀缺供给和运营承诺，不是“能否建立连接”。首发商品边界冻结为：

Effective Entitlement v1 的四个桶只承载“是否有资格”和标量上限，不能承载 region list、pool reference、residency policy 或 SLA profile reference。上述结构化明细必须进入 ProductAllocation，再派生 Assignment；不能为了省一个对象把 JSON 塞进字符串 feature、把 region 编码进 quota key，或让 NSGW 解析 SKU。

Fixed Region 是硬调度与故障转移约束，不是“优先选择”标签。域内没有健康容量时返回明确不可用并进入所购服务的 SLI/SLA，不能越区恢复。它的价格必须覆盖受限供应商选择、域内冗余、无法借用域外空闲容量和独立演练成本。

Reserved Throughput 不允许统计超售。它只从满足 isolation 的 Dedicated Relay Pool 容量库存成交；该池不能同时承载 Community Relay，因此免费增长不会侵蚀已承诺预留。区域价格基于故障域损失、运维/安全余量和经批准的 capacity evidence，不使用全平台统一冗余系数。协议与对象模型保持套餐中立：Enterprise-only 是首发 Product Catalog/销售策略，未来放开给 Team 不需要修改 wire protocol。

#5. 首版强制范围

#5.1 强制点

每项限制只在一个地方强制：

UI 永远不是强制点。ProductAllocation admission 不能由前端选项代替；NSGW 不相信客户端自报的任何商业状态，只接受 NSD 基于有效 Entitlement、Assignment/Activation 和必要 committed Capacity Reservation 签发的短期 lease。

#5.2 只计量项的管理端展示

本月临时节点：8,420 分钟
本月托管边缘流量：186 GB

超内部阈值先提示、联系客户或人工调整。**不自动扣款，不突然断网。**真实数据足够后再决定是否推出分钟包和流量包——届时只需签发 enforcement: warn 或 block 的新声明。

#6. 商业状态与数据生命周期

#6.1 三类事件不可压成一个布尔

三条不可动摇：

• **社区自建 Community L3/L4 不受平台商业状态影响。**托管云则在 grace 后收敛到当前有效免费 entitlement 和配额，不承诺无限期提供未付费托管控制面。
• 托管云降级前必须给出影响预览和资源选择；已有收费 Capability Lease 自然到期，不把欠费伪装成安全撤销，也不立即拆除基础连接。
• **超配额冻结由客户选择，系统不自动挑。**系统自动挑一定会挑掉生产节点。

#6.2 审计保留期降档

保留期不是"永不删除"——否则购买一个月 Team 就永久获得 30 天历史，不可执行。正确闭环：

1. 降档前显示将受影响的日期范围；
2. 提供明确导出窗口（建议 30 天）；
3. 导出窗口内保留原有数据；
4. 窗口结束后按新的保留期清理；
5. Legal Hold、调查冻结或法规要求优先于套餐策略；
6. 不因降档立即静默删除。

配套两条机制要求：

• 清理动作本身写审计记录（谁降的档、清理了哪个日期范围、何时执行），且该记录的保留期独立于被清理数据，否则会出现"审计日志少了五个月且无人知道原因"；
• Legal Hold 是一个可置位标志，由 Security Admin 设置，阻断保留期驱动的删除，其置位与解除本身也进审计。

#7. 私有部署禁止 Kill Switch

Entitlement 异常在私有部署中的行为是硬性禁令：

• 不得拒绝私有 NSD 启动；
• 不得切断已建立的数据面；
• 使用最后有效声明并持续告警；
• grace 之后只阻止新增收费托管能力；
• Community L3/L4、自建 Relay 和已有 Grant 不受商业授权影响。

理由不是道德而是运营：网络产品里的 license kill switch，第一次误触发就是客户整组织断网加事故报告；而且对客户掌控的二进制根本不可执行。私有部署收入来自合法授权、升级、支持、合规包和 SLA，不来自远程断网能力。

Enterprise 私有部署默认按“年度平台费 + Human Seat 合同阶梯 + 支持/SLA 等级 + 可选 Managed Edge”报价，不按客户内部 Node 数逐个计费。离线 license bundle 必须可验签并记录合同主体、授权范围、期限和版本，支持导出席位/资源/能力使用报告；到期记录并持续显示不合规，但不能阻止启动、切断已有网络或削弱 Community L3/L4 与安全撤销。禁止 Kill Switch 不等于放弃记录事实，合同续期、升级权和支持资格仍以可审计授权为准。

#8. 客户端边界

**NS App 不读取套餐名。**它只读取两件事：

1. 某项功能当前是否可用；
2. 某次操作的返回结果。

不允许出现 if (plan == "team")。App 的发版周期最长，套餐逻辑一旦写进去，改套餐就要等全部用户升级客户端。

Billing 与管理后台可以显示套餐名和订单——它们属于 Subscription 层。

#9. 全新商业边界

NSIO Next 不承接旧 NSIO 的订阅、资源用量、价格、账单、License 或 Entitlement：

1. 新 Organization 在 Next 中选择 Free、试用或付费商品后，签发第一份原生 Effective Entitlement；
2. 不根据旧 NSC/NSN 数量自动创建 Human Seat、Managed Resource 或历史用量；
3. 不提供 Legacy entitlement、旧价格保护或跨产品自动续费；如商务上需要优惠，应创建 Next 自己的折扣、合同和到期规则；
4. Next 的账单只引用 Next 原生资源 ID、槽位事件、Capability Lease 和边缘计量证据；
5. 旧 NSIO 与 Next 是两条独立产品线，客户可以分别订阅和运行，但不能把一边的商业声明作为另一边的运行授权。

#10. 实施顺序

首版交付的不是计费平台，而是一个边界正确的 Entitlement Resolver。

#10.1 计量流水要求

usage_outbox(event_id, aggregate_type, aggregate_id, aggregate_revision, event_type, payload, committed_at, published_at)
seat_slot_events(event_id, ledger_sequence, org_id, user_id, action, reason, occurred_at)
resource_slot_events(event_id, ledger_sequence, org_id, membership_id, from_class, to_class, occurred_at)
ephemeral_lease_intervals(org_id, membership_id, lease_id, valid_from, valid_until)
edge_counter_checkpoints(org_id, edge_unit_id, direction, counter, observed_at)
relay_budget_periods(budget_owner_id, period_id, starts_at, ends_at, high_speed_limit, consumed, revision)
relay_budget_subjects(subject_id, budget_owner_id, rotation_epoch, valid_from, valid_until, state)
relay_budget_leases(lease_id, subject_id, gateway_instance_id, allocation, valid_from, valid_until, generation)
relay_counter_checkpoints(subject_id, gateway_instance_id, period_id, counter, observed_at)
entitlement_snapshots(org_id, deployment_id, entitlement_id, entitlement_revision, digest, verified_at, stale)
usage_reconciliation_findings(finding_id, org_id, kind, expected_set, observed_set, detected_at, status)

• 事务 outbox：席位或资源权威状态变化与对应 outbox 事件必须在同一数据库事务提交，不能先改状态后“尽力发事件”；
• 幂等可重放：每条事件带稳定唯一键，消费者重复处理不得重复占用、释放或计费；
• 确定性顺序：账本使用按 Organization 单调递增的 ledger_sequence 处理同一时刻的释放与占用，不能依赖不同主机的墙上时钟决定周期峰值；
• 周期对账：按事件推导出的活跃槽位集合必须与权威 User/Membership 状态定期比对。差异写入 usage_reconciliation_findings 并告警，不能静默改写已出账单；
• 释放口径固定：席位只在删除、停用或 deprovision 时释放；受管资源只在分类事务确认不再受管或资源删除时释放；
• 临时节点按租约计时：以签发的有效租约区间为证据，不能依赖可能缺失的进程启动/删除时间戳；
• 保留期：原始流水 90 天，汇总 3 年；
• 账单可解释：任一周期的槽位数量必须能列出对应 User/Membership 和 occupy/release 证据；Edge 流量取单调计数器差值并处理重置。

#10.2 契约测试纪律

Entitlement 跨 NSD、NSGW、管理后台三方，是典型的 schema 漂移高风险面。要求：

• schema 与 fixture 提交到 ns-shared-next，三方共用同一份定义，不各写一份再对齐；
• 契约测试必须把真实序列化的结构对 schema 校验，不能只校验 fixture 之间自洽；
• 每个套餐一份 fixture，外加"Subscription → Effective Entitlement"的 golden test；
• 覆盖必需 quota 缺失、未知 enforcement、schema 版本过高、签名失效、持久化副本恢复、合法签名旧 revision 重放、同 revision 不同摘要七种异常路径；
• 覆盖席位释放、受管资源每一种分类变化、outbox 重放、遗漏事件后的对账发现，以及临时租约跨边界计时。

#10.3 套餐与 Community Relay 发布门

内部 Product Catalog 可以先冻结 Free/Team/Enterprise 的商品结构与 Team $8 月付、年付折合 $6 的价格基准；官网公开价格、Community Relay 具体服务数字和销售吞吐承诺必须等待以下证据：

1. Direct、customer-owned Relay、Community Relay 和 WSS/TLS fallback 完成真实互操作与故障切换；
2. Community Relay 有 fair queue、本地 token bucket、并发/过载保护、短期 RelayBudgetLease 和计量陈旧 fallback；
3. 超大云、中型云/CDN、裸金属/包端口至少两类供给完成实例、固定 IP、出网和跨区单位成本测量；
4. 按家用 NAT、CGNAT、双端 symmetric NAT、企业防火墙、移动网络和 IPv4/IPv6 分层取得直连率与 Relay 用量分布；
5. Team 保守场景达到批准的毛利目标，Free budget owner 的最坏月成本存在明确上界；
6. 控制台能解释周期、用量、档位、降速、恢复时间和升级/自建 Relay 路径；
7. 所有 pending_measurement 常量由版本化证据回填并通过生产同构反向测试，不能由实现者或销售临时填写。

#11. 核心原则

1. L3、L4、ACL、Service 发布是产品基础能力，不做付费阉割；
2. 收费重点是团队协作、受管资源、托管边缘、企业治理和 SLA；
3. Entitlement 与 Grant 分开：购买能力不等于获得访问权限；
4. 商品组合由服务端配置，套餐逻辑不进入 NS App 与网络协议；
5. 商业状态异常不得压成"没有权限"，也不得切断已建立的安全连接；
6. 首版计费简单，但数据模型足以支撑后续增加 Business、Exit Pack、Ephemeral Pack 等商品而不改运行时协议。