refactor(server): settled state is now server-authored, ending client drift - #5462

💭 Looking at the scope of files being changed across the chat, command palette, sidebar, and settings components, I'm noticing a pattern around input handling. The SettingsPanels.tsx change to commit AutoSettleDaysInput on blur or Enter suggests there might be a shared input primitive or pattern I should examine to ensure consistency across these UI updates. I'm checking for UI consistency issues in the settings panels, particularly around how useSettingsRestore handles the unified settings object that combines both client and server settings. The key question is whether updateSettings properly routes the thread auto-settle properties to the server, and I need to verify what supportsAutoSettle actually does. There's also a potential problem with the settings search registry — if searchableSetting("auto-settle-merged-threads") registers these entries but the UI conditionally hides the rows, search could navigate to non-existent elements. Let me check how the search registry works and whether it needs to match the rendered rows. I'm noticing that the settings search catalog still includes entries for "auto-settle-inactive-threads" and "auto-settle-merged-threads" even though those rows are now conditionally hidden, which means search results would navigate to anchors that don't exist. It's a soft UI consistency issue, though there are precedents for conditional rows elsewhere in the settings. I should check if other conditional searchable settings like "environment-identification" follow the same pattern. I need to verify whether usePrimarySettings and useUpdatePrimarySettings handle server-side settings, since threadAutoSettleAfterDays is now a ServerSettings field. If the update function only patches client settings, the new field won't persist to the server—that would be a real functional regression, not just a UI consistency issue. The routing checks out. Looking at the UI consistency issues in the diff now—the AutoSettleDaysInput component uses a basic input primitive where Enter and blur both commit changes, but since the value gets server round-tripped without optimistic updates, the prop only refreshes after the echo comes back. The draft updates immediately to the parsed string value, which is fine. The Enter key handler doesn't prevent default, though that's probably not an issue since there's likely no form wrapper. I'm also noticing the interaction between the switch toggling thread auto-settle and... With supportsAutoSettle now gating the number input row visibility, the settings search catalog still lists both entries and will try to navigate to anchors that don't exist when those rows are hidden. That's a concrete behavioral change introduced here—the search can scroll to nonexistent targets. I should check how the search handles missing anchors and whether there's precedent for this pattern, like the environment identification row which is also conditionally rendered but still in the catalog. There's precedent for this pattern since environment-identification is conditionally rendered and still cataloged. Looking at the other in-scope changes, I'm checking ChatView.tsx where changeRequestState was removed from ChatHeader and autoSettleOnMerge now pulls from serverConfig settings instead. I need to verify that ChatHeader still correctly passes arguments to useThreadActionMenu and that activeThreadPr isn't sitting unused. In Sidebar.tsx, onChangeRequestState was removed, so I'm checking whether prState is still actually used in SidebarThreadRow or if it's now an unused variable. The sidebar row is now passing autoSettleOnMerge as a per-thread environment setting from serverConfigs, and the useNowMinute import was removed—I need to confirm there's no lingering usage of that. Let me examine the Sidebar row implementation. Checking whether useNowMinute is still referenced elsewhere after removing it from Sidebar and ChatView, since it could be a dead hook now. Then I need to focus on the UI consistency review — scanning through the web files for any changed UI behavior, starting with Sidebar.tsx around line 3508 where autoSettleOnMerge is being set. Looking at how Sidebar and ChatView handle the threadAutoSettleOnMerge setting: Sidebar pulls it from serverConfigs.get(thread.environmentId)?.settings.threadAutoSettleOnMerge defaulting to true, while ChatView uses serverConfig?.settings.threadAutoSettleOnMerge ?? true. Both default to true so they're behaviorally consistent. The changeRequestAutoSettles function still handles the Woke pill suppression the same way, just sourcing the flag differently now. ChatHeader's removal of the changeRequestState prop from the interface and useThreadActionMenu call looks correct. I need to verify whether activeThreadPr is used anywhere else in ChatView after removing it from the memo, since it was previously passed as changeRequestState={activeThreadPr?.state ?? null} — if it's not used elsewhere, that's a potential unused variable error. I need to check where useThreadActionMenu is being called from, particularly looking at ChatHeader since the diff shows changeRequestState was removed from there. Let me search for other callers to understand the full scope of this change. I need to check the useThreadActionMenu hook to see if it still has the useClientSettings import after removing those settlement-related lines, and verify whether supports.settlement is now causing a TypeScript error since it might be unused. The supports.settlement flag still gates the menu items, and the settled partition in Sidebar no longer depends on that capability since effectiveSettled() now checks the settledOverride field that older servers simply won't include. I'm now looking at how the "Woke" pill derives autoSettleOnMerge per thread. The server keys are already routed elsewhere, so that's not a concern. Looking at the AutoSettleDaysInput change, there's a UI consistency issue with the number input type — the native spinner arrows modify the draft value but don't commit until blur, and the same happens with keyboard arrow keys, which feels intentional but worth examining. There's no Escape key handling to revert changes, though that's minor and optional. I'm checking whether there's a shared NumberField primitive in the UI components that ProviderSettingsPanel uses for numeric settings — and yes, there is one with increment/decrement variants. The rule says to prefer core UI primitives over native controls, but AutoSettleDaysInput predates this PR and was already using the raw Input type with number handling. The PR only changed the commit timing, not the primitive choice itself, so demanding a switch to NumberField would be unrelated cleanup. That said, the patch did rewrite the commit logic, which makes the primitive choice relevant again. I should check how NumberField is actually used elsewhere in ProviderSettingsPanel to see if it's the established convention for numeric inputs. I'm noticing the auto-settle days field uses a raw number input with manual clamping logic, which differs from the shared NumberField component used elsewhere in Settings. Since this PR is already touching that commit logic, there's an argument for bringing it in line with the existing pattern, though I need to be careful not to scope-creep into unrelated cleanup. Let me verify how Base UI's NumberField actually handles value changes — specifically whether onValueChange fires on every keystroke or only on commit, since the PR intentionally requires commit-on-blur behavior. Looking at Base UI's NumberField behavior—it fires onValueChange on each keystroke as it parses the input, which doesn't align with the PR's goal of only committing when editing finishes. While Base UI does have onValueCommitted in recent versions, I need to verify if NumberField specifically supports it. Setting that aside, the real concern is the auto-settle toggle behavior. When toggling the switch, there's no optimistic update on the client side, so the checked state won't visually change until the server responds with the updated config. If the RPC round-trip is slow, the UI will feel unresponsive. But I should check whether other server settings already follow this same pattern — if backgroundActivity and automaticGitFetchInterval are also server-persisted settings with controlled switches, then this is just the established convention and not a new inconsistency. Let me look at the ServerSettings fields to confirm. The async round-trip pattern for server settings is already established with existing switches, so that's not a concern. Both Sidebar and ChatView handle autoSettleOnMerge consistently with the same default behavior. ChatHeader's prop removal and corresponding updates at call sites look good, though I should check if there are any remaining UI concerns in the Sidebar implementation. Looking at the timestamp resolution logic, the fallback from settledAt to updatedAt for legacy rows is intentional and tested. Mobile and web sorting are consistent on this front. The effectiveSettled function in Sidebar needs access to fields like latestUserMessageAt and settledAt, which are already present in the SidebarThreadSummary type, so that's fine. I need to verify that changeRequestAutoSettles is still properly exported and used across Sidebar and ChatView, and then confirm whether ChatView's serverConfig reference is pulling from the thread's environment config or the primary config. The thread's environment setup aligns with how the Sidebar reads per-environment. The settings panel gates on the PRIMARY environment capability but applies the setting across all environments, which follows the existing pattern where the General panel only edits the primary environment. There are no CSS or component changes in the diff, so the UI consistency check should come back clear. Now I'm hitting a conflict: the instruction says to respond exactly "All clear" when there are no findings, but the system requires JSON schema output. Since structured output is mandatory, I'll set the state to success with "All clear" in the summary field. Before I finalize though, let me double-check the SettingsPanels component — the AutoSettleDaysInput row uses standard width classes without overriding core geometry, so that's fine. I'm also verifying the accessibility labels are retained, checking whether the supportsAutoSettle capability flag properly gates the UI rows, and confirming that the autoSettleOnMerge prop is consistently provided across all SidebarThreadRow render paths. I need to verify whether removing useNowMinute from the Sidebar component breaks the relative-time labels that display settled timestamps. The mobile version kept nowMinute for snooze label updates, but I should check if the web Sidebar has similar time-relative displays that depend on that re-render trigger, particularly around how settled timestamps are formatted and displayed. I'm realizing that removing useNowMinute() from the Sidebar component creates a real problem — those relative time labels like "2m ago" won't update anymore since they were relying on that hook to trigger a re-render every minute. Without it, the timestamps would stay frozen until something else causes the component to re-render, which is definitely a regression. Let me check whether that hook's return value was actually being used elsewhere or if it was only there for its side effect of forcing updates. So the real issue is whether those inline functions and objects in renderThreadRow are breaking the memo optimization, causing rows to re-render on every parent tick. If that's happening, then the minute-based time labels like "5m" would stay fresh. I need to check if threadTimeLabel is actually being called in the row and whether there's a separate hook managing the time updates, or if it's relying on parent re-renders to refresh the display. The relative time labels in the sidebar are recalculated during render without any internal updates, so removing useNowMinute() from the Sidebar component might actually prevent those labels from refreshing. The real question is whether the memoized SidebarThreadRow components re-render when the parent renders — if their props stay stable, the memo optimization would block re-renders regardless, meaning the minute ticker might not have been refreshing the labels even before this change. I need to check what props are passed to the rows in the render function to see if any of them are inline callbacks or objects that would break memo's shallow comparison and force re-renders. The memo is preventing re-renders when props stay the same, but the minute tick updates nowMinute, which causes the partition memo to recalculate and generate new arrays—though the thread objects themselves remain unchanged. This means row props should be identical, so memo should block the re-render, yet the labels still aren't refreshing. The issue might be tied to callback functions like handleChangeRequestState that are being passed down. Looking at the actual prop flow: wokeAt gets computed from threadWokeAt(thread, {now: snoozeNow}), where snoozeNow is recalculated on each memo run but likely produces the same string value, so memo still blocks. This suggests relative labels weren't minute-ticking through this path even before the PR—not a new regression. Removing useNowMinute from the Sidebar eliminates a per-minute re-render of the shell itself, but I need to check if there are other relative labels rendered directly in the Sidebar outside the memoized rows, like project group headers or search result rows that use threadTimeLabel. Given the uncertainty and the requirement to find concrete regressions rather than speculate, I'm leaning toward no findings here. But let me do one more targeted check of the ChatView and ChatHeader area around lines 4100-4200 to catch any leftover UI prop inconsistencies—specifically whether changeRequestState was removed from the ChatHeader interface but is still being passed to it somewhere else in ChatView. The web layer looks clean with no changeRequestState references. I'm checking UI consistency across the remaining components—useThreadActionMenu properly uses useClientSettings, the merged threads description about server-side application is consistent, and AutoSettleDaysInput correctly resets to default when toggled off then back on. Everything appears aligned. There's a pre-existing accessibility gap where the days input lacks an aria-label (other controls like Switch and SelectTrigger have them), but that's not introduced by this change. Given the schema requirements, I'll format the final response as "All clear" with the title "UI Consistency: All clear" and mark it as success.