Debug Viewer

The Debug Viewer is the pack's honest answer to "why did my prompt come out like that?" It's a read-only inspector: you connect any intermediate state - a scene, some warnings, some errors - and it renders everything into a single report you can read on the canvas. It never modifies the data passing through, and it's an output node, so the report shows up right there in the UI. There's no deep mechanism to explain; it's a window, and that's the whole job.

Where it earns its keep: the Scene Compiler pipeline is designed to be traceable - every tag should be explainable back to the sentence it came from - but a chain of nodes hides that trace. The Debug Viewer is how you look at it. Connect the Analyzer's scene and you can eyeball the Scene JSON the model actually produced. Connect a stage's warnings and errors and you'll see why a concept got dropped or flagged, instead of staring at an unexpectedly short prompt and guessing.

Inputs and outputs

All three inputs are optional, so you can wire up exactly what you're curious about:

• scene (SCENE) - any scene data, from the Analyzer or the Validator.
• warnings (STRING) - a stage's warnings output.
• errors (STRING) - a stage's errors output.

The single output is report (STRING) - the rendered summary of whatever you connected. Hook all three in at once for the full picture; hook just one if that's all you need.

One thing it deliberately does not show: resolved tags. That's the Resolver's json output's job - the Debug Viewer covers scene and diagnostics, and the Resolver's json output covers the final compiled tags. Together they're the pack's whole debugging story.

Installing and the gotchas

cd ComfyUI/custom_nodes
git clone https://github.com/kunail0804/ComfyUI-Scene-Compiler.git

Then restart ComfyUI. Like the Validator, this node runs fully offline with no extra dependencies beyond the pack's single jsonschema requirement - if the pack loads, this node loads. (ComfyUI Manager search is the nicer path once the listing goes live; today the clone is the reliable one.)

The common mistake is expecting it to do something. It won't fix a scene, recompile a prompt, or change behavior - connect it, read the report, disconnect it. If your report is empty, check that you're actually reading the report output and that the inputs you connected are the ones with data in them. And a small tip: because all inputs are optional, you can leave it permanently wired to warnings and errors on a long pipeline - a read-only inspector is cheap insurance that costs nothing when things are working.