Ollama live catalog: qualify the installed release after #6002

[Hmbown]

v0.10.0 planning update — 2026-09-19

The extraction requested below has already landed through #6002. The contributor's PR and its history are retained; no second implementation is needed.

Keeping this issue open only for installed-release acceptance: with a real local Ollama server and its live model catalog, verify that the default and picker use the available models and that a selected model completes a turn. Source and unit-test evidence alone do not close that gate.

---

Original report (retained for context)

Branch fix/y2-ollama-catalog-brand-20260901 tangles the real fix (Ollama default comes from the live local catalog: provider_defaults.rs, models.rs, model_inventory.rs, provider_lake.rs) with a mark.rs rewrite and web brand tiles that conflict with the new-logo direction. Parked, not landed. Extract the catalog-default change alone onto current main with its tests; leave brand assets to the site/mark refresh.

[wuisabel-gif]

Hi @Hmbown, I would like to take the bounded catalog-default slice from #5848.

Proposed scope:

• extract the Ollama/Y2 live-catalog default behavior from the parked fix/y2-ollama-catalog-brand-20260901 work onto current main;
• keep the change limited to the provider default/catalog authority paths (provider_defaults.rs, models.rs, model_inventory.rs, provider_lake.rs as applicable);
• preserve the existing live-catalog and model-resolution contracts, including the engine/UI agreement;
• carry over or add provider-neutral regression tests proving the default comes from the live catalog;
• leave the mark.rs rewrite, website brand tiles, and unrelated branding work out of scope;
• verify formatting, Clippy, focused catalog/model tests, and the relevant workspace check.

Is this an acceptable slice to take?

[Hmbown]

Hi @Hmbown, I would like to take the bounded catalog-default slice from #5848.

Proposed scope:

• extract the Ollama/Y2 live-catalog default behavior from the parked fix/y2-ollama-catalog-brand-20260901 work onto current main;
• keep the change limited to the provider default/catalog authority paths (provider_defaults.rs, models.rs, model_inventory.rs, provider_lake.rs as applicable);
• preserve the existing live-catalog and model-resolution contracts, including the engine/UI agreement;
• carry over or add provider-neutral regression tests proving the default comes from the live catalog;
• leave the mark.rs rewrite, website brand tiles, and unrelated branding work out of scope;
• verify formatting, Clippy, focused catalog/model tests, and the relevant workspace check.

Is this an acceptable slice to take?

Yes absolutely!

[wuisabel-gif]

Historical check: the original catalog-default slice is already on main via merged PR #5795 (f76252d02). I will not duplicate that landed implementation.

The remaining review-identified gap is in the Runtime API paths that still read config.default_model() directly and can expose/send the unresolved local-Ollama placeholder before live catalog resolution is available:

• crates/tui/src/runtime_api.rs::runtime_request_model
• provider_default_model_for_api
• get_config

If acceptable, I would take this as a separate three-commit follow-up:

1. route Runtime API model resolution through the same live-catalog-aware/Ollama-unresolved guard;
2. add provider-neutral tests for omitted-model create_task/stream_turn and config projection;
3. update the focused changelog/docs and verify the full relevant gates.

This keeps the already-landed catalog work untouched and closes the remaining reachable unknown-model path identified in the #5795 review.

[wuisabel-gif]

Status update: the original Ollama live-catalog default slice is already on main through PR #5795 (f76252d02).

The remaining Runtime API/catalog-authority follow-up is also already present in integration commit 7c4bab4, included in maintainer PR #6002. That work covers the omitted-model Runtime API path, catalog-aware provider defaults, exact route identity, and related model pagination/resolution surfaces.

I am not opening a duplicate PR from this lane. #5848 should remain open until #6002 is repaired, merged, and the resulting release evidence confirms the catalog/default behavior end to end.