历史档案候选与单体方案快照平台架构
代码组织与部署边界
产品分仓，共享客户后台直接二开 new-api
历史方案：本页为恢复第一版多仓文档前的快照，不是现行任务或已实现能力。现行入口为平台架构。
现行 最终方案 v1.1 采用独立产品仓与一个共享客户后台。oceanway-platform 直接改造官方 new-api，Core、API 接入、账务和任务为内部模块。首期不创建独立 Core、Edge、Contracts 服务或要求固定仓库数量。
| 边界 | 当前安排 |
|---|---|
| 客户后台 | oceanway-platform，已有身份、计费与转发在同一服务内协作 |
| 供应网关 | 独立近上游 new-api；数据库、供应凭据与发布线隔离 |
| 产品仓 | Console/Admin/Developer/Site 与 Studio/Drama/Commerce 保留独立职责 |
| Worker | 先沿用任务模块；需要独立进程时仍在客户后台仓维护 |
| API 规范 | 先在客户后台仓维护版本与生成客户端，不新建 Contracts 运行服务 |
| Docs/Design/Infrastructure | 继续分别维护文档、设计资源与运行配置 |
本地 platform/oceanway-platform 与 text-gateway 共享 Git 元数据；N0 须明确独立分支、远端和发布身份，不能把客户补丁推入供应网关分支。旧 Core/Edge/Contracts 目录保留历史，不删除、不恢复旧实现或旧阶段协议限制。
只在实际容量或独立发布需求证明必要时，再从清晰模块边界提取服务。共享后台可有多个实例，分仓不等于每个模块都需要一个进程。当前没有新服务初始化或生产迁移证据。