Module model_catalog 

§2 module 26 model.catalog (docs/composable-harness/ COMPOSABLE-HARNESS-DESIGN.md §3.1 [capabilities.model_catalog]) — P4 of the composable-harness migration (design §5.2 phase P4: “aliases + fallback chains (userconfig.rs:386-411) promoted into core” + the small_model knob).

What moved here. The CLI’s alias_table/resolve_model_alias (crates/cli/src/userconfig.rs) were CLI-only (design §1.10: “CLI model aliases ✓ … resolve_model_alias, userconfig.rs:386-411”). This module is the single source of truth now — DEFAULT_ALIASES is the exact same eleven built-in aliases, byte-identical, so moving them here changes no resolved slug for any existing caller. The CLI crate re-exports through userconfig::alias_table/resolve_model_alias (zero call-site churn, zero behavior change — see that module).

What’s NEW (P4). resolve_alias additionally accepts an extra table ([capabilities.model_catalog].aliases, §3.1/§3.2: “capabilities.model_catalog.* | CLI alias_table … + NEW small-model/fallback”) so a user’s own config can add or override an alias without recompiling — extra is checked BEFORE DEFAULT_ALIASES, so a user override always wins. resolve_fallback_chain resolves a [capabilities.model_catalog].fallback list of aliases/slugs into a plain slug list the SAME way, for the D-9-adjacent “failure fallback chain” knob (catalog §4a: “Model aliases + failure fallback chain (resolution table before request build)”).

Scope note (S-sized, per design §5.2 P4). This module lands the RESOLUTION TABLE only — Config::small_model/Config::model_fallback are knobs a caller can read, not a retry/failover LOOP that automatically re-sends a failed request against the next model in the chain. Building that loop is a distinct, larger change (closer to §1.10’s “mid-session model switch,” itself called out in design §5.2 as its own M-sized item, separate from this S-sized catalog item) and is out of scope here.

Structs

Resolution

Everything [capabilities.model_catalog] resolves into, alias-resolved: the effective core.model, the small_model (if set), and the fallback chain (if set). Shared by both resolution paths that carry a capabilities.<name> table shaped like crate::configfile::CapabilityConfig — the SDK’s crate::configfile::HarnessConfig resolver (materialize_config) and the CLI’s own FileConfig-driven build_config — so the alias/small-model/fallback resolution logic lives in exactly one place.

Constants

DEFAULT_ALIASES

The built-in alias → full-slug table (byte-identical to the CLI’s original userconfig::alias_table, moved here as the single source of truth — see the module doc).

Functions

resolve

Resolve [capabilities.model_catalog] against base_model (typically the already-computed core.model / CLI --model/config value). Consulted regardless of capabilities.model_catalog.enabled — matching the resolver’s existing D-9 check (configfile::validate_modules), which already reads model_catalog.small_model unconditionally: these are data a caller resolves against, not an activation switch.

resolve_alias

Expand a friendly model alias to its full slug, consulting extra (config-provided aliases, §3.1 capabilities.model_catalog.aliases) BEFORE DEFAULT_ALIASES — a config-provided alias may override a built-in one (e.g. re-pointing "opus" at a different slug), but an unknown value always passes through unchanged so any real slug still works. extra is typically empty (no config wired it in), in which case this is exactly the CLI’s original resolve_model_alias behavior.

resolve_fallback_chain

Resolve a [capabilities.model_catalog].fallback list (each entry an alias or an already-full slug) into full slugs, in order, via resolve_alias. An empty chain resolves to an empty Vec — the default, no-fallback-configured shape.