H3 Product Shell Boundary

Every sidebar in this pack - the Context page, Production, the clip editor's plumbing - gets its data from somewhere, and this is somewhere. H3 Product Shell Boundary is the terminal node that joins the backend's authorities into the single projection the bundled browser extension consumes. It's the pack's one hand-off between "server did work" and "browser shows a screen."

If you're a normal user, you will never place this node, and the sidebar will still work. If you're building your own front end against the pack, this is your contract.

What it does

It takes a validated context report and the native H3 wiring issued for that exact report, and emits a content-free product projection: task mode, profile, report identity, prompt fingerprint, execution correlation, the asset bindings named for presentation, and the limitations that apply.

Two properties define it. First, it is authority-checked, not merely typed. The node verifies that the wiring belongs to the report - the underlying module comments are explicit that structural equality can't stand in for the runtime-issued authority - and refuses with invalid_authority if it doesn't, or stale_wiring if the wiring's prompt doesn't match the report's document. Second, it's manual-only: the projection is built against a local qualification plan whose product scope must be manual_only_scoped, so an "assisted" product scope is refused outright as unsupported_product_scope. The shell describes what a human-driven pipeline did, and won't pretend to describe an assisted one.

It's also an output node. That's the practical tell that it's a terminus: ComfyUI will execute the chain that leads to it just to produce that projection.

Inputs and outputs

Required:

• report (H3_CONTEXT_REPORT) - the exact validated report.
• native_h3_wiring (H3_NATIVE_H3_WIRING) - runtime-issued wiring, from H3 Native MiniMax H3 Adapter.

Optional, and each is an authority the sidebar uses when present:

• recompute_plan (H3_RECOMPUTE_PLAN) - canonical recompute authority, i.e. what should be invalidated when something changes.
• pipeline_transaction (H3_PIPELINE_TRANSACTION) - single-transaction authority.
• generation_sequence_state (H3_GENERATION_SEQUENCE_STATE) - the state of a longer-video sequence.
• semantic_proposal_review_authority (H3_SEMANTIC_PROPOSAL_REVIEW_AUTHORITY) - the authority attached to an accepted or rejected proposal.

Outputs: prompt (STRING) and product_shell. The plain string alongside the structured projection is a convenience so the node can also be the thing your graph ends on in a normal ComfyUI sense.

The host pair it cares about

The shell is built against a specific host pairing: node API V1, a pinned ComfyUI core revision, and a pinned frontend revision. Before you read that as a version gate, note what the README says about the extension's own compatibility check - it inspects what your host actually provides (the native H3 nodes, their inputs, the templates, the frontend functions it uses) rather than matching a version string, and names whatever's missing.

That's a deliberate posture, and it's the more durable choice in a ComfyUI ecosystem where the frontend has been rewritten under packs' feet more than once (comfyui-ecosystem.md). The tested combination - ComfyUI 0.38.0 with frontend 1.53.6 - is the one the author verified, not a minimum.

Install

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

Not in the Comfy Registry yet, so the clone it is. Keep both the root __init__.py and the comfyui_h3_context/ folder - this node lives in the nested package. No Python dependencies are declared, no models are downloaded at install, and the browser extension is prebuilt (the repo contains its Vite source, but you never need to build it). The repo's subgraphs/H3 Product Shell Boundary.json is the bundled reusable graph, and workflows/m15_03_product_shell_*.json are API-format examples of it wired up.

When it fails

invalid_authority and stale_wiring mean the same thing in practice: you handed it a report and a wiring value from different runs. Because wiring is issued per report, caching one and reusing it after an upstream edit is exactly how you get here. Rebuild the chain.

If you're seeing unsupported_product_scope, you're outside what this shell describes - it projects a manual-only pipeline and won't claim more.

And the honest caveat: the shell's job is to be trustworthy about provenance, not about quality. It will faithfully tell a UI what the pipeline did. It has no idea whether the video came out well.