🐛 Bugfix: Theme.service added light-theme class when dark theme was ac...

Date: 2026-02-25
Time: 21:47:09 UTC
Session: gspace1-143.1
Agent: angular
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Theme.service added light-theme class when dark theme was active — html had conflicting theme-dark + light-theme. How to sync light-theme/dark-theme with active theme mode?

Task: Not specified

🎯 Decision Made

Chosen:

B) Make isDarkMode prefer activeTheme()?.mode when available, sync preferredMode on applyTheme

Options Considered:

1. A) Remove Theme.service updateThemeClass entirely, rely only on ThemeApplicationService
2. B) Make isDarkMode prefer activeTheme()?.mode when available, sync preferredMode on applyTheme
3. C) Merge both services into one

💭 Reasoning

ROOT CAUSE: Theme.service.isDarkMode was computed from effectiveMode (preferredMode or systemMode). preferredMode defaults to LIGHT and was never updated when applying a theme. ThemeApplicationService correctly set theme-dark from theme.mode, but Theme.service added light-theme from effectiveMode=LIGHT. Both services modify html element. FIX: (1) isDarkMode computed now prefers activeTheme()?.mode when theme is loaded, else effectiveMode. (2) applyTheme() calls stateService.setPreferredMode(theme.mode) on success so preferredMode stays in sync. This preserves both services, fixes the conflict, and ensures ux-smart-theme-utilities.scss selectors ([data-theme="dark"], .dark-theme) work correctly.

📁 Files Involved

• libs/theme-system/theme-runtime/src/lib/services/theme.service.ts

🔗 Related

• Decision ID: dev_1772056029566_ebq93m2
• Session: 143 (migrated from 142 — user had set_session(143) at start; MCP used active session 142)
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation. Moved to S143 per user request.