Core 实施计划

目标与范围

负责客户身份、Key、销售模型、价格、人民币充值与积分账务、调用任务及同仓 Worker。Core 是客户事实的唯一写入方；供应渠道和供应凭据留网关，产品项目内容留各产品仓。

需求输入与确认

依据共享内核、全局身份、钱包规则和客户定价确认领域边界。需求逐项对应 Core 的 auth/users/keys/catalog/billing/usage/admin API 目录。

首期企业使用专属账户与协议价，暂不做企业多人协作；零售、FDE 和 uumi 模型对接业务按定价页分别处理。全局登录是已确认要求，域名和交接细节作为设计输入。

设计与原型

先画出账户—会话—Key、模型—计费规格—价格版本、订单—积分流水—预留—结算三组关系；定义字段归属、单位、唯一约束及迁移顺序。

服务原型使用请求示例与状态时序：登录/刷新/撤销、并发预留、支付回调、执行结果未知、结算响应丢失、Worker 重启恢复。执行状态与账务状态分开，取消或超时不直接等于退款。

API 与文档交付

优先迁入 new-api 的 user/token/auth_session、额度与 billing_session 等实现，保留可兼容的方法、路径和响应；拆分差异记录在源码复用规则。

• 客户接口：身份、用户、Key、目录、账务、用量。
• 运营接口：Admin，后台授权必须服务端执行。
• 协作接口：内部契约和 OceanWay 扩展。授权、预留、结算、结果查询使用稳定操作标识，不能让 Edge 直接读写 Core 库。

每批同步 Contracts 精确 Schema、失败样例、迁移与恢复说明。全量源接口清单不等于运行支持清单。

实施步骤与交付物

九个阶段细化为 46 项任务，按子页阅读，不在总页追加各领域细节。每项写明前置、代码/数据范围、接口文档交付和具体验收；已有代码的验证依据单列在开工基线。

接口覆盖与实施顺序将 218 项上游 Core 参考和 18 项提案逐项归到任务，区分主线、条件启用与需评审项；不是一次性全部开发或全量接口已冻结。

依赖与接入顺序

基础回归复用 CORE-01/02 已有成果；下一执行包为 CORE-03.01 的全局登录协议设计。CORE-03 与 CORE-04 可按开发排期交错推进。CORE-05 依赖价格和单位语义，CORE-06 与 Edge 联调；CORE-07 按其所需事实就绪接入；CORE-08 接媒体网关协议。

Contracts 随具体接口交付；Console/Admin 原型提供输入，不阻塞已有清晰接口的迁入。对应总体 CE-01/02/04/05，跨仓验收见文本调用及媒体任务。

验收标准

• 用户、会话、Key 和运营权限隔离；客户端不能指定权威账户或低价组越权。
• 余额不足不执行；预留和结算在并发下保持账务一致；金额与积分精度明确。
• 重复支付、重复结算、审计失败和进程重启均有可核对结果；日志不暴露完整凭据。
• Console 显示的本人价格与实际消费依据一致；Admin 操作有身份、理由、对象和结果。
• 全局登录、模型调用、账务、媒体和容量各自验收，不由 Key 管理测试替代。

待定项与后续范围

积分比例、支付提供方、充值套餐数值、FDE 服务与额度规则、旧客户权益期限待确认。OAuth/2FA/Passkey 按启用范围安排；组织协作和全量 Agent/MCP 抽象不作为首个文本闭环的前置。

本文定义计划，不累积执行日志。实际版本、完成状态和验证证据见项目进度；任务状态登记到本机工作台，并关联本文步骤。