fix: use supported model presets in companion setup - #226
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthrough
ChangesSetup preset catalog integration
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The setup dropdown now uses supported preset identifiers and includes coverage for retaining and persisting a valid Ollama selection. No actionable merge risk remains. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The companion setup dropdown used stale preset IDs and omitted
ollama-agentic. Its two-way selection binding cleared that valid preset, causing setup to fall back to the non-toolollama-generalprofile and leaving local chat unable to select a tool-capable model.Populate the dropdown from the same
LocalModelPresetCatalogused by setup. This exposes supported presets and removes IDs that the CLI cannot resolve.Validation: a headless Avalonia regression checks that the real window binding retains and saves
ollama-agenticand every offered ID resolves. A desktop integration smoke using the updated companion and the released NativeAOT gateway/CLI passed setup, websocket chat through a local provider fixture, stop/restart/reconnect, corrupt-config recovery, and owned-gateway shutdown on desktop exit.Summary by CodeRabbit
New Features
Bug Fixes
Tests