H3 Semantic Proposal Producer

Most "prompt enhancer" nodes in ComfyUI do the same thing: you wire a text box in, a language model rewrites it, the rewritten text goes straight into your conditioning whether you looked at it or not. The standard failure modes are well documented - the model returns "Here is your enhanced prompt:" as literal tokens, or it invents a plot you didn't ask for (the KB's LLM-node doc covers the drift problem in detail).

H3 Semantic Proposal Producer is the other shape. It runs a local Ollama profile, produces a proposal, and emits a review authority - a handle that says "a human may now look at this." Nothing gets applied to your prompt without an accept.

The four inputs it insists on

None of them are free text:

• report (H3_CONTEXT_REPORT) - normally from H3 Context Plan or H3 Context Validator. This is the compiled, diagnosed context the proposal has to be about.
• wiring (H3_NATIVE_H3_WIRING) - from H3 Native MiniMax H3 Adapter. The node has to know which H3 graph and model this prompt is destined for; a proposal for nobody's workflow is not a proposal.
• provider_setup (H3_PROVIDER_SETUP) - from H3 Provider Transparency. No declared provider policy, no run.
• ollama_profile - a combo, defaulting to ollama.qwen3_8.27b_bf16.local.

That third input is the tell. The README is explicit that assisted authoring - the sidebar's Optimize prompt - is a completely separate provider setup, and this node has its own pinned local profile with its own model, configured on its own. So: local Ollama, on the ComfyUI host, one documented profile. If you skipped setting that up, you get a refusal, not a different provider. Nothing switches silently on failure - that's stated as a design rule, and the code backs it up by only ever surfacing closed outcome codes like producer_execution_failed or choose_local_model, never the prompt, the response or the source objects.

Note also that the node is an output node: queue the graph and it executes as a terminal step. There's no downstream node required for it to do its job.

What you get out

One output: review_authority (H3_SEMANTIC_PROPOSAL_REVIEW_AUTHORITY). It's consumed by H3 Product Shell Boundary, which claims the authority and presents the proposal for accept/reject. That's the whole point of the type: a plain string can't be "reviewed," but an authority object can be claimed exactly once, so a proposal can't be quietly applied twice from a cached run.

Which is why the node returns float("NaN") from IS_CHANGED, the standard "never cache me" idiom in ComfyUI. Provider qualification and the one-time process-local authority must not be replayed from cache - rerunning the graph re-runs the model call, and there's no stale authority lying around from last Tuesday.

How to use it, honestly

This is not the node you reach for to make your prompt "better." It's the node you reach for when you want a second opinion on a prompt that's already structured - a plan with declared intent, references and hard constraints - and you want that opinion as a review step rather than as a blind overwrite. Which is exactly what the official H3 prompt-writing guides reward: intent, shot content, camera and audio written explicitly, not a pile of adjectives the model has to decode.

If you do want a fast quality pass on the text before generating, the sidebar's assisted authoring does the same job with a provider of your choice and the same accept/reject contract. Keep the two separate in your head - the README does, and mixing them up is the fastest way to spend an evening wondering why your Ollama model never appears in the settings page.

Install it

Per the README the pack isn't in the Comfy Registry yet:

cd ComfyUI/custom_nodes
git clone https://github.com/rookiestar28/ComfyUI-MiniMaxH3-Studio.git

Restart ComfyUI, refresh the browser, and find the node under Add Node → h3_context → semantic. Nothing is installed by the pack itself: no Python dependencies, no provider SDK, no models. You supply Ollama, the profile's model, and - through H3 Provider Transparency - the declared policy that says the route is local and the loopback boundary is understood.

Actual failure modes, all of which surface as codes rather than tracebacks: no Ollama reachable on the host; the profile's model not pulled; a wiring or report input that isn't the exact typed object the node expects; or a host-issued execution correlation that doesn't match the node being executed. Fix the named thing and re-queue - there is no fallback path, by design.