MiniMax H3 Selective Repair Bind / 修复绑定 (Advanced)
Lock a repair segment to an immutable manifest revision
- repair_plan
- repair_execution
- compiled_prompt
- negative_prompt
- length
- seed
- segment_index
- timeline_start_seconds
- parent_candidate_id
- base_manifest_revision
- report_json
Between "I want to redo segment 3" and "here's the redo," there's a step that keeps a long-video production from falling apart: pinning that intent to a specific, immutable version of the accepted timeline. That's this node. It binds one item from a repair plan to an accepted-manifest revision and exposes the exact generation inputs for that segment - so your graph regenerates against the same baseline it was planned against, not against whatever the timeline happens to be this week.
The name is the mechanism: bind. It takes a repair_plan and a chain_id (your long-video chain, e.g. my_h3_long_video), picks the entry at repair_index, and produces a H3_T8_REPAIR_EXECUTION object that is permanently tied to base_manifest_revision - an immutable revision of the accepted manifest. Everything downstream (Stage → Accept → Compose) inherits that binding, so a candidate can be verified against the exact frames, samples, and timeline it was designed for.
What it deliberately doesn't do: load models, queue sampling, or modify the accepted chain in any way. It's a pure planning/contract node. If you've seen the pack's other "contract compiler" nodes, this is the same philosophy - bind first, execute later, verify always.
Inputs and the outputs that matter
repair_plan- fromMiniMaxH3SelectiveSegmentRepairT8Advanced.chain_id- which production chain this belongs to.repair_index- which plan item.
Outputs: repair_execution (the typed handle for Stage), plus the exact inputs the generation graph needs - compiled_prompt, negative_prompt, length, seed, segment_index, timeline_start_seconds, parent_candidate_id, base_manifest_revision - and report_json.
The set worth wiring onward: repair_execution into SelectiveRepairStage, and compiled_prompt/negative_prompt/seed/length into your sampler so the redo uses precisely the bound inputs.
Installing
In the T8mars MiniMax H3 Audio T8 pack:
cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8
or ComfyUI Manager → "MiniMax H3 Audio T8", restart. No pip deps; nothing loads.
The take
If you're doing one-off short clips, this is overkill - you don't need a manifest-revision contract when there's one take. The moment you're maintaining a multi-segment long-video chain across days, where the accepted cut keeps moving while you generate fixes, this node is what keeps your repair honest. The base_manifest_revision output is the thing to read: if the manifest has moved since you planned, the binding makes that visible instead of letting a candidate silently target the wrong baseline. Boring, and exactly the kind of boring that saves you from re-rendering a whole timeline.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| repair_plan | H3_T8_REPAIR_PLAN | — | |
| chain_id | STRING | my_h3_long_video | — |
| repair_index | INT | 00–100000 | — |
Outputs (10)
| Name | Type | Description |
|---|---|---|
| repair_execution | H3_T8_REPAIR_EXECUTION | — |
| compiled_prompt | STRING | — |
| negative_prompt | STRING | — |
| length | INT | — |
| seed | INT | — |
| segment_index | INT | — |
| timeline_start_seconds | FLOAT | — |
| parent_candidate_id | STRING | — |
| base_manifest_revision | INT | — |
| report_json | STRING | — |