首尾帧文件预检：尺寸、比例与角色绑定

01准备环境与输入

1. 准备 Node.js 与已有 FFmpeg；若不在 PATH，先将 FFMPEG_BIN 设为可执行文件绝对路径。本次夹具实际使用 FFmpeg 6.0。
2. 查看 binding.json 与 executed/inputs 中的原创 first.png、last.png，尺寸均为 320×180；另有 180×320 竖图专门用作错误输入。
3. 把角色名、文件 basename 与预期 SHA-256 一起保存，选择全新输出目录，避免旧清单悄悄指向已替换的文件。

02执行配方

运行命令

node run-recipe.mjs --out ./my-run

1. 固定每个角色对应哪份文件

   脚本创建两张小型原创 RGB 示意图并写出绑定清单。首尾图的字节与边缘标记各不相同。哈希来自实际文件，不通过上传次序或文件名包含 first 来猜测角色。

2. 同时核对画布与完整解码

   逐项读取 PNG 签名和 IHDR 宽高，再由 FFmpeg 完整解码为一帧 RGB。两张都必须为 320×180，并符合本任务明确选定的 16:9 画布。只有头部尺寸正确，还不能证明压缩像素能解码。

3. 实跑四种不安全绑定

   依次检查竖版尾图、交换文件名、缺少尾图及父目录路径。它们分别实际触发尺寸不匹配、哈希绑定失败、输入缺失与不安全 basename，failure-receipt.json 保留具体异常。

4. 把文件与绑定清单一起留档

   检查 execution-receipt.json 的七项通过及脚本运行前后哈希。改成自己的上传流程时，把两张 PNG 与 binding.json 成套保存；相机、主体与首尾语义仍需独立审看。

03检查结果

• 正确首尾图各完整解码为一帧 RGB。
• 两个角色都准确为 320×180，交叉相乘验证 16:9。
• 首尾图 SHA-256 不同，且分别匹配各自绑定文件。
• 180×320 的竖图替换会因尺寸不一致被拒绝。
• 把 last 文件名放入 first 但保留旧哈希，会被拒绝。
• 缺失文件与父目录路径均失败，七项检查写入回执。

04排错与交付

这份清单记录文件就绪情况，不代表已生成首尾过渡、已兼容某个接口或已保留两端视觉状态。

05下载脚本与样例

• 原创任务专用本地夹具示意图 ↓
• 完整可运行包：原创输入与真实回执 ↓
• 任务专用标准库夹具脚本 ↓
• 有界本地执行与回执辅助模块 ↓
• 英文执行与验收说明 ↓
• 英文结构化任务说明 ↓
• 中文执行与验收说明 ↓
• 中文结构化任务说明 ↓
• 实际完整通过回执 ↓
• 实际预期拒绝回执 ↓
• 命名任务检查结果 ↓
• 分发文件 SHA-256 清单 ↓
• 实跑夹具：binding.json ↓
• 实跑夹具：inputs/first.png ↓
• 实跑夹具：inputs/last.png ↓
• 实跑夹具：inputs/portrait.png ↓