The analysis

ComfyUI substrate inventory

Read at: magieva-core branch fix/residency-fail-closed-round-lesson, commit ef3798123c5 (2026-10-27). All line numbers are against that commit.

Headline finding. Magieva has a genuinely shipped ComfyUI substrate, not a plan: a complete Local Resource Manager (LRM) connector that speaks ComfyUI's real HTTP API, five embedded workflow graphs (four registered), GCE GPU provisioning that installs ComfyUI from scratch and registers it back into LRM, a task-executor video provider, a weight-licence hosting gate with per-model pins, and a desktop Electron install/run path. But it is fragmented into three parallel invocation paths that do not share a gate, and several seams that look wired are dead: internal/psdedit/local.go POSTs to an LRM route that does not exist, the contentstudio COMFYUI_API_URL façade is set by nothing in any deployment config, the comfyui_lrm transport has no registered Go driver, and the desktop's ComfyUI registration is opt-in and defaults off. The planning docs are stale in both directions — docs/planning/26.35/os-video-model-integration/README.md:3 still says "Planning. Nothing built." while its own Phase 1 is live in production, and docs/planning/26.35/status/M3.md says "No ComfyUI workflow graphs for video" while four such graphs now exist and two are verified by execution on real GPUs.

What is actually shipped

Status key: (a) live/wired · (b) exists but behind a flag / env var / unshipped · (c) planned only.

(b) Exists but behind a flag / env var / unshipped

The ComfyUI integration contract

LRM → ComfyUI (the real protocol)

All in services/local-resource-manager/connector_comfyui.go. HTTP only — there is no websocket client anywhere in LRM (grep for websocket in services/local-resource-manager/*.go returns only the unrelated relay connector for desktop Ollama, connector_relay.go:1). Progress is polled.

Output extraction is a documented trap. comfyOutputKeys = ["videos","gifs","audio","images"] (:379) — core SaveVideo emits the mp4 under images, not videos; the comment records this was corrected against a live ComfyUI (frontend 1.49.6) on 2026-08-26. MIME is derived from extension (comfyMimeByExt, :384), because the old code hardcoded image/png for everything.

Fail-loud guards (both are the fix for a real silent-wrong-output defect):

• req.Control != nil → hard error "control conditioning … is not implemented" (:220-231). Control graphs are Phase 4.3.
• A non-image capability with no template → hard error naming capability and model (:238-255), instead of the txt2img fallback that once answered a video request with a PNG.

Callers → LRM

EndpointURL is lrmClient.baseURL + "/v1" (services/aimrs-service/handlers.go:166), so ExecuteLocalGeneration lands on LRM's synchronous /v1/generate.

⚠️ The three invocation paths do not share a billing gate — this is load-bearing

HandleUniversalGeneration (sync, /v1/generate) refuses platform-GPU generation for any provider that is not Bernini:

// generation_proxy_handler.go:239-249
if backend.Origin == OriginPlatformGPU {
    if h.billing == nil { … "platform GPU billing not configured" }
    if backend.ProviderName != ProviderBernini {
        return 503 {"error":"no flat pricing configured for this platform model","code":"NO_PRICING"}
    }

HandleAsyncGeneration (/v1/generate/async, :344-396) has no billing gate and no provider check — it goes straight to genConn.GenerateAsync.

HandleImageGeneration (/v1/images/generations, :59-181) also has no billing gate and no provider check — it goes straight to genConn.Generate at :140.

So of the three ComfyUI invocation paths, only one gates:

The consequence is inverted from what one would expect: the two paths that do work on a platform GPU are the two with no billing gate, and the one path that is correctly gated is the one that cannot serve ComfyUI at all. aimrs.ExecuteLocalGeneration is therefore usable for ComfyUI only on origin=customer_device.

GPU runner → LRM registration

services/gpu-runner-service/lrm_client.go:70-83 POSTs to /api/v1/local/backends:

{"organization_id":"…","provider_name":"comfyui","display_name":"platform-gpu rtx6000 (comfyui/wan2.2-ti2v-5b)",
 "base_url":"http://<ip>:8188","backend_type":"image","capabilities":["<one capability>"],
 "origin":"platform_gpu","max_concurrent":4,
 "hosted_models":[{"model_id":"comfyui/wan2.2-ti2v-5b","license":"apache-2.0"}]}

Note backend_type is "image" for ComfyUI and "video" only for Bernini (:66-69) — a ComfyUI runner is registered as an image backend even when it was provisioned for a video capability. hosted_models deliberately carries no clearance field: LRM re-reads org_license_acceptances itself (lrm_client.go:34-44), so the two gates judge the same fact independently.

Shipped workflow graphs

Five files in services/local-resource-manager/comfyui_workflows/; four registered.

Models with NO graph (registered in the catalog and offered in the picker, but a request fails loudly): wan2.2-t2v-a14b, ltx-2.3, ltx-2.5, scail-2, ltx-video. This is the honest fail-loud path, not a silent fallback — but it means the customer-facing model list (customer-docs/site-src/reference/models/comfyui--local.md:10-23) advertises models that cannot render.

Models and licences

The gate

internal/modellicense/ classifies weight licences for platform-GPU hosting, deliberately separate from BORG's SPDX code-licence check (policy.go:1-15): "a model's node-pack/code can be MIT while its downloadable weights carry a restrictive license." The canonical example given is Bria RMBG-2.0 — ComfyUI-RMBG node code permissive, RMBG-2.0 weights requiring a commercial agreement.

ValidatePlatformHosting(modelID, license, hasClearance) (validate.go:31): HostedAllowed → nil · RequiresAgreement → nil only if clearance · Prohibited → always error · Unknown → error (fail closed).

Enforced independently at both hosting paths: gpu-runner-service/manager.go (Provision, before creating the VM) and local-resource-manager/backend_handler.go:224 (on origin=platform_gpu registration). Both read clearance from org_license_acceptances, never from the request body (backend_handler.go:193, lrm_client.go:34-44).

Model → licence map

Pins in internal/modellicense/policy.go (knownWeightLicense, :41-80), asserted by internal/modellicense/os_video_models_test.go:22-47:

Two subtleties worth carrying into any reuse:

• WeightLicenseFor picks the most restrictive match, not the first (policy.go:202-218) — the comment records this replaced a map-iteration-order fail-OPEN coin flip on a gate deciding commercial hosting rights.
• Adapters classify independently of their base (os_video_models_test.go:106-134): every LTX IC-LoRA is restrictive even on an Apache-2.0 Wan base, so ValidatePlatformHosting runs per adapter. manager.go states the base passing the gate "does NOT clear its adapters."
• Customer-device hosting is deliberately NOT gated (policy.go:70-74): "that is the customer's own use, and the asymmetry is correct, not a bug to fix."

Desktop / local install path

Install — web/scripts/setup-comfyui.sh (166 lines), invoked by NativeProcessOrchestrator.runComfyUISetup (:1056), which locates the script at Resources/scripts/setup-comfyui.sh (packaged) or ../../../scripts/setup-comfyui.sh (dev). It checks Python ≥3.10, creates a venv at ~/.magieva/comfyui-data/venv, clones ComfyUI, installs requirements.txt, installs two custom-node packs, and writes a launcher at ~/.magieva/bin/comfyui/comfyui_launcher that runs main.py --listen 0.0.0.0 --port 8188 --enable-cors-header.

Run — backend definition at NativeProcessOrchestrator.ts:361-378: binaryName: 'comfyui_launcher', processName: 'magieva-comfyui', hostPort: 8188, healthProbePath: '/system_stats', capabilities ['text-to-image','text-to-video','image-to-image','background-removal'] (hyphenated to match LRM's canonical vocabulary). Port ownership is checked before spawn (:505, refuses with pair_owns_port).

Announce — startup.ts:1535 registerComfyUINode, gated on localProcessing.image.enabled (default false), calls install({backend_type:'comfyui', expose_via:'cloudflared'}) then bridge.sendBackendReady({backendType:'comfyui', capabilities, maxConcurrent: 1}). The desktop does not POST to LRM directly — it goes through the event-bridge (docs/planning/26.27/local-magieva/03-local-media-routing-comfyui-aimrs.md documents this correction).

Model selection — LocalModelSelector.ts:75 selectDefaultImageModel: ≥24 GB → sd3.5_large, ≥16 GB → flux1-schnell, else SDXL. canRunLTXVideo (:187) gates on ≥14 GB RAM; canRunBriaRMBG (:196) on ≥3 GB.

Two concrete defects in this path:

1. setup-comfyui.sh:128 clones kijai/ComfyUI-RMBG — the 404 URL that the GPU-side script explicitly fixed to 1038lab/ComfyUI-RMBG (startup_script.sh:64-66), and which startup_script_test.go:103-107 now asserts against. The desktop path still has the broken URL.
2. CapabilityAdvisor.ts is at web/electron/main/briareus/CapabilityAdvisor.ts, not web/electron/main/backends/CapabilityAdvisor.ts as cited by docs/planning/26.35/os-video-model-integration/README.md and the migration header — and it contains no ComfyUI or local-backend logic at all (127 lines, chat-model budget only: assessModel, recommendChatModel). The migration's claim that it "drives the two-path runnability check" for ComfyUI is not true of this file. deriveHardwareProfile, also cited, does not exist there.

Planned but NOT built

Reusable in a competition entry

Directly reusable as an open-source ComfyUI app (little or no Magieva-internal coupling):

1. The workflow-graph corpus + the (capability × model) keying discipline. comfyui_workflows/*.json are ComfyUI's own templates exported to API format, with _README blocks recording provenance, upstream version, and measured wall-clock/peak-VRAM. The workflowTemplateKey design (comfyui_workflows.go:37-44) and the rule "a model with no template must FAIL, naming the model" is a genuinely good pattern for any multi-model ComfyUI app.
2. comfyui_workflow_params.go in full. Graph-agnostic injection matching on class_type and following the graph's own links — survives a re-export that renumbers nodes. The isLink guard (never overwrite a link with a literal, :45-54) and findPromptNodes (resolve positive vs negative by following links, :91) are the two pieces that make it robust. This is the single most reusable file in the inventory.
3. The connector's output-extraction layer. comfyOutputKeys + comfyMimeByExt + sortOutputsRichestFirst encode hard-won knowledge (core SaveVideo emits under images) that any ComfyUI client needs.
4. The fail-loud guards. Refusing to answer a video request with a txt2img PNG, and refusing control requests that nothing honours, are the right defaults and are cheap to port.
5. setup-comfyui.sh — a working, idempotent macOS/Linux ComfyUI installer (once the RMBG URL is fixed to 1038lab).
6. The licence-classification idea — separating code licence from weight licence, with most-restrictive-wins and per-adapter classification. Reusable as a concept even if the specific pins are Magieva's.

Magieva-internal plumbing that would need replacing:

1. LRM itself. The whole /v1/generate + /v1/generate/async + /api/v1/local/backends surface, LocalBackend, Origin (customer_device/platform_gpu), the X-Organization-ID attribution header, LocalUsageRecorder, and the token-hold billing gate. A competition app would talk to ComfyUI directly.
2. The AIMRS resolution layer. ExecuteLocalGeneration depends on a resolved EndpointURL and IsLocal() from a separate routing service. Not portable.
3. The GCE provisioner + tier catalog. provisioner_gce.go, gpuTiers, ai_model_execution_tiers, ai_model_adapters — cloud-specific.
4. internal/modellicense's enforcement points (org_license_acceptances, platform_gpu origin) — the policy is reusable, the enforcement is Magieva's DB.
5. The desktop event-bridge registration (sendBackendReady → event-bridge → LRM) — three services deep.
6. internal/psdedit/local.go and the contentstudio façade — both currently broken; do not port as-is.

Judgement. The reusable core is roughly comfyui_workflow_params.go + comfyui_workflows.go + comfyui_workflows/*.json + the connector's submit/poll/extract half — a self-contained "ComfyUI workflow runner with model-keyed graphs and safe param injection." Everything else is either Magieva's multi-tenant routing/billing substrate or an unwired seam.

Gaps and unknowns

Verified gaps (code-level, no runtime needed):

• internal/psdedit/local.go:72 targets a non-existent route; its payload field would be dropped even if the route existed. The local PSD-edit path cannot work.
• COMFYUI_API_URL is set nowhere in deployment config; services/comfyui-service does not exist. The contentstudio ControlNet ComfyUI path is dead code.
• comfyui_lrm has no registered transport driver.
• setup-comfyui.sh:128 still clones the 404 kijai/ComfyUI-RMBG.
• Sync vs async vs images billing-gate asymmetry: platform-GPU ComfyUI is rejected on /v1/generate but accepted and unbilled on /v1/generate/async and /v1/images/generations.
• lrm_client.go:66-69 registers every ComfyUI runner as backend_type: "image", even when provisioned for a video capability.
• Customer docs (comfyui--local.md) list 19 models; only 4 have registered graphs.

Not verified / unknown (stated rather than guessed):

• I did not run go test, go build, or any service. "Live" above means wired in code and reachable by a registered route/caller, not observed running.
• I did not read services/local-resource-manager/backend_handler.go in full, so I cannot state whether the registration gate and the generation gate agree on every backend type; I verified only the origin=platform_gpu hosted-model licence check at :224.
• I did not verify the ai_model_adapters migration (20260831130200) contents beyond its header.
• I did not confirm whether the first_last_frame_to_video gap is still open in a later commit — GenerationRequest at this commit carries one InputImageURL only (generation_types.go:50).
• The docs/planning/26.35/status/M3.md production claims (live in 26.35.5, 0 local_backends rows, dryrun provisioner) are the doc's assertions; I did not query any environment.
• internal/contentstudio/ is another agent's scope; I read only the COMFYUI_API_URL façade (character_render_controlnet.go:160-274).
• I did not exhaustively enumerate every _test.go assertion; test files are cited as evidence of intent and coverage, not audited line by line.