Zura · Stage Hand-off

Zura Studio breaks a project into stages - appearance, motion preparation, sampling, delivery - and the exported Graph view keeps them apart on purpose. Which means stage three needs a value that stage one produced. This node is how it gets there: up to 64 arbitrary named values packed into one wire.

If you've used rgthree's Context, you know the shape. Bundle a handful of connections into one pipe so the graph stops looking like a plate of spaghetti. This is a narrower, stricter version of it, and the strictness is what makes it usable.

Inputs and outputs

• keys - a JSON list of signal names as a string, default "[]". Something like ["footage", "character_view", "width", "height"].
• previous (optional) - another ZURA_STUDIO_SIGNALS bundle. Its contents are copied in first, so the new keys are layered on top. This is how you chain stages without re-passing everything.
• value_0 through value_63 - optional * sockets, one per position in your keys list, in order.

Output: stage_data, the ZURA_STUDIO_SIGNALS bundle itself.

Note the * on those value sockets. That's ComfyUI's wildcard type - it'll take an IMAGE, an INT, a string, a model, anything. Which is convenient, and also the reason this node is a debugging hazard: nothing here type-checks what you're carrying, so a footage key that actually holds a width integer won't blow up until three nodes later.

The node validates aggressively on the way in, though. The keys list has to be valid JSON, a list, at most 64 entries, all strings, with no duplicates. And every declared key must actually have its matching value_N connected - miss one and you get "Connect the stage signal: <name>" naming the exact thing you forgot. That's a much better failure than the alternative.

Where it fits

Studio generates these bundles when it exports a stage to Graph view: the stage's upstream objects are packed here, and downstream stage graphs read them back. It's the plumbing that lets you edit one stage's internals without the whole project becoming one unreadable graph.

For hand-built workflows it's also just a neat trick. A closed character-identity set - footage, reference view, resolution, the shot's cache key - travelling on one wire instead of four is the difference between a readable graph and a wall.

Install

Ships with the pack:

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

Manager: search Zura Nodes (publisher ZURAVFX) and restart. Nothing extra for this one - it never touches tensors, models or disk. It's pure dict-shuffling.

Common issues

"The stage hand-off contains invalid signal names." keys isn't a JSON list of unique strings. The classic is single quotes from a hand-edit, or trailing commas. It's parsed with a real JSON parser, so ['a','b'] is not valid and ["a","b"] is.

"The previous stage has no signal named …" That error comes from the read node, and it means the key you asked for was never packed upstream. Diff your keys list against the reader's key string. Case matters.

The graph got worse, not better. Almost every time this is the wildcard biting: the pipe swallowed a type error that a plain wire would have caught at connect time. Especially in a workflow you're debugging, prefer direct connections and use the bundle only where the stage really is already shipped that way.

Chained bundles lose things. With previous connected, the new values override same-named old ones and everything else passes through - so a duplicate name isn't an error, it's a silent override. Name things distinctly if a stage re-packs the same concept with a different meaning.