03:00:0050% OFFClaim
MiniMax H3

Hands-on recipe

Bind shot identity, file, hash and editorial order in one manifest

Keep shotId, exact filename, SHA-256 and order consistent before assembly. These checks establish file identity and sequence, not visual continuity or the quality of generated footage.

Includes executed local fixtures, scripts and receipts. These checks do not represent a video-generation service run.

Get the practice files ↓
Original task-specific local-fixture diagram
Original shot specification JSON files, actual binding failures and a shot-to-file matrix diagram. Standard-library execution only.

01Prepare environment and inputs

  1. Use Node.js with built-in filesystem and crypto modules. The three original one-second shot specifications are opening, hinge and hold; no media provider is contacted.
  2. Read shot-manifest.json together with the JSON files in shots/. Each file carries its own shotId in addition to the external manifest binding.
  3. Choose a fresh output directory and require order values 1–3 to match row position. Basenames are local and unique; parent paths and duplicated filenames are not allowed.

02Run the recipe

Run command

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

  1. Define identities independently from filenames

    The fixture writes three distinct shot JSON files and a manifest with shotId, order, file and sha256. The editorial identity is opening/hinge/hold, while the basenames are shot-01.json through shot-03.json. This distinction lets a renamed file remain a separate reviewed decision.

  2. Validate order and uniqueness first

    Check the exact row count, unique shot IDs, sequential order values and unique safe filenames. A duplicate ID is a failure even when its bytes can be opened; a reordered manifest is not silently sorted into a different editorial sequence.

  3. Check both file bytes and internal shot identity

    Require the file to exist, its SHA-256 to match and its internal shotId to equal the manifest. The suite swaps a filename while keeping the original hash, then rebinds the hash to the wrong shot as a separate case. The second case still fails identity binding.

  4. Preserve the failed bindings for review

    Inspect eight assertions and six expected-rejection records. A missing shot, duplicate ID, wrong order, swapped filename, wrong internal identity and duplicated file each retain a concrete failure reason. Use a separate video review for action and continuity.

03Check the result

  • The valid three-row manifest passes without reordering its records.
  • opening, hinge and hold are three unique shot identities.
  • A duplicate shot ID and a reordered row are separately rejected.
  • A filename swap fails the original SHA-256 binding.
  • A missing file and a duplicate filename are rejected.
  • Even after rebinding the swapped file’s hash, its wrong internal shotId is rejected; all eight checks pass.

04Troubleshoot and deliver

A readable file is attached to the wrong shot.

Correct the file-to-shotId binding and recheck its internal identity. Regenerating a hash alone cannot repair the editorial mismatch.

Two rows use one shot ID.

Assign the intended distinct shotId to the incorrect record and its file content, then recompute only that file’s expected hash.

The sequence changes after download.

Use the manifest order values as the handoff contract and reject row-position disagreement; do not substitute alphabetical file sorting.

The manifest makes the three shot specifications reviewable as a package. It does not inspect footage, enforce narrative meaning or demonstrate any video model run.

05Download scripts and fixtures

Reference documentation