2 Commits

Author	SHA1	Message	Date
程序员阿江(Relakkes)	137895f23e	fix(test): isolate the appearance cache from a real CLAUDE_CONFIG_DIR ... The same suite passed under `check:desktop` and failed under `check:coverage` — 271 files and 3332 tests either way, with one case red in the second: "returns null rather than throwing on a missing or corrupt cache" read back `{isDark: true, background: '#201D17', ...}`, which is exactly what the case above it writes. `appearanceStatePath` resolves `env.CLAUDE_CONFIG_DIR` before falling back to `app.getPath('home')`, and these cases passed no env, so they defaulted to `process.env`. `check:coverage` runs its suites through `createSandboxedTestEnvironment`, which sets CLAUDE_CONFIG_DIR (scripts/pr/test-environment.ts:74). With it set, the per-case temp directories from `makeApp()` stop deciding anything: every read and write collapses onto one shared file, and `afterEach` only removes the temp directories, never that file. So the round-trip case wrote it and the missing-cache case read it. Only that one case is ordered to notice — the others write before they read. Nothing about the product is wrong here: defaulting to `process.env` is what the shipped code should do, and a portable install setting CLAUDE_CONFIG_DIR is a supported mode. The defect is that the tests never opted out of it. Each case now passes the isolated env `makeApp()` hands back, which is the convention `windows.test.ts` already follows for the same path shape (it threads `{}` or `{CLAUDE_CONFIG_DIR: tmp}` through every call). Verified both ways: with CLAUDE_CONFIG_DIR set — the condition that reproduced the failure — and without it, 23/23 each time. `check:coverage` now reports 5/5 suites, and `check:desktop` stays green. `sidecarManager.ts` and `windows.ts` resolve paths the same way; their suites were checked and already pass an explicit env.	2026-07-27 07:49:12 +08:00
程序员阿江(Relakkes)	5b891151ae	feat(desktop): follow the system dark/light appearance (#1106) ... An Auto-dark-mode user reported being flashed by a white window every evening, then switching to a dark palette by hand. That is two defects, and only one of them is the missing feature. The flash fired even for someone who had already saved a dark palette. `index.html` hardcoded `data-theme="white"` while the code that reads the stored theme, `initializeTheme()`, only runs after the app bundle's dynamic imports resolve. So every launch painted white first. A synchronous inline script now resolves the theme before any stylesheet is parsed, and Electron seeds `backgroundColor` from a cached appearance so the window is not white before the renderer's first frame either. Following the system is a switch in Settings -> General rather than a seventh palette. The OS only reports dark/light while the app ships six palettes, so each ground carries its own preference: the picker splits into "use in light mode" (the four paper grounds) and "use in dark mode" (the two ink ones), and a pick lands in the preference for its own ground. Choosing ink-blue at noon is therefore remembered for that night rather than fighting the OS. Detection goes through `prefers-color-scheme` because the same renderer runs under Electron, the Tauri shell and the browser entry, and the media query is the only signal all three share. New installs follow the system; existing ones keep their fixed palette until they opt in, so an update never silently repaints someone's app. `nativeTheme.themeSource` is deliberately left alone, which is the part most likely to be "fixed" later. Pinning it to the user's palette would make context menus and the macOS frame agree with the app, but it is a process-wide override of `prefers-color-scheme` — the very signal this feature reads. Re-enabling the switch would then resolve against the pinned value instead of the real OS setting, and the override also leaks into the preview WebContentsView, forcing third-party pages to the app's theme. A test fails on any assignment to it. The OS-flip listener reads the preferences from storage rather than from its own store. The pet and trace windows run the same bootstrap with their own store instance over one shared localStorage, so after the main window turns the switch off their in-memory copy still says "on" — acting on it wrote the user's choice straight back out. A `storage` listener catches the other windows up. `settingsStore.theme` is gone. It was a copy that only refreshed on an explicit `setTheme`, so an OS flip left the Settings picker highlighting a palette that was no longer on screen. uiStore owns the theme; the copy had no remaining readers. The 「纸·墨·印」 rename reaches the new keys too: `light` -> `warm-classic` now migrates for the per-ground preferences, not just the applied theme, so the palette daytime returns to is not silently reset. Guards, each verified by breaking what it protects: the inline script is extracted from `index.html` and run verbatim against `resolveAppliedTheme` over every stored combination — including dirty values, which are reachable because it runs before the persistence migrations, and cross-ground values like a dark palette stored as the light preference; the three copies of the palette grounds (CSS `--cc-bg`, `index.html`, main process) are pinned to each other and to `THEME_MODES`, so a seventh palette cannot ship without a pre-paint color; the two grounds are proven to cover every palette at compile time; and the IPC payload is held to a literal 6-digit hex because `setBackgroundColor` also accepts `#AARRGGBB`, where a translucent window means click-through and overlay spoofing.	2026-07-27 02:15:37 +08:00