历史 · 平台与运行仓库
重构前档案，仅供追溯，不作为新版本执行指令
历史档案 · 2026-09-11 重构前快照。 本文中的“当前”“已冻结”和实施顺序属于旧基线。新版本以现行总览和实施计划为准。
平台层只有三个仓库。Contracts 定义跨仓协议；Core 拥有共享领域与运行事实；API Edge 终止机器协议与认证。Core 保持模块化单体，不再拆 Identity、Wallet、Asset 或 Execution 仓库。
本轮先统一三个服务的消费者需求、服务设计和可运行原型，再按依赖推进后台 API。各仓需求、设计、原型、实现和验收均由本人负责，当前协调入口为本机工作台；已有 Issue/PR 保留为历史及可选同步链接，开工不以新建 GitHub 任务为前置。共用交付模板见实施工作流。
| 仓库 | 首轮需求和设计产物 | 原型形态 | 后台阶段 |
|---|---|---|---|
| Contracts | 消费者场景、字段所有权、版本与兼容决策 | 合成消息、Golden、正反向 Schema/消费 fixture | 生成与发布工具、固定版本资格 |
| Core | 命令/查询、领域事实、事务和授权矩阵 | 调用时序、状态机、失败注入 fixture | 按 Append、投影、查询等纵切实现 |
| API Edge | 开发者请求/重放/错误体验、Core 依赖 | 请求回放、响应对照、无接线 adapter fixture | Observation、执行协议与公网能力逐阶段接入 |
非 UI 服务也必须完成产品设计：明确谁调用、要解决什么问题、成功和失败如何解释，以及消费者下一步能做什么。时序图、状态机和可运行 fixture 是这三个仓库的原型；不为内部服务强行增加管理页面。
每项需求关联设计决策、原型场景、接口条目、实现切片和验收证据。首轮交付标注“待定/草案/原型已验证”，不得写成已上线能力。现有 B0 准入与 0.2.0 契约作为回归基线保留，不重新建设。
需求和设计可以先于依赖完成，使用合成数据验证交互及错误语义；正式跨仓消费仍须固定已发布 Contracts 版本和摘要，并完成生产者/消费者资格。原型通过、代码合并、包资格、环境联调和发布是不同状态，分别在本机工作台登记。
API 文档随服务实现维护：Contracts 拥有 Schema 和版本语义，提供 HTTP 的仓库拥有 OpenAPI 的路由与鉴权描述，Docs 组织说明和链接。尚未确定的 method/path 不写成可调用端点。B1 技术约束及证据入口见 B1 交付控制页。