Badge Edit Prompt Route V1

What this is for

Every masked edit is one of two things: change what the region means (make the eagle look angry, remove the scratch) or change what it's made of (that region is silver now). Those are different prompts, different constraint policies and, in the pack's case, different downstream nodes. Keeping them in the same graph means somebody has to decide, based on some booleans, which prompt actually goes to the model - and then prove afterwards which one it was.

Badge Edit Prompt Route V1 is that decision, made explicit. Two mode flags in, one prompt plus an edit_mode label and a digest out, with a status string telling you whether the request is valid and whether it's actually going to run.

It's a logic node with a paper trail. The interesting bit isn't the routing, it's the action_digest, which lets downstream validation refuse to act on a request whose prompt changed after you previewed the mask.

How it works

The contract is exactly-one-mode. semantic_mode and material_mode are XOR: set both, or neither, and the node reports edit_mode: invalid with reason invalid_edit_mode and an empty prompt. It doesn't throw - a deliberately neutral answer so the graph can keep going and the guard downstream can decide what to do.

With a valid mode it picks the matching prompt widget, trims it, and builds the digest over edit mode, material id and the final prompt text. effective_request is only true when you asked to apply (requested_apply), the mode is valid, and the prompt is non-empty. If the prompt is blank, the status reason is empty_prompt rather than not_requested, which is a nice touch - you can tell the difference between "you didn't press go" and "you pressed go with nothing to say".

Three of the inputs are lazy. check_lazy_status only asks for the branch you selected: in semantic mode it wants semantic_prompt; in material mode it wants both material_prompt and material_id. The other branch's inputs are never evaluated. In a graph where those prompts are themselves built by an expensive chain, that's a real saving, and it's the same lazy-evaluation trick comfyui-node-plumbing.md describes for switch nodes generally.

The inputs and outputs

• semantic_mode (on by default) / material_mode (off) - the XOR pair. Exactly one.
• requested_apply - off by default. Think of it as the safe/armed switch: with it off you can still read the resolved prompt and mode for preview purposes, but effective_request stays false.
• semantic_prompt - default Refine only the selected region.
• material_prompt / material_id - the material branch. Both are ignored in semantic mode.

Outputs: selected_prompt (the winner, trimmed), edit_mode (semantic, material or invalid), effective_request (boolean), action_digest (a SHA-256 over mode + material id + prompt), and status (JSON with state: ready|blocked, reason, edit_mode, effective_request).

Install

cd ComfyUI/custom_nodes
git clone https://github.com/TeutonicMepheles/ComfyUI-DAELab-Custom-Nodes-Library.git
# restart ComfyUI

This is a V3 node (comfy_api.latest), so it needs a reasonably current ComfyUI. It's registered from the badge_app_workflow module alongside three siblings, and if that module fails to import you lose all four - see the note below.

Where people get burned

Both flags on. The most common wiring mistake in any XOR node, and here it fails quietly by design: you get an empty prompt and edit_mode: invalid instead of an exception, so a graph that ignores the status will happily send an empty prompt to a paid call. Always wire effective_request into whatever gates the spend.

Reading the prompt but ignoring the digest. The digest exists because prompts change. If you cache a validated selection and then edit the prompt, action_digest changes and the guard downstream should reject the apply. Skip that wiring and you've built yourself a stale-approval bug.

material_mode with no material id. The mode is valid, the prompt may be non-empty, and effective_request can be true with an empty material_id - the digest then covers an empty id. Put the id through, or the material branch loses the one field that identifies what it's supposed to apply.

Missing node. If this node doesn't exist in your menu at all while older DAELab nodes do, check your startup log for an import error in badge_app_workflow/node.py. cv2 and scipy are the usual suspects, and the pack bundles this node with its routing siblings in one module, so a single missing dependency takes the group down with it.