PROC-02-020 Commerce真实云桶与独立原件服务联调20261022

1. 范围

用户授权将配套原件服务部署到pic-vps的media.oceanway.tech，完成Commerce真实云桶上传、下载、生成结果保存和复用联调。本轮没有切换Platform调用，没有部署Commerce公网产品服务，没有修改Drama、旧媒体业务、旧桶或旧数据库。

本轮接通实际HTTPS File Owner与实际私有TOS。生成验收采用Commerce真实FFmpeg素材合成及生成视频再次合成，不使用存储夹具，也没有调用付费AI图片或视频供应商。前批PROC-02-019中的受控Owner浏览器证据不能替代本轮证据；本轮也不把FFmpeg合成称为付费模型生成验收。

2. 部署制品与隔离

镜像从上述精确commit的Git归档构建，校验归档摘要，并带OCI revision标签。源码仓当前已改名Oceanway-AI/temp-media-gateway，本轮没有修改旧部署命名。构建日志、镜像manifest及私有配置留在独立部署目录。

基础设施提交9132406提供deploy/media-isolated/upgrade_commerce.py。先执行只读check，再由受控入口校验镜像revision、目标Compose、端口、新桶、永久保留、独立数据库连接及停用的后台任务；备份独立数据库和env后，只用up -d --no-deps app替换新实例app。没有重启新旧PostgreSQL/Redis，也没有重载Caddy。此版本不增加schema变更。

旧app、旧PostgreSQL及旧Redis的容器ID、镜像ID、配置完整摘要和restart count在本轮前后相同；Caddy完整文件摘要相同。新旧媒体域名/api/status均返回200及success。Platform未执行任何配置写入或发布；本轮未重新读取其13条连接完整记录，不能将PROC-02-018的旧摘要冒充本轮新查询。

3. 真实云桶验收

Commerce运行于loopback，以独立临时SQLite保存业务记录；服务端使用专属File Owner凭据。验证脚本为Commerce仓的scripts/verify_file_owner.py，所有模型凭据显式置空，避免dotenv加载本机付费配置。文件上传、Owner查回执、云桶GET及结果发布均为实际网络请求。

验收包含：

1. 上传项目公开PNG，保存稳定原件证明；同命令重交保持同一素材ID，内容不一致返回409。
2. 模拟Owner成功但Commerce素材登记未完成，保留上传命令，删除一次性测试SQLite中的素材行；查询为pending，重交同一文件后经Owner已有回执恢复同一素材ID。
3. 上传真实RIFF/WAVE文件，验证MIME、长度和SHA-256；不以通用二进制响应冒充音频。
4. 真实FFmpeg从云原件读取图片、音频并合成MP4；完成原件保存后才发布任务成功和结果素材ID。
5. 直接选择第一条生成视频的稳定素材ID，再次从云桶读取并完成第二次真实视频合成；没有将原结果下载到正式本地素材目录再重新导入。
6. 云桶签名GET、206 Range、Commerce附件下载与Range均校验内容；匿名对象读取返回403。
7. 重启本机Commerce进程，上传命令、素材、任务结果仍恢复相同ID；临时处理目录已清空，无正式assets/或jobs/媒体目录，SQLite没有token、access grant或签名URL。

恢复边界：Commerce的pending登记仍需客户端向Commerce重交文件，Owner先查已有不可变回执，避免再次向云桶传原件。不能宣称浏览器到Commerce这一段也已消除重传。不可将本轮重启已完成记录验收扩大为生成中断后的跨进程原始响应恢复。

4. 云桶跨域与画布缺陷

新正式桶原本没有CORS规则。实际浏览器中，普通图片预览能显示，但crossOrigin=anonymous画布图片通过产品307跳转云桶时出现MissingAllowOriginHeader，画布为空白。仅做后端下载测试无法发现这个问题。

只在新正式桶增加一条读取规则：来源为http://127.0.0.1:4175、http://localhost:4175和https://commerce.ocean-way.top；方法仅GET/HEAD；允许Range，暴露ETag、Content-Length、Content-Type、Content-Range及Accept-Ranges；缓存3600秒并启用Vary: Origin。未开PUT/POST/DELETE、匿名权限或通配来源，未改任何旧桶、临时桶或生命周期。

真实HTTP验证：三个白名单来源的Range响应206，返回各自准确的Allow-Origin和Vary；未列入来源的签名请求没有跨域授权；匿名读取仍403。服务TOS程序身份没有增加桶管理权限，配置通过已有控制台会话完成。

Commerce提交f75ac6f修复画布读取：当前主体先向Commerce取得临时读取地址JSON，画布再直接加载该地址，不再依赖跨域重定向。读取响应no-store；地址只在组件内存中使用，图层/项目仍保存稳定素材ID。生成图片结果先解析其原件元数据再授权，未增加媒体Blob库；切换图层或卸载时中止旧请求，防止旧图片覆盖新图层。

5. 浏览器与重启验收

扩展权限更新后，以Chrome真实文件选择器上传公开测试PNG，新素材进入实际云桶。1440×900画布显示完整杯子图片，刷新恢复同一editor及云原件；实际导出PNG已经下载并解码，不再是空白画布。文件为650×650、426127字节，SHA-256为3c992342a9b807a709164c673b9fec3a07c82dca52e9a70497e4b290c42d8630。这是云图可导出的证据，不扩大为设计尺寸与输出像素一致的验收。390×844下实际图片naturalWidth为1024，页面scrollWidth和clientWidth均390。

本轮内置浏览器恢复时发生CDP focus emulation超时，最终浏览器验收由用户已开启文件权限的Chrome扩展完成。浏览器记录中两条扩展连接消息与应用跨域缺陷分开；未将扩展消息伪报为零错误。

仅重启pic-vps独立app后，实际重新授权并下载同一图片及生成视频，SHA仍相同、读取来源头仍正确。旧app/PG/Redis及Caddy未重启或变更。本机Commerce工作树新增被Git忽略的0600开发配置，subject为commerce-local-development，与本轮commerce-cloud-validation验收素材隔离；未向Platform写凭据。

终次完整云桶脚本基于Commerce功能提交f75ac6f40f025b265709686e5e8288baa4f8beae，验证脚本SHA-256为4f092c3be6768f65060633dc983d395bcbe8b7b01ab83eb8b620647f86af339d；随后提交72a52f5保存同一脚本及浏览器记录。此前两次扩展验证分别在HTTP状态及视频任务阶段中断，未完整保留细分原因；终次重新执行全部流程通过，没有在脚本中增加生成自动重试，也不将单次完整通过当作长期稳定性或性能压测。

6. 自动检查与证据位置

本轮Commerce类型检查、前端20文件81项测试、后端177项测试及生产构建通过。新增覆盖临时读取地址的主体隔离、撤销拒绝、非HTTPS拒绝、生成结果元数据解析，以及不得把临时授权写入素材表。现有bundle大小警告及两项Python依赖警告继续单列，不计为失败。

脱敏证据目录为/tmp/ow-commerce-live-cloud-evidence/。部署侧image-manifest.json、commerce-isolation-after.json和私有升级备份保留在pic-vps独立目录。凭据只在用户私有配置目录及服务器root-only文件中保存，不进入Git、浏览器持久化或本文。

本轮未合并主分支、未切换Platform调用、未更改Drama。Commerce公网身份接入、付费模型实际生成和消费者生产切流仍属于另一次明确授权与验收范围。