/add-generation-support

name: add-generation-support
description: Wire an existing ecosystem into the generation system. Adds generation support to basemodel.constants.ts, creates graph and handler files, and wires them into the ecosystem discriminator, workflow config, and router. Use after add-ecosystem when you need the ecosystem to show up in the generation form. Always checks @civitai/orchestration-client for ecosystem-specific types before writing the handler.

Add Generation Support

Wires an existing ecosystem (already defined in [basemodel.constants.ts](src/shared/constants/basemodel.constants.ts)) into the generation form. Requires the ecosystem, base model, license, and family to already exist — use the **add-ecosystem** skill first if any of those are missing.

When to use

• After `add-ecosystem` for a new provider
• To re-enable generation for an ecosystem that was previously commented out
• When adding a new graph/handler pair for an existing ecosystem that didn't have one

Prerequisites check

Before starting, confirm the ecosystem exists in [basemodel.constants.ts](src/shared/constants/basemodel.constants.ts):

• `ECO.<Name>` is defined
• An `EcosystemRecord` exists in `ecosystems`
• A `BaseModelRecord` exists in `baseModelRecords`

If any are missing, stop and direct the user to run `add-ecosystem` first.

Workflow (interactive after research)

1. Check @civitai/orchestration-client for ecosystem-specific types

The orchestrator client package is **`@civitai/orchestration-client`**. It is the continuation of the old `@civitai/client`, which can no longer be published to and is frozen at `0.2.0-beta.98`; the version line carries on unbroken in the new package (`0.2.0-beta.101` and up). **The repo depends on both** — the new package for anything recent, the frozen one for the handlers and workflow types that still import it. New ecosystem types only ever land in the new package.

**Always** check the latest published client version, even if types aren't in the currently installed version.

# Check installed version (either package may be present)
grep -E '@civitai/(orchestration-)?client' package.json

# Check latest available — the 'latest' dist-tag lags 'beta', so read the version list
npm view @civitai/orchestration-client versions --json | tail -20

Search the **latest** version's types for the ecosystem:

cd /tmp && npm pack @civitai/orchestration-client@<latest-version> 2>/dev/null
tar -xzf civitai-orchestration-client-<latest-version>.tgz
grep -n "<EcosystemName>\|<ecosystem-name>" /tmp/package/dist/generated/types.gen.d.ts

Note what you find (or don't find):

• **Ecosystem-specific types** (e.g., `SeedanceVideoGenInput`, `ComfyErnieStandardCreateImageGenInput`): use them — they give you the exact field shape and strict enum literals
• **Multiple variant types** (e.g., standard vs turbo): the handler will branch on model version and return the appropriate typed input
• **No types at all**: fall back to the generic `ImageGenStepTemplate` / `VideoGenStepTemplate` with a string `engine` field

If the installed version is older than the latest and the latest has useful types, bump:

pnpm add @civitai/orchestration-client@<latest-version>

Import new types from `@civitai/orchestration-client` rather than hand-rolling them. Handlers already importing from `@civitai/client` keep working — leave them unless migrating them is the task you were asked to do.

2. Research model defaults

If the user hasn't already pointed you at docs, check the HuggingFace or official model card for:

• **Model version IDs** on Civitai (the user usually has these — ask if not)
• **Recommended aspect ratios / resolutions** (exact dimensions)
• **Recommended guidance scale / cfg scale**
• **Recommended inference steps**
• **Supports LoRAs?** (drives resources node)
• **Supports negative prompts?**
• **Fixed sampler/scheduler** (if the provider locks these, hardcode in the handler rather than exposing UI controls)
• **Media type**: image-only, video-only, or mixed

3. Decide on graph structure

Based on research, pick the right shape:

• **Single model, simple**: one `sliderNode` per parameter, one aspect ratio set. Seedance is a good reference.
• **Multiple versions with same controls but different defaults**: use `createCheckpointGraph` with `versions.options`. Parameter defaults can vary via `ctx.model?.id` checks. Seedream is a reference.
• **Multiple versions with different capability sets**: use a computed `<name>Variant` discriminator and branch into separate subgraphs. Ernie is a reference — base has LoRAs, turbo doesn't.
• **Model-dependent defaults on the same node key**: if both variants have `cfgScale` but different defaults, just declare each subgraph with its own `sliderNode` defaults. **Do NOT add a `.effect()` that calls `set('cfgScale', ...)` on variant change** — see "Don't use `.effect()` to reset slider values across variants" below.

4. Confirm the plan with the user

Summarize:

Adding generation support for: <EcosystemName>

Graph: src/shared/data-graph/generation/<name>-graph.ts
- Versions: <list with IDs>
- Aspect ratios: <list>
- Sliders: cfgScale (<range>, default <n>), steps (<range>, default <n>)
- Features: [resources, negativePrompt, images for I2V, etc.]
- Structure: [single graph | discriminator with subgraphs | version-dependent defaults]

Handler: src/server/services/orchestrator/ecosystems/<name>.handler.ts
- Types: <from @civitai/orchestration-client, or generic>
- Step type: <imageGen | videoGen>
- Fixed params: sampler=<x>, scheduler=<y> (if applicable)

Wiring:
- basemodel.constants.ts: uncomment/add ecosystem support + settings
- workflows.ts: add to <TXT2IMG_IDS | TXT2VID_IDS | etc.>
- ecosystem-graph.ts: add to grouped discriminator
- ecosystems/index.ts: import, type, export, router case

Wait for confirmation.

5. Make the changes

All files listed below are required edits. Make them in one pa