历史 · 产品与 Surface 仓库
重构前档案，仅供追溯，不作为新版本执行指令
历史档案 · 2026-09-11 重构前快照。 本文中的“当前”“已冻结”和实施顺序属于旧基线。新版本以现行总览和实施计划为准。
六个活跃产品仓负责不同用户旅程和产品私有聚合，不拥有第二套 Identity、Wallet、Run、Asset、Model Control 或 Operations 事实源。oceanway-developer-center 仅保留为迁移来源。
| 仓库 | 用户界面 | 首个稳定交付 |
|---|---|---|
| Site | oceanway.tech | 品牌、能力、案例、商业合作与 FDE 公开面 |
| Developer Center（历史） | 无独立 Host | 迁移证据与归档门禁，不再发布 |
| Console | ai.oceanway.tech、console.oceanway.tech | 公开开发者入口、组织上下文、Billing 与 /ai 私有控制面 |
| Studio | canvas.oceanway.tech | 统一创作与 Canvas 的首个 Core-backed 命令 |
| Drama | 待定 Host | 漫剧项目通过共享 Asset/Run 接入 |
| Commerce | 待定 Host | 商品内容通过共享 Asset/Run/MCP 接入 |
| Admin | admin.oceanway.tech | Workforce 只读 Run Explorer |
以上是产品目标与稳定交付方向，不代表这些能力均已实现。现阶段保留 Studio 的既有运行能力和 /drama；独立 Drama 从自己的需求基线建设，不搬走 Studio 短剧。Commerce 先围绕已存在的八个工具确认首期范围，不自动恢复长期规划里的全部管理模块。
本轮先统一需求、设计与原型
所有产品由同一位项目负责人统筹。文中产品、Identity、Billing、设计和 API Owner 表示职责与数据责任，不表示必须存在不同团队。工作包、待决策事项和验收记录优先按本地协调维护；已有 GitHub Issue/PR 作为来源与历史证据，不是开展需求或设计工作的前提。
完整流程遵循统一实施流程。本轮结束条件是六个活跃产品都有可追踪的需求基线、信息架构、统一设计说明及关键旅程原型；不是将所有后台或所有页面一次开发完。首轮原型使用明确标识的演示数据，并展示真实接入缺口，不作为生产能力证据。
| 推进次序 | 本轮设计工作包 | 主要输出 | 后续最小开发切片 |
|---|---|---|---|
| 先定共同基础 | 六产品用户、术语、导航、品牌、组件与账户边界 | 产品边界表、共同组件清单、待决策记录、跨平台主旅程 | 消费同一设计基础；身份和领域逻辑各守边界 |
| 第一组 | Site + Console + Studio | 发现产品/模型 → 进入正确平台 → 创作或 API 管理 → 结果/用量的主链原型 | Site 公开内容；Console 已有目录及 Owner 接入；Studio 保留能力的渐进迁移 |
| 第二组 | Drama + Commerce | 以各自既有需求和工具为基线的专业生产原型 | Drama 一个视频段；Commerce 一个商品图片任务的纵向链 |
| 同轮独立链 | Admin | Workforce 登录 → 精确搜索 → 证据时间线的只读原型 | 既有 Query BFF 接缝与真实 Core 依赖的联调 |
| 随 Console 处理 | Developer Center 历史来源 | 内容去向、链接、迁移与保留证据 | 接收端通过后再逐项退场，无独立新原型 |
次序表示依赖和评审顺序，不要求一个人同时建设六套产品。各产品可并行整理材料；共同基础确认后，每次选择一条可完整评审的旅程推进。按阶段退出条件安排下一包，不给缺少依据的统一完成率或承诺日期。
每个产品需要交付什么
- 需求基线：明确主要用户、任务目标、首期范围、明确不做、已有能力、待决策问题及成功条件。沿用既有需求编号，新增项与来源逐条关联。
- 产品设计：1–2 条主旅程、页面清单、导航层级、组件复用、内容与状态矩阵；设计依据统一设计系统，候选 token 不冒充已冻结标准。
- 原型：覆盖正常、空、加载、失败、权限不足、依赖未接入和恢复状态。适用的平台验证桌面、390/430px、键盘与浅深主题；只支持单主题或桌面生产的产品明确范围。
- API 能力清单与文档草案：从需求/设计阶段把每个按钮和数据区对应到读/写能力、当前事实 Owner、目标 Owner、认证、权限、副作用与缺口，同步起草 API 文档。原型页名或建议 URL 不等于已发布 HTTP 契约。
- 实现与文档验证：设计确认后按最小纵向链冻结契约、开发后台与界面、联调；同步校准请求/响应、错误、分页、幂等、版本与可运行示例，不在验收结束后补写文档。
- 验收包：把需求 → 页面/动作 → API 能力 → Owner → 测试 → 文档串起来，分别记录原型通过、代码验证、真实联调与上线状态。
上游接口尚未实现时，仍可确定用户需求、绘制状态、制作无副作用原型并编写接口需求草案。登录后真实数据、费用、正式 Run/Asset、特权查询和运维处置的接通，才需要对应身份、契约、权限与运行门禁。公开页面也须在内容与入口真实可用后单独安排发布，不因原型完成自动上线。
产品页补充本轮执行清单与交付依赖，长期架构仍以平台产品架构为准；发现旧架构与当前产品需求冲突时记录差异和确认结论，不把两套流程叠加为首期功能。