mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-23 16:36:23 +00:00
afd0270a64
Live theme authoring's core loop — Hermes recolors the skin file it just activated — repainted the TUI but not the GUI. The event path was fine (post-#69533 the WS broadcast lands and ingestBackendSkin refreshes the $backendThemes registry); the same-name apply guard also no-ops correctly (it's what protects a manual desktop theme pick). The repaint was supposed to come from the registry: the active theme IS that skin, its palette just changed. But ThemeProvider memoized deriveTheme on [themeName, resolvedMode] only, while deriveTheme reads the registry non-reactively via resolveTheme — so the store update re-rendered the provider and handed back the stale palette. Name switches repainted (themeName moves); recolors never did. Add the theme stores (user/backend/registry) to the memo's deps — they are deriveTheme's actual reactivity, same as the availableThemes memo directly above. applyTheme is idempotent, and $backendThemes only publishes on a real palette change, so no spurious repaints. Tests: render ThemeProvider for real — activation applies; a same-name recolor repaints (fails without the fix); an inactive-skin seed doesn't touch the painted theme. |
||
|---|---|---|
| .. | ||
| bootstrap-installer | ||
| desktop | ||
| shared | ||