Ollama Cloud's /settings page switched shapes for cost-based plans: parse
the 'Monthly usage $X of $Y used' row as a monthly window with a symmetric
'$X / $Y' money label that reads correctly in both used/remaining display
modes, and surface the Extra usage credits balance as a balance-only
credits_balance window matching the Codex/DeepSeek credits treatment
('Credits Balance' in the UI), omitted when the balance is $0. The VS Code
credential validation accepts the new page shape and the Settings cookie
placeholder shows the two-cookie format. Web and VS Code parsers kept in
sync per quota DOCUMENTATION.md.
The parity test fails on main: tr.ts is missing discoverFailed,
discoveringRepositories, retryDiscovery and selectRepositoryPlaceholder,
so 'all locales stay in key parity with english' is red on every run.
Carried in this PR to turn the checks green; drop it if you'd rather
land it separately.
Every updateDesktopSettings PUT replays the server's full settings
document as an openchamber:settings-synced event, and the theme listener
adopted it unconditionally - so switching sessions across directories
(any lastDirectory/activeProjectId write) could flip the theme to
whatever the server document held at that moment. A bootstrap GET with
missing theme fields made it worse: materializeAuthoritativeUiSettings
invented useSystemTheme + openchamber defaults and the persist effect
wrote them back to the server and the scoped localStorage entry.
Theme is now adopted only from bootstrap-grade syncs (the renamed
bootstrap flag, formerly adoptWorkspace), missing fields mean 'not set'
and keep the current preference, and the materializer no longer invents
theme defaults. Cross-window same-instance theme sync still rides the
scoped-key storage event; runtime endpoint switches still adopt the new
instance's server theme.
Closes the 'theme flashes to OpenChamber when switching sessions' report;
same family as the pre-#2897 'color mode forced to light' symptom.
* test(ui): provide sync runtime context in issue-2903 harness
edfc9779c (perf(chat): make session switching feel instant) rewired
useDirectoryStore and friends from the system context to the runtime
context, but this harness only rendered SyncContext.Provider, so the
render phase threw 'useSyncRuntime must be used within <SyncProvider>'
and every PR run since failed this file.
Mirror SyncProvider's own nesting: render the runtime context (read
from its globalThis registry key) inside the system one, with a
currentDirectory source matching the new CurrentDirectorySource
contract. Also drop the chained globalThis type assertions in favor of
one documented cast.
Test-only change; no runtime behavior affected.
* fix(desktop): pair close-button hover with solid error red and its foreground
The classic window-control close button hovered with the
--status-error-background banner wash but colored the glyph with
--status-error-foreground, which each theme authors as the contrast
color for the solid error red (the --destructive pairing). On the wash
the glyph loses contrast in both modes - near-black on muted dark red
in dark themes, white on pale red in light themes - and the dark-mode
wash reads as a muddy saturated red.
Hover now uses the solid --status-error with its authored foreground,
matching the destructive button pairing and the Windows caption-button
convention.
* chore: re-run PR review bot (evidence added at HEAD)
* fix(header): remove right-edge gap before close button with custom window controls
The header root already applied pr-0 for frameless chrome with
right-side controls, but webWindowControlsOverlayStyle set an inline
padding-right on the same element, which overrides the class. In
Electron (frame: false, no titleBarOverlay) the WCO right inset is
always 0, so the close button sat 12px from the window edge and the
top-right corner did not trigger close.
Skip the inline style for the frameless + right case so the class
governs; the browser window-controls-overlay path keeps its padding
and inset reservation.
* fix(desktop): inset right-side traffic lights from the window edge
The header flush-edge fix (pr-0 for frameless + right controls) also
pulled the traffic-lights cluster against the window edge, but the
inset is a Windows-caption convention that only the classic style
follows. macOS-style circles keep their spacing: an explicit 12px
right margin on the right-side cluster, owned by the component so the
mini-chat window matches.
* chore: re-run PR review bot (body now documents the traffic-lights inset)
* feat(desktop): upgrade Electron to 43.3 for Linux frameless rounded corners
- electron ^41.2.1 -> ^43.3.0 (electron/electron#51459/#52111: rounded
corners for frameless windows on Linux, default-on; disable via
roundedCorners: false)
- @electron/rebuild ^3.7.0 -> ^4.2.0 to build native modules against
the new Electron ABI
- pin node-abi to 4.33.0 via root overrides so @electron/rebuild (and
electron-builder's internal rebuild) can resolve Electron 43's ABI
- README: Electron 43 ships its own fixed extractor (extract-zip 2.0.1
Node-24 unpack bug no longer applies; ensure-electron remains a
safety net for interrupted/wrong-arch installs)
* chore: re-trigger pr-review after adding visual evidence
* fix(desktop): scope node-abi to Electron rebuild tooling
* chore: re-trigger pr-review after dependency fix
* chore: re-trigger pr-review with drag evidence
* chore: retry pr-review after evidence confirmation
desktopEntryMatchesApp used a loose substring match that accepted any
desktop entry whose Exec line mentioned a terminal launcher. A non-
terminal app launched via xdg-terminal-exec (e.g. a TUI helper) was
mis-attributed to the generic 'terminal' appId, so 'Open in Terminal'
launched the helper script and the picker showed the helper's icon.
For appId === 'terminal' only, require Categories=TerminalEmulator;
ghostty/iterm2 keep name-based matching. The xdg-terminal-exec /
gnome-terminal / konsole / xfce4-terminal / x-terminal-emulator fallback
chain is unchanged, so non-conformant custom terminal entries still
launch. Adds a shared isTerminalEmulatorEntry predicate used by both
buildLinuxOpenSpecs (launch) and buildLinuxInstalledApps (icon).
Smoke test gains a generic helper-app fixture (non-terminal app whose
Exec uses xdg-terminal-exec) plus a TerminalEmulator entry, with
assertions that the helper script is never launched and the terminal
emulator's icon resolves instead of the helper's. Two byte-distinct
PNGs keep the icon assertion a real discriminator.
Pablo Gonzalez