2.5.3 #13
Loading…
Reference in a new issue
No description provided.
Delete branch "2.5.3"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Lots of bug fixes and some new features. See release notes.
Rune caught this live: the selected MCP tab and "External MCP" sidebar row rendered as solid opaque blue blocks completely hiding their icon/label. Root cause: .glassEffect() was nested inside a .background { } closure applied to a plain Color.clear placeholder, which isn't how the API is meant to be used — it needs to wrap the real content directly (as the skill's own examples show), not sit behind it as an opaque background layer. Also discovered the skill's documented isEnabled: parameter on glassEffect(_:in:isEnabled:) isn't available on this SDK build ("extra argument in call") — worked around by branching the view instead of using that parameter. Since tabButton/mcpSidebarRow are actual Buttons, switched to the more correct approach for buttons specifically: native .buttonStyle(.glass)/.buttonStyle(.glassProminent) for the tab bar (matching the skill's textbook button pattern) rather than hand-applying .glassEffect() to custom content. mcpSidebarRow needed to stay on direct .glassEffect() application (not button styles) since its row needs to stretch full-width via a trailing Spacer(), which glass button styles don't support — but applied directly to the real HStack content this time, branched via if/else, not nested in .background. Note for the next Rune check: native glass buttons add ~13pt of their own internal padding, so manual padding was reduced/dropped on tabButton's label — sizing may look different than before, adjust if too large/small.Fourth and sixth pieces of the Apple Intelligence tool-calling work (see /Users/rune/.claude/plans/apple-intelligence-tool-calling-plan.md). generateAppleOnDeviceToolResponse() is a new, dedicated dispatch path — routed to instead of the generic generateAIResponseWithTools() when currentProvider == .appleOnDevice, since LanguageModelSession's persistent, framework-driven tool loop doesn't fit the stateless, manually-looped chatWithToolMessages contract every other provider uses. Builds the tool list + system prompt once per turn, calls AppleFoundationProvider.respondWithTools() exactly once, and renders the result through the exact same showSystemMessage/ flushToolCallSummary/updateToolCallMessage path every other provider's tool loop already uses, so the "🔧 Calling: …" UI looks identical regardless of which provider is actually running. New appleSessionKey gives Apple On-Device a stable per-conversation identity even before a chat is ever saved (currentConversationId is nil until first ⌘S) — an ephemeral UUID regenerated on New Chat and Clear Chat, which also now explicitly resets the cached tool session on both of those actions so a stale session is never reused for what the user sees as a different conversation. Dormant until step 7 flips capabilities.tools for Apple On-Device — modelSupportTools is still false today, so this new dispatch branch never actually fires yet. 425 tests, stable across two consecutive full runs, zero regressions in the existing dispatch/reset paths this touched.Live-caught by Rune: a trivial one-tool request ("how many files in my Downloads folder?") failed with "Provided 10,466 tokens, but the maximum allowed is 8,192" — on the very first real test of tool calling. Measured the real cause with Rune's actual live tool configuration (via a throwaway, uncommitted diagnostic test, not guessed): registering all 49 currently-enabled tools cost ~3,300 tokens of descriptions alone, before the system prompt, the user's message, or any tool result even factored in. One External MCP server (Obsidian, 16 tools) was 63% of that footprint by itself — third-party tool descriptions are outside Confab's control and can be arbitrarily verbose, unlike Confab's own deliberately-concise built-in tools. Checked the fix approach with Rune before implementing (a real product/scope decision, not something to guess): exclude External MCP tools specifically for Apple On-Device (other providers' 100K+-token windows absorb this fine) rather than building a full per-provider tool-selection UI right now. Re-measured after the fix: 33 tools, ~1,212 tokens — comfortable headroom in a real conversation. Confab's own built-in tools (files, bash, calendar, mail, contacts, Paperless, Maps) are unaffected. Also fixed while investigating: the real error dynamically reported the actual 8,192-token limit (Apple's own error carries this), which exposed that Confab's own hardcoded "4K context window" claims (ModelInfo.contextLength, capabilities.maxContextLength, the model description text, and a stale hardcoded "(4,096 tokens)" in the macOS 26.x-only GenerationError fallback path) were wrong for the current beta. Updated the verified ones to 8192; left the macOS 26.x-only error message without a specific number since whether that runtime shares the same limit is genuinely unverified. 429 tests, clean.