MiniMax H3 Selective Repair Accept / 修复接受 (Advanced)

The Selective Repair chain has a strict rule: nothing a machine generated gets committed to the final cut automatically. This node is where a human says yes. It takes a verified, staged repair candidate and commits it into an atomic repair overlay - and the moment you understand what "atomic overlay" means, you'll understand why this whole system is built the way it is.

staged_repair is the H3_T8_REPAIR_STAGED handle produced by MiniMaxH3SelectiveRepairStageT8Advanced, which has already verified the candidate against the bound frame/sample/timeline and base-manifest contract. This Accept node then does one thing with it: writes the repair into the accepted manifest (a file on disk whose path comes back as repair_manifest_path). The original accepted manifest and every original segment stay unchanged - a repair is an overlay on top of immutable base media, not a destructive edit. That's what lets the Compose node later roll back with base_rollback by simply ignoring the overlay, and it's why the README keeps saying nothing is ever deleted.

Inputs

• staged_repair - required, from the Stage node.
• accept_repair - the explicit commit flag, default false. Nothing happens until you flip it.
• replace_existing - default false, with a tooltip that should be read twice: "Only enable after reviewing a new take for a slot that already has an accepted repair overlay." If you accept a second take over an existing one without this, you get a refusal - which is correct, because silently overwriting a previously accepted repair would break the whole immutability promise.

Outputs: repair_manifest_path, accepted (boolean), and report_json. It's an output node - wire it to a display and read the confirmation.

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. The actual rendering of the overlay is the Compose node's job and needs ffmpeg on PATH; this node itself just writes a manifest.

The take

The design intent, spelled out: selection is cheap, acceptance is sacred. You can generate and stage a dozen candidates; committing one is the only step that changes your deliverable. So the workflow rhythm is: Stage a candidate → look at the actual video → run Accept with accept_repair true → Compose. If you skip the look and just flip the flag, the system can't stop you - it's an audit chain, not a babysitter - but the entire architecture is built so that a careless accept is recoverable, because the base segments were never touched. That's genuinely nice engineering, and it's the reason to prefer this chain over hacking segment swaps in by hand.