交付批次与关键路径
OceanWay 十四仓从受控准入到产品切流的固定跨仓交付顺序
实施采用“仓库内独立增量、跨仓按批次验收”的方式。批次不是按组织部门划分，也不是所有仓库同时发版；它代表一组只有共同通过才能扩大系统能力的跨仓门禁。
批次状态
| 批次 | 目标 | 主责仓库 | 当前状态 |
|---|---|---|---|
| B0 | Contracts-first 受控 API Admission | Contracts、Core、API Edge、Infrastructure | 已验收，公网未开放 |
| B1 | Outbox、Operations Read Model 与只读 Explorer | Contracts、Core、Admin、API Edge、Infrastructure | 当前实施批次 |
| B2 | Execution、Gateway Evidence、Metering 与 Billing Finalization | Contracts、Core、双网关、Admin、Infrastructure | 目标契约已冻结，运行时待实施 |
| B3 | 单一路径 Text Gateway Canary 与正式 Asset | Core、Text Gateway、Contracts、Infrastructure、Admin | 等待 B2 |
| B4 | Console /ai 与 Studio 逐命令切换 | Console、Studio、Core、Contracts、Infrastructure | 等待 B3 |
| B5 | Media、Drama 与 Commerce 复用共享骨架 | Media Gateway、Drama、Commerce、Core、Admin、Infrastructure | 等待 B4 的最小链路 |
| B6 | 企业治理、FDE 私有交付与受控公网扩大 | Console、Site、Developer Center、API Edge、Core、Infrastructure | 按能力分别验收 |
B0：受控准入基线
已经验收的范围仅包括固定 Contracts Release、DeveloperCredential 在 Edge 终止、Edge → Core Workload JWT、Organization-backed Run Admission、credits Reservation 与事务内 Outbox Append。
该批次不包含 Provider 调用、模型输出、正式事件发布、Metering、Settlement、Asset 或公网切流。后续不得追溯改写 B0 已发布 Schema；新增语义进入新版本。
B1：可诊断的准入事件链
固定顺序：
- Contracts 发布配对的 Run/Wallet v2、Delivery、Observation、Projection 与 Query DTO。
- Core 完成 Append-time Delivery Set、Dispatcher、Applied Receipt、Projector、Shadow Rebuild 与私有 Query。
- Admin 接入只读精确检索与 Run Explorer。
- API Edge 接入 best-effort Operational Observation，不改变客户响应。
- Infrastructure 使用真实 PostgreSQL、Workload JWT 和多进程故障注入固化证据。
- Docs 更新版本、Commit、CI、限制和运行手册。
GitHub 只承载实时执行状态，稳定范围继续以本目录为准：
| 顺序 | 仓库 | GitHub Milestone | 稳定工作包数 |
|---|---|---|---|
| 1 | oceanway-contracts | B1 · Operations Contracts | 4 |
| 2 | oceanway-core | B1 · Outbox & Operations Read Model | 8 |
| 3 | oceanway-admin | B1 · Read-only Run Explorer | 4 |
| 4 | oceanway-infrastructure | B1 · Operations Observability & Evidence | 5 |
退出门禁：一次受控准入可从不可变事件、Delivery、Receipt 和 Projection 还原；Legacy、Unknown、Not Supported 与 Projection Gap 均被诚实显示。
B2：执行、计量与账务终局
固定顺序：
- Contracts 发布 Attempt、Dispatch Slot、Binding、Route、Availability/Evidence、Closure、Eligibility、Settlement Input、Finalization 与 Case Resolution 严格联合。
- Core Execution、Metering、Billing 与 Operations 分别实现唯一 Owner Repository 和版本化 Read/Validate Contract。
- Text/Media Gateway 实现同级的私有 Gateway 契约与不可变 Evidence，但 Media 不因此提前进入产品流量。
- Admin 只读取 Operations 投影，不直接修改 Gateway、Metering 或 Billing 事实。
- Infrastructure 验证响应丢失、租约失效、乱序、重复、未知 Provider 提交和账务事务回滚。
首期正式 Reconciliation Case 仍只允许 late_settlement_dimension | billing_finalization_run。其他确定性冲突保留为 Owner-local Conflict Fact 与 Active Blocked Work。
退出门禁：同一 Attempt、Charge Dimension、Receipt 与 Ledger Effect 可完整还原；重复或乱序不会重复扣费；不确定状态不会被伪装成失败、成功或零费用。
B3：Text Gateway Canary 与正式输出
首个 canary 固定为一个 Organization、credits、一个公开文本 Offering、一个 Execution Target 和一条 Provider 路径。Core 创建 Attempt；Text Gateway 冻结 Binding/Route 并执行；Metering 产生规范事实；Billing 终局；成功结果最后登记为 Asset Version。
退出门禁：输入版本、授权、模型、路由、Provider Evidence、客户计量、供应成本、Ledger 和输出 Asset 可沿稳定 ID 与摘要还原；Text Gateway 中不存在客户、公开价格或产品 Run 第二事实源。
B4：客户控制台与 Studio 切换
Console 先接 /ai 的一个最小文本调用链和 API Usage/Logs 只读视图；Studio 再迁一个明确命令。每次切换必须记录旧 Writer、新 Writer、幂等水位、在途任务、流量比例、观察指标和回滚条件。
退出门禁：Console 与 Studio 共享 Customer Identity、Tenant、Billing Account、Run 和 Asset；旧新实现没有业务双写，回滚不重做已受理 Operation。
B5：媒体与垂直产品
Media Gateway 在与 Text Gateway 同级的契约上接入图片/视频；Drama 与 Commerce 继续拥有自己的业务聚合，只通过 Core 的 Asset、Run、Agent、MCP 与 Billing 使用共享能力。
退出门禁：至少一条媒体链、一条漫剧生产链和一条商品内容链通过刷新、重试、撤权、费用、写回和回滚验证。
B6：企业、FDE 与公网扩大
企业 SSO/SCIM、席位、授信、发票、DLP、数据驻留、FDE 私有交付和 Public API 扩容分别作为独立门禁。公开 Site/Developer Center 可以先上线内容，但任何登录后管理或机器调用必须回到 Console/API Edge 的正式边界。
公网扩大前必须补齐多实例限流、完整 Telemetry、容量与压力证据、应急降级、Secret 轮换和客户通知 Runbook。
并行规则
允许并行：
- 公开品牌内容、公开 API 文档和案例策划；
- 不产生正式事实的 UI 原型、Schema 评审与迁移盘点；
- 各仓 CI、代码规范、依赖安全与只读适配层建设；
- 后续批次的测试夹具和风险验证。
禁止并行越权：
- 在上游门禁前创建正式 Run、Reservation、Ledger、Asset 或 Provider Task；
- 让产品仓绕过 Core 直接调用网关；
- 为演示建立第二钱包、第二模型目录或第二 Operations 事实源；
- 未完成 Writer 排空和证据登记就切换生产流量。