PROC-04-001 跨项目架构深度复盘（2026-10-28）
Studio重制、Drama重制、Platform、Media、Runtime与统一运营后台的实际架构、偏离、公共能力边界和纠偏建议
日期：2026-10-28，Asia/Shanghai。范围：Studio 重制 oceanway-creative、Drama 重制 oceanway-drama-rebuild、Platform、当前 Media、Runtime、旧 Studio、Commerce，以及统一运营后台需求。
判断：本次审计确认存在系统边界偏离，主要问题不是“没有公共模块”，而是公共服务已经存在，各产品仍各自解释它的鉴权、任务恢复和文件生命周期；与此同时，重制方案、现行代码、历史 SDK 和线上制品分别处于不同阶段。 应先统一权威、协议和消费方式，再抽重复代码。建议复用 Platform 与 Media 两个现有中央权威，建立独立于 Runtime 的小型 SDK；产品保留业务数据与流程，运营后台通过授权接口管理它们。
本报告是审计结论和改造建议，不是已批准的新 ADR。本轮只读源码、Git 和运行制品，进行了无凭据 GET 探测；未修改业务代码、部署、操作业务数据库或调用收费模型。源码链接固定到本次核对提交及行号；需求文档链接指向文档站页面，后续可能继续演进。工作树包含并行修订，不能等同远端 main；时点与制品限制见 PROC-04-005。
本页是所有项目共用的审计总入口。事实截至 2026-10-28；Proposed 表示建议尚待确认。本文不替代已批准 ADR/PRD，也不授权生产迁移。分系统证据见文末附件，版本与核查边界见 PROC-04-005。
后续行动见跨项目公共能力收敛实施计划：按用户后续明确的多仓、React + Go + PostgreSQL + Redis、保留 new-api 及无旧语言兼容约束，明确 Platform 统一登录鉴权、可用模型和图片/视频费用预估展示，与 Media 共同管理系统资源；公共接入与产品/商业新增功能分别排期。下文保留审计时点事实与当时建议，后续实施范围以该计划衔接；新增架构建议仍为 Proposed。
1. 首先还原“现在到底是哪一套系统”
| 对象 | 查到的事实 | 正确判断 |
|---|---|---|
| Studio 重制 Creative | 710e20c；backend/web 相对固定上游没有差异，交接明确 P2 未开始 | 已选定 Go + React/Pi 底座，尚未完成 Oceanway 中央接入 |
| 旧 Studio | 本地 main 90eba1a；运行镜像 label 也是此 SHA，编译代码含 oceanway.text-request.v1 | 直接 Platform 生成和新文本恢复消费代码已有；不能将容器名中的 38028fe 当实际版本 |
| Drama 重制 | 本地 4165661；正式 API db860424、Web b5b9c539 | 已部署 Go + Vite；Go 行为与本次审计源码一致，本地差异主要是验收文档 |
| Platform | 本地 main db801bf；运行镜像 label ecac00e | label 对应旧源码，但实际二进制已包含新文本恢复合同，公共路由探测也确认存在；完整源码来源不能单靠 label 还原 |
| 当前 Media assets 实例 | pic-vps 的 oceanway-media-isolated-app，label 9220708，配置桶 oceanway-media-assets-cn | 已有统一素材部署实例；Platform 配置目标是 https://media.oceanway.tech，精确反代上游本轮未独立核验 |
| 旧 File Owner | 另一主机仍运行 7099bc2，协议 /internal/files/v1 | 是另一代文件服务实例，不能冒充公共 Media 域名的现行实现，也不能因旧而直接删掉 |
| 独立 media-gateway 仓 | 本地 8cdf707，另一套供应网关/历史三桶设计 | 不能用它解释现在 new-api Media 的统一素材链路 |
| Runtime | 本地主线 9ff79e6，仍有旧 FileReferenceClient 与旧 Platform 合同快照 | 可借鉴可靠执行机制；不是新 Creative/Drama 必经依赖，也不是最新素材 SDK |
| 统一运营后台 | PLAT-02-037/038/039 为 Proposed，工作包 progress=todo，明确当前只讨论需求 | 已有 Platform Admin 和分产品商业接口；“跨平台统一运营工作台”尚不能视为已实现 |
证据：源版本清单、本轮线上只读证据、Creative 交接、运营工作包。
特别说明：本轮曾按容器名、随后按镜像 label 推断旧版本，进一步检查制品后纠正了判断。Platform /new-api 的 SHA-256 为 4d4068f5dd49e4c84344964cc741a42d923b27b68bd103a05abeb08377b10834，含新恢复合同；对恢复路由的无凭据 GET 返回 401 PLATFORM_PRODUCT_REQUIRED，不存在的对照路由返回 SPA HTML。因此，“线上没有文本恢复路由”不是本报告结论；“运行制品无法由现有版本标识准确复现”才是已证实的问题。 路由存在也不代表已验收授权后的原单恢复。
2. 当前真实拓扑：统一了一部分，另一些又被产品重新实现
这张图不是说 Creative 已经在生产双扣费，也不是说所有历史任务都走同一条链。Creative 当前是待接入底座；旧 Studio 按具体请求/冻结归属使用直接执行或 Runtime；新 Drama 走直接 Platform，存储则回到产品本地。Media 连线代表当前配置目标与已发现部署实例，域名至实例的精确映射尚未独立核验。各个系统都能在自己的局部方案中成立，但组合起来没有一套一致的消费规则。
3. 登录和鉴权：需要共用的不是一个 Token，而是清晰的授权层次
| 层次 | 当前机制 | 证明什么 | 不能代替什么 |
|---|---|---|---|
| 用户身份 | Platform 会话 Cookie、SID、会话/账号版本 | 当前是谁，会话是否仍有效 | 产品项目权限、员工运营权限 |
| 产品服务身份 | X-Platform-Product-Key | 哪个注册产品服务、允许调用哪些动作 | 任意指定用户、任意扣费 |
| 后台执行授权 | exa_…，绑定用户、产品、服务 Key、task reference | 某次已授权任务可以继续执行/查询 | 登录态、项目 owner、请求已经成功、任意素材管理权 |
| 素材后台授权 | mat1 或明确允许的 EXA 路径 | 材料操作的受托范围 | 模型调用、钱包操作 |
| 员工/产品角色 | Platform role grants / actions | 可以执行哪些管理动作 | 目标对象必然属于该产品或团队 |
| 业务对象权限 | 产品 owner/member/project/version 规则 | 可以读写哪个项目、分镜、画布、作品 | 全局身份和资金权威 |
Platform /identity 是有效会话和角色信息的查询，不是“授予产品 owner”的接口。Drama 在身份成功后统一映射 RoleOwner，同时仍按对象 ownerId 校验，所以不能据此报告“任何账号能改所有项目”。准确说法是：当前 Drama 使用个人所有者模型，团队成员、产品准入、运营动作授权尚未形成完整接线。Platform identity、Drama actor、Drama 对象边界。
Creative 当前的 open_ai_canvas_session、本地密码/用户、管理员角色及积分是上游实现，尚未替换。仅嵌入 Platform 登录页面，再继续让本地 Session/Role 决定权限，会产生退出、封禁和运营权限不一致。应保留产品资料和平台 subject 映射，替换身份权威；不能只改登录 UI。Creative auth、本地用户模型。
建议公共客户端明确区分 SessionRequest、ExecutionRequest、MaterialRequest、OperatorRequest。名称是建议，不是现有 API 名。每种模式固定允许的凭据、Origin、错误和响应处理；禁止一个通用 fetch 自动转发所有 Cookie/Authorization/内部 Key。产品 Key 不进入浏览器，后台不长期保存用户 Cookie。
退出与后台生成也要分开：EXA 允许已授权原任务在满足平台约束时恢复，不能以“浏览器已退出”推断上游取消或退款；mat1 绑定原会话版本，失效后不能继续当有效材料写权限。SDK 应保留这些差异，而不是统一成“token 过期就刷新并重试”。EXA 校验、材料授权。
4. 内部请求：重复最大的部分其实是故障语义
当前 TS、Python、Go 都有自己的 Platform 客户端；它们分别实现 Cookie 选择、产品头、EXA、Origin、错误信封、原生模型参数、任务 ID、下载和恢复。HTTP 请求代码不长，但每次演进都要求多个产品同步理解同一协议。
| 入口/产品 | 现状 | 架构后果 |
|---|---|---|
| 旧 Studio 直接文本 | main 中先用稳定原 call ID 查询 oceanway.text-request.v1，再单次 POST；丢响应只 GET 原请求 | 已有值得复用的恢复消费方式；运行制品中也观察到该合同 |
| Commerce 文本 | 普通 relay POST，出错 unknown/failed；重启超时落失败，缺该 GET 恢复路径 | 上游成功但产品未存结果的场景，产品没有自动找回出口；不是已经证实重复扣费 |
| Drama 媒体 | 发送前持久 attempt，发送后保存 x-task-id，不自动重发 unknown | 保护了不重复派发，但丢首个 task ID 时，现有代码无法按原请求身份自动定位 |
| Runtime SDK | 仍固定较早 Platform 合同，submit 未含新 TextRequestID，旧 originals version | “使用公共 SDK”本身不能保证最新；SDK 必须独立发布和被消费者明确锁定 |
| Creative | 仍有自己的渠道、供应商派发/轮询和本地计费 | 不能仅把 BaseURL 改成 Platform，必须替换执行/账务适配边界 |
证据：Studio 原文本恢复、Commerce 文本、Drama worker、Runtime client。
应统一的是这条可靠链：产品保存意图和稳定请求身份 → 当前用户授权 → 冻结模型/参数/引用 → 单次派发 → 按原身份查询 → 记录执行与账务事实 → 绑定同一产物 → 产品按目标版本采纳。
这里至少有三组独立状态：供应执行、费用/权益结算、产品结果保存。用户可以统一看到“处理中”，后台必须能分辨“上游还没完成”“上游完成但归档失败”“原件已就绪但画布回填冲突”。一个 status=failed 不能覆盖三种事实。
公共 SDK 不应对收费 POST 自动重试，不应把网络异常当作失败退款，也不能把 EXA 幂等签发当作供应商执行幂等。原请求定位能力必须由 Platform 服务提供并验收；没有供应原结果证据时，任何客户端都不能补造结果。业务 command ID、call ID、attempt ID、Platform task/operation ID、供应 task ID、trace ID 的关联应一致，不能用 trace ID 代替业务去重身份。
Drama 的收尾还有具体缺口：rejected 分支在可重试数据库事务内调用 release 网络操作；部分终态 release 忽略错误且没有持久重试；取消停的是本地等待，原上游结果未继续收敛。这些应在产品事务外通过持久 outbox 处理，而不是给所有网络请求增加“重试三次”。事务内 release、终态处理。
5. 桶存储：目标应是统一文件权威，而非给每个平台一份桶配置
当前 Media 统一素材实现已经有账号隔离、同账号内容去重、容量预留、原件归档、asset/version/file 身份、pending/active binding、读租约和删除 outbox。Platform 根据身份及订阅签发材料请求；产品保存“业务对象引用了哪个版本”。这套能力比 S3 上传 SDK 更接近你真正需要的公共模块。
当前新链的控制面： 用户/产品 → Platform materials → Media assets。Platform 决定真实账号和容量权益，Media 执行素材与配额操作。普通浏览器、Creative、Drama 不应各自持有同一桶长期密钥。
数据面需要按实际版本理解： 上传当前仍经过产品/Platform/Media 的代理路径；新 Media 部署标签 9220708 对应读取实现已改为约 24 小时的 Media 授权引用 URL，由 Media 支持 GET/HEAD/Range 并转流桶内容。它不是旧文档描述的“统一十分钟 TOS 直签下载”。签名 URL 始终是临时读取能力，不是业务文件 ID。后续优化直传/CDN，应保留统一封存、配额和引用权威，而不是让产品绕开 Media。部署证据、Media 分析及固定提交差异。
| 文件类别 | 目前状态 | 建议归属 |
|---|---|---|
| 当前统一素材原件 | Media 实例使用 oceanway-media-assets-cn | Media 唯一写入/引用/删除权威 |
| 旧 File Owner 原件及历史 claims | 旧实例与旧 SDK 仍存在 | 原任务/原引用按原 Writer 维护，不能直接换接口或清理 |
| Drama 生成、上传 | 下载后写本地 DRAMA_MEDIA_ROOT，产品 PG 保存文件元数据 | 接入 Media 新 assets；产品只保留业务绑定，逐类处理现有本地文件 |
| Creative 原件 | 上游 Resource 仍支持 local/自配 OSS，存 bucket/objectKey | 新接入时替换为中央稳定引用；保留临时处理空间 |
| ZIP、转码、缩略图等 | Drama 当前本地派生 | 是新派生产物，可新增文件；要有来源关系和独立生命周期 |
| 浏览器未同步 Blob/草稿 | 尚未完成上传的编辑内容 | 可按账号/产品/项目隔离保存，不冒充云端已保存 |
Drama 本地存储是重制规划明确采用的方案，因此本报告称其与统一素材方向分叉，不把它写成未经授权的违规。六镜成功验收是视频链路，也不能倒推它违反了早先只覆盖特定图片的历史合同。问题在于继续沿这条模式扩展，会重新承担备份、容量、跨产品素材、删除保护、迁移及流量成本。Drama 原件保存、重制存储规划。
产品绑定推荐遵循已有协议：先创建 pending binding 保护原件 → 产品本地事务保存业务关联及 outbox → confirm binding → 删除业务引用时持久 release → Media 判断所有引用、读租约和归档状态后执行物删。9220708 同时把读取保护租约调整为 24 小时，因此即使解除最后业务引用，也不等于立即物理删除；运营界面需要区分业务移除、待回收和物删完成。删除一个画布节点不等于删除原件；共用账号素材也不等于共用全部项目权限。
接入 Drama 不能只改 product 名：Platform 的项目快照写入和 Media 的项目路径验证仍只覆盖 Studio/Commerce；新 Creative 路由若不同于旧 /canvas/{id}，也需要明确修订项目投影契约。Platform 限制、Media 项目验证。
本轮核实了部署实例的桶配置，没有进入云端查询 IAM、桶版本化、TTL、加密或对象清单。上述代码能力不代表这些云配置已经逐项通过验收；历史“七桶清单”也不能直接当今日实际资产清单。
6. 运营后台：统一工作入口，保留单一业务权威
统一运营后台需要能管理各产品，但没有必要变成一个直接访问所有数据库的超级服务。
| 管理对象 | 唯一业务权威 | 统一后台如何操作 |
|---|---|---|
| 账号、会话、员工授权、产品服务身份 | Platform | 当前员工会话 + 身份管理动作 |
| 商品、价格、订阅、订单、资金、权益及奖励 | Platform | 原对象版本、动作权限、原单及审计回执 |
| 模型销售发布、产品可用性、价格 | Platform；供应事实来自 Media/上游 | 显示有效发布版本及供给就绪状态 |
| 原件、容量使用、引用、物理删除 | Media；容量待遇来自 Platform | 受托管理 API，不能直接删桶对象 |
| Studio 作品审核、提示词、公告、画布业务 | Creative/Studio 产品域 | 调产品管理 API，产品检查对象与版本 |
| Drama 项目、剧集、分镜、候选、交付 | Drama 产品域 | 调 Drama 管理 API，保留其领域不变量 |
| 全域经营与故障视图 | 中央只读投影或受权聚合 | 原事件可追踪；重试/补单仍回到权威服务 |
已有可复用基础不能忽略：Platform 商业订阅接口已经支持 product scope，既检查员工的商业动作，也检查 owner_product 与跨域权益。应扩展这种方式，而不是从零设计第二套管理员系统。商业 scope 授权、商品写入范围。
但不能据此认定所有管理 API 已产品隔离。现有全局 operations 查询通过平台级 operations:read 授权，product 是可选查询条件；它服务于有全局权限的管理员，是合理现状，却不能直接给“仅 Drama 运营”使用。前端锁定 product 筛选不构成服务端权限。需要让服务端从员工授权计算允许产品范围，再与查询相交；单对象详情、导出、批量操作也须使用同一范围。授权逻辑、全局 operations 查询。
员工操作契约至少需要操作者、产品范围、动作、目标对象、预期版本、命令身份、原因及审计关联。它们是目标语义，不声称当前所有 API 已有这些字段。对产品 API 的员工委托方式需要正式确定；不能把现有产品 Key 当管理员授权，也不能让后台透传 root 身份代替员工。
Creative 自带 /admin 含用户、渠道、支付、积分、存储、登录策略等。中央接入时应按权威逐项关闭/替换其处理器和后台路径，只隐藏菜单不够；提示词、作品审核等产品内容规则则可以继续复用。Creative admin 路由。
7. 一个已经具体冲突的公共规则：存储权益
当前 Platform 代码是 20 GiB 基础容量 + 生效个人订阅的额外 GiB 累加，排除团队付款订阅对个人容量的影响。新运营 PRD 的已确认目标是 免费默认 1 GB、订阅可配置容量；“总目标取最大值”、GB/GiB 和团队容量池细则仍待定。这不是换一个默认值就完成的改造。当前算法、新 PRD、待定规则。
应由 Platform 唯一计算版本化容量待遇，Media 唯一记录 used/reserved 和执行准入；产品只展示同一结果。必须明确容量是总额还是增量、是否叠加、属于个人还是团队、到期如何处理、存量超额允许哪些操作。不能让运营后台、Drama、Creative、Media 各自算一遍，更不能把新默认上线自动变成删除旧文件。
同理，模型参数也应以 Platform 发布的有效 schema/variant 为准，产品只加入自己的业务约束。已有 10/26 的专门模型链路审计可作为历史问题清单，不能未经复验把其中每一项继续当今日线上故障：《模型与媒体参数复盘》（2026-10-26，本机历史材料，未纳入本次共享证据集）。
8. 应抽哪些模块，放在哪里
建议按提供方发布契约及客户端，不恢复一个包含全部 DTO、业务状态和部署要求的大型 contracts 仓，也不复制 Platform 内部 new-api 数据结构给产品。
| 公共能力 | 推荐形态/Owner | 第一批内容 | 产品保留什么 |
|---|---|---|---|
| 身份与内部请求 | Platform 发布 Go/TS 薄 SDK；Python 按 Commerce 消费范围实现 | principal、Cookie/Origin 边界、产品凭据、标准错误、trace、凭据脱敏 | 项目/团队/作品对象 ACL |
| 执行协议 | Platform API + SDK | EXA、稳定请求身份、文本原单恢复、媒体 task/artifact、停止/释放区别 | Task/Attempt 的业务意图、调度与候选采纳 |
| 模型能力 | Platform 契约 + SDK 纯校验/转换 | 发布 revision、variant、defaults、原生参数及引用角色 | 产品模型选择交互和业务校验 |
| 统一素材 | Media 提供 contracts，经 Platform materials 的资产客户端 | upload intent、稳定引用、pending/confirm/release、项目投影、下载/容量 | 何时引用/解绑、哪个版本被采用 |
| 运营权限和审计 | Platform 权限契约 + 产品管理适配器 | operator、scope/action/resource、版本/命令校验、审计引用 | 实际领域命令和事务 |
| 可靠性基础 | 先共用规范/fixtures；确有两个消费者后抽小库 | CAS、outbox、租约/围栏、明确不可自动重发的状态 | 不共享业务表，不统一所有工作流 |
| 登录/素材/模型 UI | 后端契约稳定后再抽 React 组件 | 登录状态、素材选择、schema 驱动参数控件 | 画布、分镜、编辑器和导航 |
可以在 Platform 提供方仓内发布独立 sdk/go、sdk/typescript 等包，在 Media 提供资产协议，包名和目录留实施时定。Go SDK 应成为 Creative 与 Drama 都可消费的普通模块，不 import Platform 的数据库/内部 handler，也不要求启动 Runtime。旧 Studio 和 Commerce 用同一套协议 fixture 检验自己的适配器，随后按需要迁移。协议生成解决字段漂移，手写的小适配层解决 HTTP 信封、错误、流式处理及恢复语义；单靠生成 client 不足以解决可靠性。
不建议现在共享： Drama 项目/分集/分镜、Creative 画布/对话、候选/采用规则、各产品所有表、全部 worker、供应商轮询或第二份钱包。素材文件能共用，业务数据不能因此全域可见；任务机制能共用，所有任务不需要同一个状态枚举。
9. Runtime 应重新定位，而不是继续扩大或一刀切删除
历史设计把 Runtime 同时当作通用执行、Agent、文件生命周期和结果交付层；后来 ADR-0026 已明确文件生命周期应退出 Runtime。当前 SDK 仍有旧文件协议，新 Creative 计划用自身 Go Task/Pi，新 Drama 已不依赖 Runtime。继续要求所有入口经过 Runtime，会与重制实际方向冲突。ADR-0026。
建议按任务性质决定：直接文本/图片/视频经共享 SDK 调 Platform；产品确定性流程由产品工作流推进；Agent 多步骤规划由已选择的 Agent 引擎负责，同样消费 Platform/Media 公共能力。是否继续采用既有 Runtime 是每类 Agent 的实施决策，不应成为登录、下载、普通素材操作的强制依赖。
旧 Runtime 内的在途任务、原结果与旧 file claims 需要维护各自原执行归属。新 Creative Task/Pi 替换旧 Runtime 时，不复制未知任务为新任务、不自动重派、不因新 SDK 建好就停止旧恢复器。公共能力独立出来后，Runtime 自己也是它的消费者。
10. 深层原因：为什么开发会不断偏离实际
- 当前决策分散。 全局架构、仓库 AGENTS 的日期补丁、交接包、产品重制计划各保存不同阶段的事实。比如总体架构仍描述 Runtime 资产权威，新 ADR 已收紧；新版运营 PRD 还写 Drama 暂缓，Drama 重制却已有正式发布。普通开发容易选到错误入口。旧总体架构、运营范围旧描述。
- 重制按仓库优化，没有同步重审系统边界。 Drama 去掉 Runtime 时连同文件管理改为本地；Creative 为保留交互引入完整上游账号/支付/渠道系统。重制完成一个页面或一条六镜流程，不能证明中央能力边界已经一致。
- SDK 不归最新协议生命周期管理。 恢复和素材接口更新在服务端及某个产品落地，其他语言实现与 Runtime 包没有一起演进。各产品都“能调 Platform”，实际故障语义仍不同。
- 部署没有可靠的一览表。 容器名、镜像 label、实际二进制可以对应不同阶段；同一主机并存旧 Console、File Owner、Runtime 和新应用。本轮甚至观察到一个 Runtime 实例重启中、另一个实例健康，不能只凭服务名判断用户依赖哪一个。
- 局部成功被扩大为系统完成。 模型成功、原件保存、产品采用、权限隔离、运营可追踪、重启恢复应各有证据；六镜 ZIP 成功不能代验参考输入、团队、长剧容量或原单失联。
纠偏需要一份简洁的“现行架构基线 + 生产能力矩阵”，而非继续追加多份互相覆盖的文档。每个能力记录提供方、权威、协议版本、客户端版本、部署制品摘要、启用范围、验收和历史 Writer。Accepted ADR 的改变通过新 ADR 明确替代，旧材料保留历史日期并退出默认入口。
11. 建议实施顺序及完成标准
| 顺序 | 具体交付 | 为什么先做 | 必须看到的完成证据 |
|---|---|---|---|
| 0：收敛当前基线 | 现行拓扑、各产品能力/部署矩阵、新旧 Writer 清单；修复制品来源记录 | 否则后续会把错误版本抽成公共模块 | SHA/digest/合同/实际端点对应；未核实项显式保留 |
| 1：公共接入最小集 | Platform Go SDK + 固定 contracts/fixtures，覆盖身份、目录、EXA、原单读取 | Creative 和 Drama 同为 Go，最直接减少两份接线 | 两个最小宿主消费同包，跨账号拒绝、错误语义一致，收费 POST 不自动重发 |
| 2：一个真实纵向闭环 | Creative 中央登录→直接文本→原请求恢复→业务回填；Drama 原单失联定位与收尾 | 先证明可靠接入，再扩展全产品交互 | 提交前后断连、重启、原响应丢失、保存失败和重复命令均回同一请求 |
| 3：统一素材 | 新 assets 客户端；Drama/Creative 项目投影；生成、上传、导出逐类接入 | 存储分叉越晚处理，迁移与配额债越大 | 同原件多引用不重复写/计容量；引用删除保护；旧结果不覆盖新编辑 |
| 4：运营权限闭环 | 在现有 Admin 能力上形成运营工作台，产品 scoped API、审计与事件投影 | 后台入口统一必须建立在真实权限之上 | 仅某产品运营不能读/改其他产品；财务权限独立；操作可定位原对象和原单 |
| 5：商业配置联动 | 1 GB 新政策、订阅容量与团队池规则定稿并落权威计算 | 它是商业规则变化，不是 SDK 常量修改 | 商品发布→交付→容量/额度生效→到期/售后，原单快照和存量处理明确 |
| 6：整理剩余编排/性能 | 旧 Runtime 在途收口、Creative Pi 接入、Drama 查询/并发/流式 I/O | 避免为共享而先造庞大框架 | 活跃 Writer 可定位，恢复与派发不互相饿死，长剧/大文件按真实目标验证 |
顺序表示依赖优先级，不是工期承诺；产品内容功能可并行，但新增登录、钱包、供应轮询、桶原件权威应停止各自扩张。现有未提交工作树要先识别归属，避免另起一份相同授权 Store。
Drama 有明确的容量风险可随相关改造处理：4 个槽混跑派发与恢复；有任务时每两秒全量 bootstrap+目录；单 JSONB 实体表缺 owner/status/task 热点索引；媒体与 ZIP 全量内存读取。Commerce 也有最大 512 MiB 上传全量缓冲。这些是源码证实的放大路径，本轮没有压测，不宣称已经发生内存或性能事故。优先改定向查询、增量任务读取、流式传输和有边界调度，不先引入新缓存/消息中间件掩盖它们。Drama 加载、轮询、Commerce 上传。
12. 需要定稿的少数架构决策
- 新 Creative 和 Drama 是否维持独立产品服务：本报告按现状建议保持独立，公共 SDK/服务共用；Creative 早期“三产品同工程”计划需明确保留还是被独立 Drama 替代。
- 新产品统一采用现有 Media assets，还是继续让 Drama 本地媒体作为长期权威：建议前者；当前本地文件的处理应按实存数据和用户承诺制定，不把历史“可清测试数据”授权泛化到今天。
- Agent 执行由既有 Runtime 还是 Creative Task/Pi 承接：可以分阶段共存，但同一任务只有一个执行 Owner；公共身份/执行/素材客户端独立于二者。
- 员工跨产品运营的授权与数据范围：复用 Platform 角色体系，补产品与对象范围的服务端强制校验及委托契约。
- 新存储权益的单位、叠加和团队归属：按新运营需求定稿；不能由每个接入产品自行填默认值。
这些决策不阻碍先整理版本矩阵、规范接口和做客户端最小闭环；但应在跨产品存储迁移与后台数据写入实施前落定。
附：证据与未验证边界
- Studio 重制、旧 Studio 与 Commerce 逐文件审计
- Drama 重制逐文件审计
- Platform、Media 与 Runtime 逐文件审计
- 本地源码/工作树基线
- 运行制品与只读路由证据
已完成：跨仓源码与关键调用链审计、分工复核、关键提交差异、线上制品/进程元数据和无凭据路由核查。未完成：带身份的端到端权限/恢复验证、付费模型/支付验证、云桶 IAM/TTL/版本化检查、负载测试、全部域名反代映射。以上建议不是已实现或已上线的声明。