前案：Core 与 Edge 分仓
恢复 Core、API Edge、Contracts 职责，采用 new-api 同源技术栈
历史方案：本页为恢复第一版多仓文档前的快照，不是现行任务或已实现能力。现行入口为平台架构。
现行完整方案见 OceanWay 最终方案 v1.1，统一规定源码提取、服务边界、数据归属、部署与实施顺序。此前未收敛的技术建议以该方案为准；商业数值仍按实际决定填写。
已被替代：以下是先前独立 Core/Edge 的方案记录。用户随后要求降低复杂度，现行方案为直接二开一套客户后台，见最终方案 v1.1。本文保留源码技术栈证据；独立服务与 15 仓建议不作为首期任务。
2026-09-12 用户最新方向：回到多仓库设计，Core、API Edge 等参考 new-api 的成熟代码实现，技术栈与 new-api 对齐。独立网关继续跟随上游；恢复的是职责分仓，不自动恢复旧 TypeScript 实现、历史协议限制或旧验收结论。
本页是新方向下的职责与实现建议；尚未创建新 Go 工程、改造原仓或执行生产迁移。最终方案已选择 HTTP/JSON + OpenAPI 与 PostgreSQL；具体契约与迁移脚本待实现。
保留的产品和商业决定
- 全部客户最终进入 OceanWay；sub2api 在迁移后退役。
- 零售与企业可使用完整已接入模型目录，账户绑定各自价格方案。
- 人民币充值、系统内积分；企业首期专属账户与协议价，不做多人协作。
- Developer 为公开模型、文档和教程；Console 为客户管理；Admin 服务三人内部团队。用户独自负责开发，维护由团队分工。
- shadcn 原型沿用 OceanWay 风格；Key 掩码旁直接复制；Playground 复用 uumi 或取消仍待选。
- Drama、Studio、Commerce 原型已经由用户安排，独立推进；本轮不覆盖其代码或重新派发。
- 独立 new-api 网关无终端客户，只接受内部受控调用并管理模型供应。
仓库职责
| 仓库／模块 | 核心责任 | 实现方式 |
|---|---|---|
| oceanway-core | 客户身份、Key 生命周期、客户价格、积分／订单、持久调用与任务关联、业务授权 | Go/Gin/GORM；按能力参考或提取 new-api，并补 OceanWay 业务规则 |
| oceanway-api-edge | 客户模型 API 接入、请求校验、授权执行、流式转发、用量交接 | Go/Gin；借鉴 new-api 路由／中间件与流式处理，不复制客户钱包 |
| oceanway-contracts | 跨服务 HTTP/事件规范、DTO、兼容规则和生成客户端 | 版本化规范、Go 模型／客户端与前端 TypeScript 客户端；不是第二个业务服务 |
| new-api 网关仓（当前 text-gateway 相关目录） | 供应商、渠道、协议适配、路由、供应任务、供应重试 | 尽量保持官方实现；名称是否调整后续明确 |
| oceanway-media-gateway | 媒体供应的专项适配与执行 | 独立保留；目标技术栈统一，现有实现的迁移另排，不能默认已经完成 |
| Console / Admin / Developer / Site | 各自产品入口与 UI | 同源 React/TypeScript 工具链，OceanWay 样式与业务组件 |
| Studio / Drama / Commerce | 自身创作业务、页面及业务对象 | 独立仓库与原型交接；新实现对齐统一栈 |
| Docs / Design / Infrastructure | 规范、设计资源、部署与运行治理 | 保留明确维护源；现有工具迁移另定，不因本页直接替换 |
Core 内仍按模块组织，不因分仓再拆身份、价格、积分为多个必须独立部署的微服务。最终方案将通用任务 Worker 放 Core 仓库，以独立进程运行；产品工作流语义留在产品仓库。
原“14 仓”曾以 Developer 归档为前提；现在 Developer 是有效产品。因此恢复多仓不能机械恢复那个数量和旧清单，最终方案列出 15 个逻辑仓库职责；实际远端与目录映射在 N0 核对。
技术栈基线
本轮实际读取固定提交 385d2dfd10d821b25c8a6766bd16eea248cb1652 的 go.mod、web/package.json 与 web/components.json：
| 部分 | 固定源码所用技术 | OceanWay 采用边界 |
|---|---|---|
| 后端 | Go（该提交声明 1.25.1）、Gin | 新 Core、Edge 等对齐，不再沿用旧 TypeScript 服务实现 |
| 数据访问 | GORM，支持 PostgreSQL/MySQL/SQLite 等驱动 | 最终方案选择 PostgreSQL；同栈不等于每个仓库都实现所有驱动 |
| 缓存 | Redis / go-redis | 鉴权缓存、额度与协调按具体一致性要求设计 |
| 金额计算 | decimal 与内部 quota 等既有实现 | 定义人民币分、对客积分和最小额度映射及舍入 |
| 前端 | React 19、TypeScript、Rsbuild | 新产品采用同源构建方式；已安排原型仅做交接对齐 |
| 路由／查询／表格 | TanStack Router / Query / Table | 统一产品工程约定 |
| UI | Tailwind CSS 4、shadcn base-nova / Base UI | 保留 OceanWay 品牌、字体、配色和布局风格；不照搬默认主题 |
对齐技术选型不意味着必须引入 new-api 的所有供应 SDK，或让 Core/Edge 与网关每次升级完全相同补丁版本。客户端平台各仓保持经过验证的依赖基线；网关可以单独升级其供应适配。
建议的数据与执行边界
- Core 是客户账户、Key、价格、积分、订单和客户结算的唯一写入方。
- Edge 不直接修改 Core 数据库，也不持有第二份可独立扣款余额。授权缓存须有有效期和撤销策略。
- 网关只有内部服务身份与供应记录，不登记每个终端客户。
- 产品拥有画布、剧本、商品、批次与正式选择等业务状态，不跨库更改 Core 余额。
- Contracts 不包含一个被所有服务共同执行的账务实现，避免升级形成隐式业务耦合。
推荐同步流式链路：
客户 → API Edge → new-api 网关 → 供应商
↕
Core：授权依据、价格快照、积分预扣、持久调用、最终结算Core 处理准入和结算；不要求每个流式分片再次经过 Core。Edge 从可信 Core 能力取得授权和计费依据，用内部凭据调用网关，逐块转发，并交接最终用量和调用状态。
异步任务建议由 Core 保存持久操作与任务关联，Worker 负责提交／查询网关，产品读自己的任务状态。使用何种领取机制与恢复记录需单独设计，不把一次 HTTP 返回成功当作任务和结算都已完成。
哪些实现值得复用
| 能力 | 参考入口 | 拆分时必须补的部分 |
|---|---|---|
| 身份与 Key | controller/user、token、auth_session 与鉴权中间件 | 用户 Session、客户 Key、内部服务身份分开；跨服务撤销与缓存失效 |
| 积分与结算 | quota_reserve、billing_session、funding_source、task_billing | 持久幂等、价格版本、重复／丢失响应、进程崩溃恢复 |
| API 与流式 | relay-router、中间件、Relay 处理 | 透明转发边界、断流用量、背压、错误及协议兼容 |
| 供应适配 | relay/channel、插件与网关路由 | 留在网关维护，不复制到 Edge 形成第二套渠道管理 |
| 客户 UI | web/src/features 与现有 shadcn 工程 | OceanWay 风格、人民币积分、客户价格与团队维护场景 |
new-api 是单体协作方式：代码依赖全局设置、数据库、缓存和请求上下文。不能仅复制 controller 或一个 Lua 脚本就认为跨服务实现已经完整。提取时记录来源提交、直接依赖、行为差异和对应验证；借鉴已有测试用例，再覆盖新出现的网络与恢复窗口。
不自动恢复的旧规则
历史 Key 单次展示／只存不可取回形式不再直接采用，当前用户已明确掩码旁复制完整 Key。旧仅接受特定 Key 格式、Responses 只返回 202、不支持流式、强制固定请求字段等，只是当时阶段限制，不应成为完整模型接入的默认协议。
不恢复旧 Developer 归档、完整企业组织模型首期必做、旧 TypeScript Contracts 制品或 B0–B6 CI 门槛。旧实现与验证留在历史；新 Go 实现必须有自己的运行证据。
首个实施闭环
先做一条可核验文本流：客户 Key → Edge → Core 授权／价格／预扣 → 网关 → 流式输出 → 最终用量 → Core 结算。覆盖余额不足、同一操作重复请求、断流及结算响应丢失。再做媒体长任务和恢复。
本闭环完成前不按“复用了成熟代码”承诺并发容量；后续分别测 Edge 长连接、Core 热点账户和结算、网关供应容量。并发目标与部署资源另定。
实施先形成新职责矩阵与提取清单，再初始化 Go 工程，不覆盖已有工作树、不恢复所有历史任务为可派发状态。