Nodes/MiniMax H3 Audio T8/MiniMax H3 Selective Repair Bind / 修复绑定 (Advanced)
ComfyUI Node

MiniMax H3 Selective Repair Bind / 修复绑定 (Advanced)

Lock a repair segment to an immutable manifest revision

By T8mars·Created 20 days ago·Updated a day ago· 807
MiniMax H3 Selective Repair Bind / 修复绑定 (Advanced)
  • repair_plan
  • repair_execution
  • compiled_prompt
  • negative_prompt
  • length
  • seed
  • segment_index
  • timeline_start_seconds
  • parent_candidate_id
  • base_manifest_revision
  • report_json
chain_idmy_h3_long_video
repair_index0

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 - from MiniMaxH3SelectiveSegmentRepairT8Advanced.
  • 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.

CategoryT8/MiniMax H3/Studio/Experimental

Inputs (3)

NameTypeDefaultDescription
repair_planH3_T8_REPAIR_PLAN
chain_idSTRINGmy_h3_long_video
repair_indexINT00–100000

Outputs (10)

NameTypeDescription
repair_executionH3_T8_REPAIR_EXECUTION
compiled_promptSTRING
negative_promptSTRING
lengthINT
seedINT
segment_indexINT
timeline_start_secondsFLOAT
parent_candidate_idSTRING
base_manifest_revisionINT
report_jsonSTRING