预览与导出一致性：fail-closed 的构件来源

背景与问题

“预览里明明是对的，导出的 MP4 不一样。“——这是视频工具的信任杀手。象棋视频工作室里，预览跑在系统 Chrome，导出跑在随包 headless-shell：两个运行时不一致，“可重复渲染”就无从谈起。更进一步：如果发布构件本身来自一台状态不明的工作机，“导出一致”也无从证明。

约束

• 导出 worker 随应用分发，必须可离线校验来源与完整性
• 不能假设用户机器 PATH 上有 ffmpeg
• 校验必须能进 CI 自动执行，不能依赖人工抽查

方案与权衡

采用三层机制收口：

1. 构建来源身份（provenance）：打包前解析 git commit / tree / dirty 状态，dirty 工作树默认拒绝产出发布构件；强行放行会标记 releaseEligible=false，运行期 preflight 拒绝。
2. 运行时 parity：verify:parity 比较系统 Chrome 与随包 headless-shell 的渲染一致性。
3. 帧级比对：verify:frame 对同一 Composition 的参考帧与导出 MP4 帧做像素级比较。

被否掉的替代方案：

• 导出后人工抽查——不可重复，进不了 CI；
• 只信任单一运行时（全用系统浏览器导出）——用户环境不可控，发布件不可复现。

验证

三条验证命令全部纳入 pnpm check 与 CI（证据见侧栏芯片）。验证机制覆盖”构件从哪来”（provenance）、“两个运行时是否一致”（parity）、“输出帧是否等于参考帧”（frame）三层。

结果

机制全部就绪并纳入验证命令集与 CI。渲染一致率的量化数字未度量，本文不提供任何编造值。

局限与后续

参考帧集需要持续维护；Android / iOS 渲染路径尚未纳入 parity 范围——移动端发布前必须补上。