MiniMax H3 Face Refine Window Studio Commit / 人工决策提交 (Advanced)

In the Studio (serial) Face Refine route, reviewing a candidate is not the same as deciding on it - and MiniMaxH3FaceRefineWindowStudioCommitT8Advanced exists to keep those two things honest. It's the per-window decision node: it re-validates the current candidate against the source, then atomically records an explicit accept or reject into the project manifest. Until that record is written, nothing about the current window counts. After it's written, the window is settled - accepted overlays are immutable and never overwrite your source media.

How it differs from the single-window review

If you've used MiniMaxH3FaceRefineManualReviewT8Advanced, the inputs will look familiar - same base_frames, candidate_window_frames, changed_mask, window_mapping, decision, confirm_accept, edge_fade_frames. The Commit node adds the Studio scaffolding: a window_plan and studio_id to locate the manifest, plus two wired inputs from the Studio Start node, job_id and auto_continue.

The decision semantics are identical to manual review - preview_only (default, changes nothing), reject (original pixels stand), accept_selected (only eligible after confirm_accept, and only inside the planned repair frames of the changed_mask). What's new is the commit boundary. The node re-checks the candidate is still valid against the current source-bound window, then writes the outcome to disk as one atomic record. Only after that durable boundary may the next window prompt be queued - which is why the description calls it a gate rather than a button.

The auto_continue wiring

auto_continue is force-input, meaning it comes from the Studio Start node's output, not something you click. Here's the rule, enforced with a ValueError if you get it wrong: auto-continue requires an explicit accept_selected or reject decision. Trying to auto-continue from preview_only is an error - run review first, look at the frames, then commit with a real decision. On a valid commit with auto-continue on, the node tells the background controller the segment is done so the next unresolved window can queue. If that background transition itself fails, the code's stance is deliberate: the window decision is already durable, so it does not retry or undo - a fresh controller run resumes from the next manifest entry. Your yes is never silently un-said.

Outputs

• review_frames - side-by-side source/candidate, for the actual human judgment.
• current_result_frames - the timeline with this window's outcome applied (bit-identical source on reject or preview).
• accepted_change_mask / rejected_change_mask - what changed and where.
• committed (boolean) - did this run write a durable decision?
• manifest_path - where the project state lives.
• resolved_window_count and complete - complete=true means all windows are settled and it's time for Studio Compose.
• background_state_json / report_json - controller and validation diagnostics.

Where people get burned

The classic sequence of pain: set decision to accept_selected, forget confirm_accept, and wonder why committed never goes true. It's the same two-step guard as the manual node, by design. Second: accepted windows can't be rolled back or rerun - if you realize later the face is actually wrong, that window is locked in and you handle it as a new repair range, not an undo. Third: remember the whole Studio route is Advanced EXP. A fixed 16GB test matrix and one real bad-face sample passed, but multi-subject human blind testing is still running - so commit like a careful human, not a batch job, and keep the full original audio for the final save (window audio is never the soundtrack).

Example graph: 2026-09-05_H3_Face_Refine_Window_Studio_Serial_Advanced_EXP.json under examples/workflows/06-face-refine. Install is the pack standard: ComfyUI Manager (search "MiniMax H3 Audio T8") or clone into custom_nodes and restart.