Multimodal — Context handler (debug outputs)

This is the debug build of the Context handler, and it exists because one specific debugging session is an absolute classic: the LLM's output goes sideways, you suspect the context, but the Context handler only gives you the combined string - one big blob with no way to tell which block contributed what. This variant produces the same combined extra_context, but also exposes every individual resolved block plus the source path it came from. It turns "why is the model talking about the wrong character?" from a guessing game into a per-block inspection.

What you get

The inputs are identical to the plain Context handler - same four blocks, same text/file/preset sources, same join_with, include_titles, preview_chars. The difference is entirely on the output side. Ten outputs:

• extra_context - the combined string, same as the regular node (wire this to the LLM).
• block1_text through block4_text - each block's resolved content, separately, so you can see exactly what made it into the context and what didn't.
• block1_path through block4_path - the source path each block resolved from (a preset's absolute .md path, or your file path), which is the killer feature: it answers "which file is this preset actually reading, and did my edit even land in the right one?"
• extra_context_preview - the truncated preview.

If you've ever chased a bug where a context block silently came out empty - wrong filename, a preset that didn't match, a file that resolved to nothing - the blockN_path outputs are your smoking gun. A block that should have content but shows an empty blockN_text plus a real path means the file read failed; a block with no path at all means it never resolved.

When to reach for it

Honestly: debug first, then swap. When you're building a new multi-block context for the first time, use this node - wire the block outputs to Show Text nodes and confirm each source is what you think it is. Once you've got a run that behaves, swap in the plain Context handler for the cleaner graph and get the two-output wiring back. Running the debug variant permanently is fine, but it's ten wires of noise on a canvas that's probably already crowded, and the whole point of the tool is that the debugging version earns its keep exactly once per configuration.

It's a utility node with a very narrow job, and it does that job flawlessly: no behavior difference from the production node, just the ability to see inside. For a pack whose whole pitch is closed-loop prompting, the debug view is the difference between trusting the loop and understanding it.