debug-render

1# Debugging renders with run-to-node
2 
3When a final asset looks wrong (not when it errors), don't re-roll the whole
4graph and hope. Localize the fault. Render only as far as one stage and look
5at what that stage actually produces. The wrong-looking output is downstream of a
6*first* bad step. Find that step, fix it there, and everything after it follows.
7 
8The tool for this is `panel_run` with `to_node_id` ("run to node"), which uses
9ComfyUI's native partial execution. Only the target output node plus
10everything upstream of it renders; every other branch is skipped. That makes each
11probe fast and cheap, and the output is delivered to you automatically, same
12as any run. Don't poll.
13 
14## When to reach for this
15 
16- A final image/video is wrong: artifacts, wrong subject/pose/composition, off
17  color, soft/blurry, melted hands, wrong style.
18- A conditioner isn't "taking" (ControlNet, IPAdapter, a mask, an inpaint, a
19  LoRA) and you can't tell if the *input* to it is wrong or the *node* is wrong.
20- A multi-stage pipeline (base → refiner, txt2img → upscale, decode → post)
21  degrades, and you need to see which stage introduces the problem.
22- You only want to test one branch of a multi-output graph without paying for
23  the others.
24 
25If instead the run fails (red error, OOM, missing node, black image from a
26crash), use the troubleshooting skill. This skill is for outputs that
27*complete* but look wrong.
28 
29## The one hard rule: `to_node_id` must be an OUTPUT node
30…