历史 · 本机协调与首轮工作台
重构前档案，仅供追溯，不作为新版本执行指令
历史档案 · 2026-09-11 重构前快照。 本文中的“当前”“已冻结”和实施顺序属于旧基线。新版本以现行总览和实施计划为准。
当前全部平台由本人负责，本机文件是任务协调主入口。总协调会话安排计划、顺序、依赖与决定；各平台会话按本地工作包执行。不要求每次需求讨论、原型修改和本地检查先建 GitHub Issue。
最小文件结构
OceanWay 工作区根目录维护：
coordination/
├── README.md 入口、计划工作树与续接方式
├── workboard.json 唯一实时任务状态与首轮队列
└── decisions.md 本人已确认决定与待确定事项需求稿、设计、原型、API 草稿和报告留在对应仓库，优先补现有文档；工作台保存引用，不复制两份方案。根目录不是 Git 仓库，本地保存不等于已备份，需要备份时再归档或同步。
首轮工作顺序
目标为统一各平台需求、设计与原型。先盘点全平台，再按下列顺序走查；独立需求整理可以并行：
- 共用基础：Design 规范/组件、全平台入口与身份需求、Docs 文档结构、Contracts 消费者需求。
- 主要产品：Site → Console → Studio 的浏览、进入、创作/开发与返回流程；Admin 单独走员工查询链。
- 垂直产品：Drama、Commerce 的首期专业流程，先解决方案差异。
- 服务与环境：Core、Edge、双 Gateway、Infrastructure 对应产品动作补时序、状态、接口和配置原型；其需求盘点从第一步即可开始。
- 汇总评审：本人确认首期范围和原型，再排后台 API、前端、文档、联调工作包。
Developer Center 仅做迁移盘点，不开独立产品设计。已有 B1 和产品候选保留基线；首轮优先级变化不抹除成果，也不自动向其他运行中的会话发停止指令。
本地工作包字段
| 字段 | 内容 |
|---|---|
| ID / 标题 / 仓库 | 稳定本地 ID，已有 Issue 可选关联 |
| 负责人 / 执行者 | 最终负责人统一为本人，执行会话/Agent 可选 |
| 目标 / 产出 / 非目标 | 可解释成果与文件位置 |
| 阶段 | 需求、设计、原型、API设计/开发、文档、联调、发布 |
| 状态 / 下一动作 | queued、in_progress、needs_decision、ready_for_review、accepted、blocked、deferred |
| 依赖 | 具体工作包/决定/接口，并说明阻塞设计、开发、联调还是发布 |
| Owned Paths / 工作树 | 允许改动文件与唯一写入者 |
| 基线 / 交付引用 | 分支与完整 commit；未提交成果用文件摘要；原型可用版本文件 |
| 验收 / 证据 | 场景、命令/环境、预期/实际、报告、本人的决定 |
| GitHub 引用 | 可空，需要时关联历史/正式交付，不另建重复实时表 |
accepted 只表示该包约定的成果被接受。需求包通过不表示 API 或原型完成；合并、真实联调、部署另列，不能压为一个勾选框。
交接方法
开始前读工作台、决定和实施页，确定复用来源与写入路径。可以在不同仓或明确不冲突的文档分区并行；migration、锁文件、共享注册表和状态机保持唯一写入者。
结束更新实际文件、版本/摘要、检查结果、剩余决定和下一动作。本人在会话已确认的事项，记录原意、日期与对应文件即可，不要求重复去 GitHub 评论。原型评审直接使用本地文件、预览和走查记录。
未提交成果可以交接，但不得归到旧 commit。目录停在旧分支时先定位工作树，不批量 reset、清理或覆盖他人工作。本地文档与原型引用允许，运行代码仍不通过父目录导入其他仓源码。
何时使用 GitHub
- 已有 Issue/PR 可继续关联正式代码交付，不为本地计划重复开单。
- 需要远端备份、独立审查、主线合并、CI 或制品发布时关联本地工作包。
- 推送后仍遵守已有远端规则；本地模式不关闭 CI、不伪造检查或批准。
- Actions 计费/额度或网络只阻塞依赖它的验证发布，不阻塞需求、设计、原型和可执行的本地检查。
- 正式运行仍固定 Contracts/镜像/环境组合；生产动作按已有授权执行，明确确认可以复用。
旧实施文档“GitHub 唯一协调来源”“开工必须先有 Issue”的要求，在本轮单人本机模式下由本页取代。已合并代码、Release、历史验收继续是证据。其他仓静态模板在需要时定点同步，不要求本轮批量修改所有仓库。