历史 · 下一阶段

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

当前工作安排：需求、设计与原型优先

2026-09-09 本人决定先补齐并统一全平台需求、产品设计与原型，随后按确认流程排后台 API、前端、API 文档与联调。总体和各平台计划见总体实施计划，实时工作包和决定进入本机协调。计划补全不等于需求/原型已验收。

下方为此前技术进度和 B1 工作包的历史快照，不代表当前唯一派工顺序。Core 存储回归已由 #21 → #19 合入 118f232c，主线 CI 123 单测/105 PG 通过；Console 目录/入口、Design 移交已合并。既有候选和运行限制保留，R1 需求设计轮次不等同 B1 完成。新状态以工作台的带日期核验为准。

2026-09-09 较早技术校正（历史）

以 B1 控制页最新核验 为当前依据，下方 9 月 8 日状态保留为历史记录。Contracts #11、Core #12/#15/#16/#17、Admin #9/#10、Infrastructure #18 已合并；Admin P4 #8 与 Infrastructure #17 已关闭。Core 已实现休眠 Schema 和事务 Repository，但合并态 CI 34308928860 失败（PG 72/73），原 Writer 正修复；独立 Reviewer 已在扩大范围复现四项 P2（回滚断言、B0 角色权限、Gap/Receipt 互斥、SAVEPOINT 事务识别），整体高风险，需修复及专业人工复核。P5 与 B1 真实联调仍未验收。

Studio #20 当前远端检查均通过，本地 #21 失败仍保留；Console #4 尚缺长期机器可读组合证据。下一步依次是 Core 修复与完整 head 接收、Contracts P5、Core Append/Bootstrap；不重开架构。普通包执行独立 AI 审查加用户完整 head 验收，高风险仍须专业人工复核。各仓治理模板同步另列独立包，当前不重复派发。

2026-09-08 历史记录

下一阶段只推进一条可执行、可计费、可诊断、可登记资产的最小链路。固定顺序是：

API Edge → Outbox/Ops Explorer → Metering/Settlement → Text Gateway canary → Asset → Console/Studio cutover

每一步必须通过验收后再扩大下一步范围；不并行迁移全部产品，也不为了演示建立第二事实源。

实施执行已经按十四个独立仓库拆分。整体批次、依赖和验收规则以十四仓实施总控为入口；当前 B1 的仓库级动作分别进入 Contracts、Core、Admin、API Edge、Infrastructure 和 Docs 实施页。本文只维护“下一门禁是什么”，不再复制每个仓库的完整工作包。

API Edge 受控准入基线已经通过固定 Contracts Release、Core/API Edge 独立 CI 与真实跨服务隔离联调门禁。当前工程阶段正式进入 Outbox Publisher（Core 组件名为 Dispatcher）与 Ops Explorer；ADR-030 和实施计划已经冻结设计，当前先收口已发布 Contracts 0.3.0 的 Core/Admin 资格，再按正式依赖落地运行链路。不能因为接口能够返回 reserved 或文档已经完成，就提前进入 Gateway、结算或产品切流。

本轮唯一工作包（2026-09-08）

正式依赖仍为 Contracts → Core → Admin → Infrastructure。以下每仓只有一个当前工作包；表内后继是同一工作包的检查点，不是追加派工。现有其他 PR 保留候选，不新增任务。本轮已向现有 Edge、Infrastructure 任务回传工作包/接口协调；未新建 Codex 任务或承诺时间。固定 SHA、测试和评审输入统一见 B1 控制页。

Core #17 的纯函数测试、Studio 模型隔离以及 Console 的只读产品工作在代码层面不依赖完整 B1 联调。当前每仓仍按上表收口一个包；这些候选不因此自动扩大为并行写同一 Owned Paths。B2/B3/B4 的运行时验收顺序不变。

已完成的进入门禁：Core Run Admission

• Contracts 0.2.0 已由提交 ce323954 固定发布；Core 提交 f9e55b6 的独立 CI Run 33777925718 已通过冻结安装、类型检查、单元测试、构建、依赖审计和专用 PostgreSQL 集成测试。
• 同幂等请求只产生一个 Run、一份 credits Reservation 与两条 Outbox 事件；跨租户、访问链不匹配、无授权、Web-only 模型和余额不足不会部分写入。
• Ledger、Price Snapshot、Model Offering Revision 与 Execution Manifest 的数据库不变量已有真实 PostgreSQL 测试覆盖。
• Core 与 API Edge 使用固定的 @oceanway-ai/contracts@0.2.0；GitHub Actions 对 Contracts Package 只有 Read 权限。
• Contracts 发布使用同一 tgz 写入 GitHub Packages 与 Release，并通过 Registry/Release 制品内容比对 Workflow 验证。

以上只验收 Contracts-first/Core Run Admission 实现基线，不代表生产环境或端到端执行链已经上线。

当前验收范围严格是 Organization-backed。目标架构中的 tenantKind = organization | personal_space 不会追溯改写 Contracts 0.2.0、现有 ExecutionManifest 或 wallet.reserved@1.0；Personal Space API Admission 必须等待 tenant-aware Manifest、Run/Wallet Event、授权与 Billing 门禁以新版本共同发布，在此之前持续拒绝。

1. 已完成的收口门禁：API Edge 受控准入

• 首个命令固定为 POST /v1/responses，请求只包含稳定 publicModelId 与非空文本；Idempotency-Key 必填。
• DeveloperCredential 固定使用 22 字符 keyId 与 43 字符 secret 的 ow_sk_<keyId>.<secret>。调用时 Raw Secret 只到 Edge；Edge 按 keyId 从 Core 读取请求级验证快照，在本地执行 SHA-256 constant-time 比较且不持久化 Snapshot。
• developerCredentialId 就是不可变版本身份；轮换创建新 Credential ID/Key/Secret 并撤销旧 ID。Snapshot 与 Admission 分别读取、复核确切 Credential ID、App、Environment、Service Account、租户和 Billing Account；Workspace 与可选 Project 只由 Environment Execution Binding 唯一解析，Admission 另外解析当前 api Model Offering。
• API Edge 使用短期 Workload JWT 读取 Snapshot 和调用 Core；Core 从 JWT 注入 Caller Workload Principal。内部 Admission 强制 apiVersion="v1"，Edge 与 Core 使用同一 Contracts Canonicalizer 校验请求 Fingerprint。
• Edge 的 Operation/Correlation 稳定绑定 V1、Organization、Environment、Service Account、responses.create 与 Idempotency-Key。Core 幂等记录按 Organization、Execution Principal 与 Idempotency-Key 分区，冲突 Fingerprint 只包含 apiVersion、操作、Environment、Service Account 与公共请求 Fingerprint；Credential Version、Trace 和可变执行绑定不进入 Fingerprint。每次 HTTP 接收仍使用新的 requestId。
• 当前只校验 W3C Version 00 traceparent，沿用合法 Trace ID 写入 Run/Manifest，缺失或无效时生成新 Trace ID；不宣称已形成 Parent Span、Sampling State 或 OpenTelemetry Exporter。
• 成功只返回 flat {requestId, runId, status: "reserved", createdAt}；错误返回 OpenAI-style nested error 和 underscore 稳定错误码。两者都不表示已有模型输出或完成结算。
• API Edge 只做当前最小协议、认证、幂等入口和响应映射；不建立 Credential、Run、输入、余额、Offering 或授权事实的业务持久化。分布式限流、完整链路追踪和公网压测留作公开切流门禁，不写成当前已有能力。

验收基线：API Edge 提交 f97cf5f 的独立 CI Run 33774539995 与 Core 提交 f9e55b6 的独立 CI Run 33777925718 均已通过。Infrastructure 提交 e72e5f3 固定了 gate 源提交 9cc3c9c 及证据 evidence/controlled-admission-e2e-9cc3c9c49b16-f9e55b6e56e4-f97cf5f27027.json。该真实跨服务证据使用固定 Contracts 0.2.0 Release 制品、HTTPS JWKS、RS256 Workload JWT、Edge/Core Socket HTTP 与独立 PostgreSQL，验证了默认关闭、受控 202/reserved、并发同请求收敛、冲突与主要信任边界拒绝、Trace/持久化关联以及响应和服务日志不包含 Secret。事务回滚与更多领域拒绝分支由 Core 自身 PostgreSQL 集成测试覆盖，不能把这份跨服务证据扩张解释为执行、发布或结算验收。完整契约见 ADR-029。

公网仍保持 PUBLIC_ADMISSION_MODE=disabled。该受控链路尚未接入 Gateway 模型输出，Outbox 事件尚未由 Publisher 正式投递，Metering 与 Settlement 也未完成。

2. 下一工程阶段：Outbox Publisher 与 Ops Explorer

当前事实必须先保持准确：Core 已经原子写入 run.created@1.0 与 wallet.reserved@1.0，但没有 Dispatcher、Delivery Lease、正式 Consumer、Operations Projection 或 Query API；现有 run.created@1.0 也不足以独立重建 Request、Developer Access、授权、模型与价格快照。

固定实施顺序：

1. Contracts：0.3.0 已发布配对的 Tenant-aware run.created@2.0 + wallet.reserved@2.0 低敏、自包含准入事件，以及 Operational Observation、Projection Status 与 Operations Query 严格 Schema；下一门是 P3/P4 独立评审与 P5 接收。两个 v1 保持原样并只产生 Legacy/Partial 投影。首个 Producer 只接受 tenantKind=organization；Personal Space 必须等待 Manifest、授权、Billing 与端到端门禁共同通过。
2. Core Schema 与 Worker：在 Event Append 同事务冻结 Mandatory Delivery Set，新增独立 Delivery/Attempt/Quarantine、Lease Token Fencing、Applied Receipt 与版本化 Projection；数据库强制 Event/Observation Source 不可变。Projector 必须支持 operation_linked / observation_only / legacy_run_only，把 wallet-first 事件放入 Pending Reservation 后按全部关联键原子链接，并以严格判别联合表达 verified/unverified Snapshot。Checkpoint 以逐 Delivery/Receipt、未决集合和一致性快照边界证明进度，不使用存在提交乱序与回滚空洞的全局标量 Position。Shadow Rebuild 先冻结 Candidate 集合，Shadow 只追平该集合，再排空旧 Active 并原子切换；最终事务不得扩大边界。首期使用 PostgreSQL 和一个受托管 core-operations-worker，不引入 Kafka/NATS。
3. Observation 与 Query：Core 对已接受 Observation 按 ID 幂等耐久保存，Edge 到 Intake 仍是 best-effort；首期只表达已接受记录范围、健康窗口和已知投递失败，请求级完整性保持 Unknown/Not Measurable。Error Producer 提交固定 Normalization Policy Version，Core Projector 独占标准 Error Fingerprint 计算。Core Authorization 是 Signed Workforce Grant/JIT 的唯一签发 Owner；Query 同时验证 Admin BFF Workload JWT 与绑定该 Workload 的 Grant，特权/跨租户数据释放前的两阶段 Audit 必须全部提交，失败时关闭且跨租户不可枚举。
4. Admin 与证据：交付只读 Run Explorer，按 Request、Operation、Correlation、Run、Reservation、Event 及已摄取 Observation/Error ID 精确检索，显示 evidenceKind、Projection Version、Freshness、严格 Verification/Completeness/Integrity 与 Accepted Observation 范围/健康窗口；只有 operation_linked 可进入 Explorer 详情，其他结果明确显示不适用。Infrastructure 固化多 Worker、崩溃窗口、Pending Reservation、重建切换和权限证据。

本阶段不开放写命令，不接 Gateway、Asset、Metering、Settlement 或客户 Webhook。批次、Lease、退避、保留与告警阈值全部来自配置、SLO 和容量验证，不写无依据常数。

验收：一次受控 Admission 可以从 run.created@2.0 + wallet.reserved@2.0 还原低敏准入、Run、Reservation 和投递/应用链；Event Append 与 Delivery Set 同事务，重复、乱序、提交乱序、回滚空洞、崩溃、旧 Lease、Schema 错误与 Shadow Rebuild 都能收敛或明确隔离；两个 v1、Observation 缺失和后续未接入阶段均诚实显示 Legacy/Partial/Unknown/Not Supported。完成后只代表“可诊断的准入事件链”，仍不代表模型已经执行。

3. Metering 与 Settlement：完成首个严格终局闭环

• Contracts：按 ADR-031 发布 Run/Attempt Manifest 四元组、Gateway Dispatch Slot 与 Binding/Route/Evidence、Execution Closure、SettlementInputSnapshot@1、FinalizationInputManifest@1、三组 FinalizationValidationBundle@1、Billing Decision/Transition/Exposure、Funding 与 Command Result 的封闭 DTO、Canonical Golden 和负向制品。
• Execution 与 Gateway：Gateway 只追加不可变 Evidence，并把唯一 Dispatch Slot 原子收敛到 Bound 或无 Provider Side Effect 的 Terminal Rejection；Execution 用新 Attempt 表达换路，并以不可逆 CAS 冻结完整 Attempt Set。未知提交不得降格成 Not-dispatched。
• Metering：作为 MeterEvent / ProviderCostFact / Eligibility / Settlement Input 的唯一 Writer，逐层校验 Run、Attempt、Binding、Route、Evidence 与冻结 Policy；客户计量和供应成本保持独立，Operational Observation 不能驱动结算。
• 冲突与恢复：Execution/Gateway Owner 冲突及 Metering 本地确定性校验冲突只写内容寻址 Conflict/Blocked Fact，保留 Active Work 并释放 Lease；暂态网络、锁和容量问题不写领域冲突事实。新 Current Generation 以 superseded Finish 关闭旧 Started Attempt，修复后同 Work 可重领。
• Billing：先读取 Execution 关闭前置条件，再构造严格 Input Manifest；对关闭事实、每个 Charge Dimension 的 Metering Snapshot 和实际存在的唯一 Gateway Availability 获取三组 Purpose-bound Receipt。只在 Billing 自己的事务锁定 Account/Reservation/Dimension State，原子提交 Decision、Ledger、Release 与 Outbox。
• 迟到事实与人工处置：成功终局是吸收态；其后更正只追加 Transition/Refund 或 Late Settlement Exposure。任何正差额人工补结都必须绑定严格经济身份、Funding Policy、一次性 Funding Decision、Signed Command Grant、Metering Receipt 和 LateSettlementCommandResult@1；Operations 只拥有 Case 工作流。
• Finalization 对账出口：在任何 Producer 能把 Fence 推进 reconciliation_required 前，同批启用严格 Resolution Request → Candidate → Operations Decision → Core Command Grant → Billing Applied Fact/Event。Case 持有期间普通 Settlement 只推进 Watermark，只有当前代 Resolution Event 能冻结累计输入、创建下一代 Work 并重新执行全部 Owner Reads；重评仍冲突则开启新 Case 代次。
• 授权响应丢失恢复：Command Grant Exchange 按 Assertion Issuer/JTI 的稳定 Operation 先读首次 Issuance Result；完全相同 Candidate/Workload 返回原 Grant，异正文冲突，仅 Result 不存在时消费 Assertion JTI。故障注入必须覆盖 Core 已提交 Grant/Audit、HTTP 响应丢失及跨到期重放。
• Case 准入：首期正式 Operations Case 仅 late_settlement_dimension | billing_finalization_run。Provider Cost、Gateway、Execution、Asset、Webhook 或普通客户计量异常若需要可靠 Admin 队列，必须另发 Canonical Event、Mandatory Delivery、Owner Read、Identity、终态 Authority 和恢复契约，不能复用两个 Billing 分支。

首个 canary 仍只使用 Organization、credits、一个文本 Offering 和一条固定 Gateway 路径；Entitlement/Money 分支先以 Contracts 与负测固定，不在没有产品与账本实现时伪装上线。

验收：Gateway 无规范 Fact 写权限；每个 Attempt、Charge Dimension、Receipt、Ledger Effect 与 Case Resolution 都能沿内容摘要还原；13 个 Event Type/Schema 适用项和 14 个 Mandatory Member 均有 Golden/事务/重放证据；重复、乱序、并发关闭、授权或消费响应丢失、Case Resolution 先后倒置和线性化边界后的更正不会重复扣费、永久卡住或重开历史终局；不确定状态不会被伪装成零费用、失败或成功。

4. Text Gateway canary：接通第一条真实执行链

• Core 使用固定版本的内部 Gateway Execution Contract 和短期 Workload Credential 调用 Text Gateway。
• 首期只接一个明确 Offering Revision、一个执行目标和一个文本 Provider 路径。
• 建立 AttemptExecutionManifest → AttemptRouteBinding → GatewayRouteSnapshot → Provider Evidence 的追加式链路，以及提交确定性、状态观测与安全错误映射；Metering 再生成规范 Fact。
• 同一 Attempt 只有一个 Gateway Invocation/Task、Binding 与 Route Snapshot；网关内部只可在完全相同路由上做有证据的安全协议重试。任何换 Channel、Supply、凭据、Provider Model 或 Adapter 都由 Core 新建 Attempt；不确定提交进入查询与对账，不盲目重试。

验收：一个 API 文本请求可以从准入、执行到终态和结算完整还原；Gateway 不出现客户、DeveloperCredential、用户售价、钱包或产品 Run。

5. Asset：登记正式输出

• 成功结果登记为 Asset Version，保存 Run、Step、Attempt、Blob 与模型版本 Lineage。
• Asset 继承 Tenant（Organization 或 Personal Space）、Workspace 与可选 Project 权限范围，读取与删除执行引用保护；首个 canary 仍只覆盖 Organization。
• 失败、释放或未知状态不创建伪成功 Asset；重放事件不重复登记。

验收：结果可以用稳定 Asset ID 在授权范围内读取，来源与费用可追溯，删除不会留下静默失效引用。

6. Console 与 Studio：按命令切换 Writer

• 先在 Console /ai 接入一个最小文本调用链和 API-only 用量/日志视图。
• 再让 Studio 的一个明确文本或创作前置命令使用同一 Core、Billing、Run 与 Asset 链路。
• 旧入口只能代理到 Core，或继续作为唯一 Writer 并进行无副作用 Shadow Read；不得业务双写。
• 每次切换记录 Writer、路由、幂等水位、在途任务、回滚条件和观察窗口。

验收：同一用户或企业在 Console 与 Studio 使用同一身份、Billing Account、Run 和 Asset 事实；回滚只影响后续新命令，不重做已受理任务。

本阶段明确延后

• /v1/responses 的生产公网切流、真实文本输出、流式与 /v1/chat/completions 兼容入口；
• 多实例分布式限流、客户 IP/细粒度 Scope 策略、完整 W3C/OpenTelemetry 链路与公网容量/压力测试；
• GET /v1/models、Embedding、Rerank、Run 查询、取消和客户 Webhook；
• Media Gateway 正式执行链与图片/视频产品迁移；
• Canvas Runtime 协议冻结；
• 完整 Agent/MCP 组合与跨产品 Handoff；
• Drama、Commerce 和 FDE 私有交付切换；
• 完整 Identity UI、企业 SSO/SCIM 和高级治理。

这些能力在最小文本链路通过后复用同一骨架扩展，不另建钱包、Run、Asset 或模型事实源。