v0.1.25 — provider/catalog/task-routing three-layer split

[TsekaLuk]

Why

A provider carried a required defaultModel, which made a connection and a model choice the same thing. That single field was a second, hidden routing authority: automatic setup preferred it, resolveModel fell back to it, and when it was empty the call fell further back to a hardcoded per-kind table — reaching a model the user never configured. It is also why a DashScope connection had to be named "Qwen Image 3": the label was the only place left to say what the connection was.

Separately, Settings offered six task slots while the runtime consumed a two-slot chat/image projection. A binding for webdev was dead whenever text was set; image-edit was dead whenever image-generation was set. The UI promised per-task routing the runtime never honoured.

What

Configuration is now three layers that cannot be collapsed:

Layer	Owns	Persisted in
1 Connection (ProviderConfig)	endpoint + protocol + credential reference	providers.json
2 Catalog (ProviderConfig.catalog)	the models that connection advertises	providers.json
3 Routing (CapabilityBindings)	which connection + model serves each task	settings.json

• defaultModel is optional and deprecated: parsed so pre-v0.1.25 providers.json still loads and so the one-time binding migration can seed a text route from it, and consulted by nothing else. resolveModel has no fallback table — an unbound call fails with NO_MODEL_BOUND.
• The probed catalog moves from a localStorage verification receipt onto the connection, so clearing web storage no longer strips a provider of its models. Verifying a provider and refreshing its catalog are one action (verifyProviderCatalog) with one writer.
• task-routing.ts resolves every generation call site by task, with an explicit inheritance chain. taskFallbackChain is shared with the coverage summary so the two cannot drift.
• useEndpointModels/listEndpointModels are removed: gated on provider.baseUrl, they were permanently disabled for every direct vendor connection, which is why the model pickers were always empty.
• Settings AI reads as two steps — connect providers, then assign models to tasks. A task row shows provider · model, never a bare slug, and says which task an unassigned route inherits from.

Found while auditing

• materialize() rebuilt ProviderConfig field by field and dropped catalog, so any edit — even a rename — erased the model list it had just probed. Fixed, with a regression test.
• commerce-operator.test.ts matched the Cargo version through an escaped regex (0\.1\.24) that a version-bump search never finds; it would have kept passing against the previous release. Now derived from package.json.
• updater/release-notes.test.ts used the next version as its "not in the catalog" case, so it broke the moment that version shipped. Now a synthetic version.

Release

Prepares v0.1.25: version bumped across display, Cargo, Tauri, capability manifest and Codex plugin, with a reviewed release-note catalog entry in all five shipped locales.

Verification

pnpm lint · tsc --noEmit -p tsconfig.app.json · 463 frontend suites · 322 Rust tests · pnpm build · release-notes:validate --require-all-locales · validate-release-version --expected 0.1.25 — all pass.

Not yet done: the app has not been launched manually. This changes the persisted provider shape and every generation call site, so a real run is worth doing before the tag.

🤖 Generated with Claude Code