RT-05-003 Studio 与 Platform 正式接线证据

记录日期：2026-10-15。本批已实现独立 OceanWay Runtime 的 Studio 产品组合根及 Platform 正式协议适配，并完成具名真实供应闭环：当前用户授权 → Planner 原调用 → 媒体工具 Job → 原 Operation 恢复 → 原输出读取 → Artifact → Studio 资产 → 候选与 inbox 回执。真实验收 Run 完成 2 次 Planner、1 次图像生成，候选未自动采纳；本批全部真实费用为 18.0454 points / ¥0.180454，含首个失败请求的 Planner。受控测试、真实试验、远端 CI 与生产启用分开判定，完整 G2 仍未关闭。任务与门禁只在交付清单登记。

本页区分独立 Runtime、Studio 组合根、Platform Go 契约、正式 Go 全链路及真实供应五个证据层次。不同分块分别通过，不能相加成为一次同 Run、同 Operation 的完整实测；受控供应的合成图和种子余额不能登记为真实模型或实际消费。

本页保留 60b0762 正式接线批次的历史回执。后续付费原产物显式恢复、标题/内容版本分离、CI 修复与预发布/灰度状态见上线收口证据，不覆盖本页的原始费用、UNKNOWN 记录或当时未通过的门禁。

本批开放范围

新 lane 使用 Studio 根页 / 的现有对话展示合同，正式提交 API 为 /api/platform/creator/studio/runs，只接收 chat、无附件、无 Skill 的普通文本与文生图。它安装真实 Planner/媒体协议适配器；测试中的模型响应仍由本地 TCP fixture 提供。Canvas、视频、带引用输入等继续使用旧 Writer，不因共用前端合同而算作 Runtime 已接线。通用 SDK/Panel、结构化人工检查点和最小固定 Workflow 尚未交付，完整 G2 仍由交付清单判定。

职责与写入边界

包以固定 file: 制品安装，包含源码、LICENSE/NOTICE，并记录 Runtime 来源提交及 SHA-256；构建和部署不依赖相邻仓库路径或私有 registry 登录。Runtime 本体不导入 Studio 或 Next.js。

Studio 的 products/studio/runtime/ 持有产品组合根、可信 creator 映射和原 Platform envelope；Runtime 不依赖产品内部表。资产登记独立于对话投递：稳定 assetId 标识原件，conversationAssetId 是产品侧展示引用，候选另外记录 Runtime Run/Job 来源；不伪造旧 Agent Run 或媒体 Task 外键。

代码与制品

资产与组合根最初在 0.3.1 下验证，随后已纳入固定 0.3.2 的 38 项产品 PG 统一复验；各子集属于这 38 项，不能重复相加。

持久执行与恢复

• 首次预检和实际请求来自同一构造器；完整原 envelope 在 HTTP 前持久化。Platform Operation 一旦关联便不可替换，恢复只使用原请求证明。
• UNKNOWN、丢响应或未找到原单都不能证明未执行，只允许定位/恢复。明确准入拒绝且没有发起调用时，才进入独立 blocked；自动 Worker 不解锁，用户显式恢复沿同一意图继续。
• stopped/failed 后的未受理 blocked 不得在迟到的恢复命令下重开。Studio 的真实媒体 Job 一旦明确失败，先终止本轮，不再调用 Planner 创建替代生成；工具参数在 Job 受理前被拒绝时，仍可进入无副作用的参数修正。
• Tool Result 只暴露原任务引用和输出序号，不暴露私有请求、凭据或供给 URL。Artifact 保存前核对规范化原字节；保存重入再核 SHA、MIME 与长度。
• local/S3 使用持久保存 intent 与确定性 key。文件或 S3 PUT 已提交但回执丢失时读取同一对象；不创建新 key，不在异常分支删除可能已提交的原产物。原 provider 身份改变则等待原配置恢复。
• 当前 creator 停用仍可保存已有付费原产物；候选交付继续检查产品权限和目标版本。候选不自动修改文档或画布。
• 停止禁止后续 Planner/新工具；在途原操作继续恢复和保存。本批实现曾把对话改名也作为目标版本变化；后续上线收口已将改名与内容版本分离，新轮次/真实上下文变化仍按冲突处理。系统等待/停止摘要不自行使原交付版本失效。
• 接收端已提交 inbox 后丢回执，重放返回原回执；首次投递前目标版本已变化则保留原产物和待处理状态，不自动投递到新版本，也不重新生成。

首次预检与实际 Planner 请求的完整指纹在受控组合根测试中核对。生成调用、保存和投递各自拥有持久屏障；关闭浏览器或更换适配器实例不会使原调用获得新的 dispatch 资格。候选回执目标同时冻结在 Agent 策略中，只有原 Job、实际 Artifact 及该目标回执都满足，才向后续 Planner 提交 saved observation 或宣布完成。

本轮组合根测试还发现并修复了有状态适配器方法丢失接收者的问题：直接把类方法交给冻结回调的执行器会丢失 this，工具进入 UNKNOWN 且没有媒体 POST。组合根现用闭包绑定实例，Runtime 端口接收者合同另有专门回归；未知错误仍保留原身份，不能因为修复代码而自动新发原调用。

真实供应还暴露了保存阶段的超时差异：已结算原 PNG 为 1,406,082 字节，一次读取需 13.257 秒，超过原先共用的 10 秒 activity 预算。媒体原 binary 输出与 provider refresh 已改为复用现有 image/video 模型超时，locate/普通 metadata 仍用 activity；没有新增超时常数、重试或媒体身份。该修正只延续原 Operation/原输出的保存，不再提交生成，也不将保存等待登记为生成失败。

正式联验发现的合同缺口

正式 Go HTTP 联验暴露了受控适配器 fixture 未覆盖的身份长度约束：Runtime 的 execution_ 加 64 位摘要共 74 字符，被 Studio 原样用于媒体 idempotency_key；Go 原媒体 request ID 只允许 1～64 字符。首次 Planner 已由正式 Go 结算并保存，媒体在创建 Operation 前被拒绝，客户端未取得可证明未创建的正式回执，因此原 Job 保持 UNKNOWN，未产生 Artifact、候选或 inbox。

真实供应首个请求也命中同一缺口。该请求只完成原 Planner，不能登记“真实图像生成成功”或完整闭环。修复必须在首派发前建立符合正式合同的稳定媒体身份，并覆盖实际 Go 路径；既有持久 envelope 不变，原 UNKNOWN 只定位/核对，不能将缩短后的新键写回原调用后重派。Studio 已为新请求将媒体字段稳定映射为完整 64 位摘要：映射在首派发前冻结，私有 call ID、Job 和 sourceRef 继续使用原执行身份；旧原键仅按原 envelope 定位/读取。正式 Go 与真实模型的修复后结果仍各自登记。

这项发现说明为什么分块测试与完整联验需要分列：官方客户端、真实 Runtime 和产品 PG 均参与的受控测试，可以验证组合根恢复和保存，却不能替代正式 Go 对输入、授权和账务的实际判断。

修复后，干净源树 caffaab3857d9c56a36b795fe44c81701d0c7134 的正式 Go 受控链已通过：独立新验收 Run runtime-c4ab7f39-677c-47d0-b2e8-4b808ff5ff72 经 Studio 正式 HTTP、真实 Go Platform 与两个隔离实库，形成 2 次 Planner＋1 次媒体、3 个 succeeded/settled/saved Operation，以及各 1 个 Job、Attempt、Artifact、候选和 inbox。旧 Agent/媒体任务 Writer 记录为 0，候选未采纳；重复同一请求及额外 Worker 没有新增供应调用。

该链供应仍为本地合成响应，真实模型调用为 0。原图按冻结规格规范化为 31×53、1010 字节；最终 SHA-256 bde5db9483e9c7c3fd12272c568b056288c2e8d72b400d7ec960f05914aa56bc 与资产、Artifact 和 inbox 关联一致。受控供应账务在隔离夹具中结算，不登记为真实账户消费。证据为本轮验收目录的 owned-v2-http-acceptance-safe.json；旧失败 Run 的 Core/Platform 已停止，UNKNOWN 原 envelope 仍保留，不伪装成原 Run 修复。

真实供应同 Run 验收

真实验收使用独立 Studio 数据库、本机正式应用及原有普通客户/合法产品 key，沿 Platform 的现有余额、当前用户授权和正式供应链执行；没有新增测试余额或绕过 TLS。传输复用电脑现有系统代理。该环境证明实际产品协议、供应、费用与保存闭环，不表示 Studio 生产实例已开启新 lane。

3 个真实 Operation 均为 succeeded/settled/saved，费用包含原媒体恢复、保存和最终观察之后的全部已发生调用；保存网络超时只重读同一原输出，没有第二次生成。实测源树为 7e2392f7cbc8a6c6f1b48b474ff6133a0d852fcc，安全回执为本轮验收目录 live-v2-http-acceptance-safe.json。首个身份长度不合的失败 Run 与其成本完整保留，不并入本 Run 伪装成功。 最终源码 60b0762ee1cfc8006c328e48e1cffc6737de9af7 上连续两次提交原 clientRequestId 均返回同一 completed Run，未新增调用或费用；再次核验仍为原 2 Planner＋1 图像、同一 hash/Attempt/候选/inbox。

受控与真实两库另以 READ ONLY / REPEATABLE READ 严格复核：各 Run 的 call → Job/sourceRef → Attempt → Artifact → 存储资产 → 对话资产 → candidate → inbox → 冻结目标关联一致，Attempt/Artifact/Delivery 各 1 个且状态正确。该 scope 内旧 Agent 与旧媒体任务为 0 行，产品链接的旧 run/task 外键为 null；共用 shared_media_assets 各有 1 条原件登记，这是复用现有存储，不能写成“旧存储 0 行”。安全映射回执为 final-db-mapping-safe.json。

Writer 与回退边界

新 clientRequestId 一旦绑定 Runtime，原消息、对话、context、core Run 和 Platform 授权均按该身份恢复。已有旧 Agent/媒体记录仍由旧队列处理；新 Worker 只列出自己的绑定与 Job。两套 Worker 可以在同一维护入口被调度，但不能推进对方的记录。

第一次请求还没有 conversation 时，单靠对话锁不能阻止新旧 lane 各建一轮。本批增加 studio_run_request_writers，以 product/subject/creator/clientRequestId 唯一认领 lane 与实际 Run ID，并与产品 Run 创建同事务提交，发生在授权 HTTP 之前；事务不会跨 HTTP 持锁。失败一方按原 binding 读取，不能借 rollout 开关或重试换 Writer。既有历史 binding 仍为权威，不要求回填认领表；原正文指纹继续由各自 prepare 合同校验。旧 Run 删除后仍保留请求 tombstone，不设 TTL，也不将删除解释成可重新派发。输家事务同时回滚本轮自动创建的 Runtime conversation/messages，旧方此时尚未 attach 对话。7 项独立受限 PG 测试覆盖双 lane 首次竞争、各自并发重放/改正文拒绝、跨主体隔离与未回填旧记录保护，未触发收费调用。

旧 Run 从失败状态恢复或重试时，也可能与新 lane 争用同一对话；只在 HTTP 前查询一次活跃 Run 不能覆盖授权网络请求期间的竞态。本批已在同一对话锁下增加持久占位及原命令恢复：成功绑定旧授权后解除占位，模糊失败保留占位，不按 TTL 假设旧调用未发生。最终旧 retry 事务还按 scoped conversation → Run → guard 加行锁，严格核对原 run、command、action 与 fingerprint。5 项隔离受限 PG 测试覆盖模糊原命令保留/挡新 Writer/同命令恢复、已有 Runtime 时旧 retry 在授权前拒绝、明确无 grant 拒绝释放/并发 stop 保护，以及实际 retry 双请求中共享 guard 已释放后迟到 grant 不得绑定或写入重试命令（分别在有/无新 Runtime 下验证）。该围栏验证本批同进程 lane 互斥，不代表旧队列已迁移或独立服务 Writer 交接完成。

OCEANWAY_STUDIO_RUNTIME_ENABLED=1 只决定新请求是否进入此 lane。关闭开关后的回退必须保留 Runtime 制品、schema、读取/控制入口及原单恢复 Worker，直到已有任务和回执完成交接；不把原任务复制回旧队列，不回滚数据库后重放收费请求。生产 Writer 交接与独立 Runtime 服务仍未执行。

Runtime 资产 intent 保留原 provider 身份、确定性 key 和内容指纹，不保存存储凭据。provider 身份不匹配时暂停保存，等待原配置恢复；旧清理器不得删除仍被 Runtime 引用的原件。新候选、inbox 与资产的完整删除/GC 策略另行交付，本批不自动清理这些记录。

已获得的验证

旧 PG 回归使用新建隔离库及显式 C locale。最终收尾时曾并行运行 PG、单元、构建和 lint，2 个旧测试触发既有固定 5 秒超时；未改测试 timeout，清空并新建 fixture 后串行独立复验：旧 178/178 用时 11.3 秒，新 38/38 用时 4.61 秒，均无跳过；先前超时仍保留为并行资源负载下的失败回执。首次复用已污染 fixture 的领取数量差异、以及另一新库 en_US.UTF8 下既有 prompt facet 排序预设差异分别保留为环境问题；未修改无关 prompt 代码，也不把这些运行混入最终 178 项通过计数。

本轮来源与原有工作树指纹固定于 Runtime 仓 docs/verification/studio-integration-baseline.json。原有 Studio 57 个、文档站 14 个未提交文件保留；另有并发对象存储/架构文档增量未纳入本轮 4 文件提交，也未覆盖；必要的数据库 pool export、存储入口和数据库说明采用追加增量单独审查。业务生产部署、旧队列接管、独立 Runtime 服务、Canvas 完整接线、Drama/Commerce 实际消费均另有门禁。