Zura · Save Motion Section

If you've queued a Wan motion section in Zura Studio and wondered why there's a Next section button instead of one big Run, this node is the answer. ZuraWanSavePreparationPart (Zura · Save Motion Section) is the shard-writing sibling of the pack's preparation cache: instead of one giant .pt for the take, it writes one bounded part per window, each with its own receipt, and refuses to write a part that isn't legitimately connected to the one before it.

Same job, different granularity

The whole-take version validates the performance and saves it in one go. This one does it per window, and everything it can't check locally it checks by provenance pin: a part is only trustworthy if it can prove which reviewed shot, source file, mask, reference and render cache it came from.

Three inputs carry that proof, and they're why this isn't a copy-paste of the other node:

• window (ZURA_WAN_WINDOW) - from ZuraWanPreparationWindow, which decodes an artist-bounded slice of the source and its mask. It carries start frame, count, total frames and raster size, and the part is validated against those numbers.
• carry_state (ZURA_WAN_POSE_CARRY) - from ZuraWanCarryPoseWindow. WanAnimate's pose detector falls back to a body-only heuristic when it can't see a full skeleton, and a window boundary is exactly where that fallback used to snap. The carry state hands the previous window's body estimate forward, so section five doesn't re-detect a different person.
• clip_details (GENJ_CLIP) - the reviewed shot's identity and timing. The part's frame count must equal the reviewed clip's total, not the window's, which is how shards stay tied to the approved take.

The rest mirrors the whole-take node: frames, mask, pose, face, one reference image, a 64-hex cache_key, scope of person or head, and the optional speech_guide_key / speech_guide_sha pair.

The adjacency rule is the point

The carry state is checked at both ends:

• The first part (start == 0) must carry the canonical empty carry. Anything else means you're resuming into the middle of a take you never started.
• Every later part must present a carry_in digest and previous-receipt digest matching the checkpoint its predecessor actually wrote.

Get it wrong and you get Wan preparation pose carry is stale or not adjacent to its predecessor. That's not pedantry - a glitch at a window join is usually a pose guide that quietly reset. The same applies to the shared pins: source, review, render-cache and footage-metadata hashes all have to agree, or you get Wan pose carry provenance does not match this preparation part.

It also refuses to overwrite. Run the same window twice and you get This Wan preparation part already exists. Use a new preparation cache key. Rather than clobber a good shard with a bad one, it makes you start a fresh cache identity - and it rolls back anything it created during a failed attempt.

Inputs and output

You set very little by hand: scope has to match the approved mask, cache_key comes from the section controls, and the three wires above must be the real ones for this window. The output is approved_part_receipt - a path to the part's JSON receipt, which the section controls read to know what's done and where the next section starts. When the last one lands, Studio swaps in ZuraWanMergePreparation to reassemble a single preparation from the shards.

That's the flow from the artist guide: queue the current section, click Next section, and once the receipts add up, Finish motion → queue the merge → Open render. Slower to babysit than one giant run, and the only version that fits in RAM on a 16 GB card.

Install

Same pack, same install:

cd ComfyUI/custom_nodes
git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
python -m pip install -r ComfyUI_zura_nodes/requirements.txt

You'll want ComfyUI-WanAnimatePreprocess for the pose nodes the windows feed, detection/vitpose-l-wholebody.onnx and detection/yolov10m.onnx under ComfyUI/models/detection/, and ffmpeg/ffprobe on PATH - these parts decode real video. The section flow adds no model downloads of its own.

Troubleshooting

The errors here are unusually specific, so treat them as instructions:

• Apply the verified Wan pose carry before saving a preparation part. - carry_state isn't wired, or isn't from a pose-carry node.
• Wan pose carry and preparation part describe different frame windows. - a carry from one window met the frames of another. Requeue the section instead of reconnecting by hand.
• Wan part does not match the reviewed full clip length. - clip_details belongs to a different take, usually because you changed the shot after opening the graph.

One behaviour worth knowing: this node re-runs every queue, deliberately (IS_CHANGED always reports changed). It writes files to disk, and ComfyUI's cache would otherwise skip it and leave you with a shard that was never rewritten.