历史 · 多仓本机实施与提交规范

历史档案 · 2026-09-11 重构前快照。 本文中的“当前”“已冻结”和实施顺序属于旧基线。新版本以现行总览和实施计划为准。

当前全部项目由本人负责，按本机协调登记任务、需求决定、原型意见和本地验收。GitHub Issue/PR 是可选远端关联，不是本轮开工前提。已存在的 Issue、PR、固定制品和历史 CI 继续可追溯。

工作包与并行

本地工作包写清 Owner、目标、产出、非目标、依赖、Owned Paths、验收与下一动作。需求或原型包可以没有代码分支与 GitHub ID；涉及代码时保留隔离分支/工作树，避免覆盖在途成果。

Codex Project = 一个仓库的实现上下文；OceanWay 根项目负责总协调
本地 Work Package = 一个有明确产出、范围、依赖和验收的增量
Worktree = 代码/复杂文档增量的隔离工作目录
Branch = codex/<local-package>-<slug> 或已有 issue 分支
GitHub Issue / Pull Request = 需要时关联的远端交付记录

不同仓库或不冲突的文档分区可并行。Migration、OpenAPI 根文件、依赖锁、共享注册表和状态机同一时间只有一个写入包。跨仓功能在本地总工作包关联各仓子包，不复制源码和 DTO 维持同步。

本地完成与交接

每包保存源版本、实际文件、未提交摘要、运行命令、验证环境、结果和本人决定。需求包按范围与场景验收，原型包按可走查流程和状态验收；代码包执行与改动相称的检查。不要为可逆文档或静态内容改动增加无关业务测试。

目录名不等于当前分支。开始前检查实际工作树与未提交内容，已合并分支不追加新工作，旧证据不自动覆盖新 head。正式接收范围发生变化时，复验受影响内容，不机械重跑无关全量测试。

Commit 与可选远端 PR

Commit 使用 Conventional Commits。每个提交保持可审查范围，不提交 Secret、客户数据或无关生成文件。不直接向远端默认分支推送，不 force push，不清理其他任务的文件。

采用 GitHub 时，每个 PR 对应仓库内增量并关联本地工作包/必要 Issue，填写结果、范围、契约、验证与回滚；遵守远端现有模板、CI 和评审规则。本机模式不自动修改远端 Required Checks 或宣布批准。默认分支从仓库实际配置读取，Design 使用 baseten-ui。

Contracts 与版本

接口需求和草案可以本地评审。正式跨仓消费仍按：规范确认 → Contracts 固定制品 → Producer 兼容 → Consumer 固定版本 → Infrastructure 组合联调 → 按能力发布。

允许本地文档、原型和报告引用，不允许运行代码依赖跨仓源码路径、未发布分支或复制类型。一个接口一个规范源，文档引用固定版本。环境发布记录 Repository、Commit、Artifact/Digest 和 Contracts 版本。

本地检查与远端限制

本地检查先按改动执行：文档用 MDX/类型/构建/链接；产品用对应浏览器流程；数据库用真实约束/事务；Gateway 用协议/恢复证据。具体要求见验收与发布。

需要远端合并或制品发布时补对应 CI。Actions 计费/额度或网络问题登记为外部阻塞，不跳过必要检查，也不阻塞独立需求、设计和原型。现有分支保护与模板由 Infrastructure 维护，本轮不批量调整各仓远端设置。

同一个人的不同职责

总协调：优先级、依赖、决定、接收状态。
产品/服务职责：需求、设计、API、实现、文档和测试。
Contracts 职责：规范与版本一致性。
Infrastructure 职责：环境、部署、观测和恢复。
Design / Docs 职责：设计规范与实施/API 说明的各自唯一维护位置。

以上均由本人承担，执行工作可以交给不同会话；无需虚设多团队签字链。已明确授权与确认按原文复用，发布和风险相关验证仍针对真实动作与现有要求进行。PR 合并、页面可访问、本地测试或文档更新都不单独等于上线。