文件可读，但分给了错误镜头。
更正文件到 shotId 的绑定并核对内部身份，仅重算哈希不能修复剪辑错配。
实操配方
分镜清单绑定：镜头 ID、文件、哈希与顺序
组装前保持 shotId、准确文件名、SHA-256 与剪辑顺序一致。这些检查证明文件身份和顺序，不证明镜头视觉连续或生成画质。
附实际运行过的本地样例、脚本和回执；不代表已调用视频生成服务。
01准备环境与输入
- 准备 Node.js，只使用内置文件与加密模块。三份原创一秒分镜规格为 opening、hinge、hold；不接触媒体提供商。
- 同时查看 shot-manifest.json 和 shots/ 内的 JSON。每份文件除了外部清单绑定，内部还保留自己的 shotId。
- 选择新目录，order 必须为1至3且与行位置一致。basename 必须为本地唯一文件名，不接受父目录或重复文件。
02执行配方
运行命令
node run-recipe.mjs --out ./my-run
让镜头身份独立于文件名
夹具写出三份不同分镜 JSON，以及包含 shotId、order、file、sha256 的清单。剪辑身份为 opening/hinge/hold，文件名为 shot-01.json 至 shot-03.json；改名和改身份因此是两个需要审查的决定。
优先核对顺序与唯一性
先核对准确行数、唯一镜头 ID、连续 order 和安全且唯一的文件名。文件能打开也不能放过重复 ID；清单乱序时直接失败，不暗中排序成另一种剪辑顺序。
同时验证字节和内部镜头身份
要求文件存在、SHA-256 匹配，内部 shotId 也等于清单。脚本先测试交换文件名但保留旧哈希，再单独测试把哈希也改成错镜头文件的哈希；第二种仍会因身份不匹配失败。
保留错误绑定供复核
检查八项断言与六条预期拒绝。缺文件、重复 ID、错顺序、错文件、内部身份不符和重复文件均有具体错误原因；动作和连续性应另行看视频验收。
03检查结果
- 合法三行清单按原顺序通过，没有自动重排行。
- opening、hinge、hold 确为三个唯一镜头身份。
- 重复镜头 ID 与乱序行分别失败。
- 交换文件名会因原 SHA-256 绑定不符而失败。
- 缺失文件与重复文件名均被拒绝。
- 即使重绑错文件的哈希，内部 shotId 不符仍被拒绝；八项检查通过。
04排错与交付
两行使用同一镜头 ID。
把错误记录及其文件内容改为真正的独立 shotId，再只重算该文件哈希。
下载完成后镜头顺序变了。
把 manifest order 当作交付约定，拒绝与行位置不一致，不改用文件名字母排序。
这份清单让三份分镜规格可以成套复核，不检查视频本身、不保证叙事含义，也没有证明任何视频模型运行。