Epic: Portal App Dark Theme

Input from Gemini 3 Pro:

✦ I have completed the implementation of the Portal App Dark Theme infrastructure and initial switching logic.

Summary of Changes:

1. Theme Infrastructure:

   • Created resources/scss/theme-neo-dark and populated design-tokens.
   • Inverted Semantic.scss mappings to map semantic variables to dark core tokens (e.g., backgrounds are now gray-900).
   • Updated root selectors in Core.scss, Semantic.scss, and Component.scss to .neo-theme-neo-dark.

2. UI Updates:

   • Refactored apps/portal/view/HeaderToolbar.mjs:
     • Removed the Slack icon.
     • Added a "Switch Theme" button (Moon icon) with handler: 'onSwitchTheme'.

3. Controller Logic:

   • Updated apps/portal/view/ViewportController.mjs with onSwitchTheme.
   • The logic toggles this.component.theme between neo-theme-neo-light and neo-theme-neo-dark.
   • Updates the button icon dynamically (Sun/Moon).

4. Configuration:

   • Added neo-theme-neo-dark to apps/portal/neo-config.json to ensure the CSS is loaded.

The foundation is now in place. Future iterations can focus on fine-tuning the visual assets (logos) and specific component overrides if needed.

Input from Gemini 3 Pro:

✦ Progress Update: Dark Theme Implementation

We have successfully established the dark theme infrastructure and updated the core form and container components.

Completed:

• Infrastructure: Created theme-neo-dark structure and replicated all SCSS files from theme-neo-light.
• General Components: Updated Toast, Chip, StatusBadge, Process, Progress, Splitter, DateSelector, Video, BoxLabel.
• Containers: Updated Accordion, AccordionItem, Viewport, Panel.
• Forms: Updated Fieldset, Text, CheckBox, Picker, Switch, Triggers.

Remaining Work (To Be Done in Next Session): The following component categories still contain hardcoded light-theme colors and need to be updated to use dark theme semantic tokens:

1. Data Views:

   • grid/ (Container, Body, Header)
   • table/ (Container, Body, Header)
   • list/ (Base)
   • tree/ (List)

2. Navigation:

   • tab/ (Container, Strip, Header)
   • menu/ (List, Panel)
   • toolbar/ (Base)

3. Complex Components:

   • calendar/ (Views, Containers)
   • dialog/ (Base)
   • tooltip/ (Base)
   • draggable/ (SortZones)

4. Application Specifics:

   • apps/ (Portal, Docs, etc. need review for specific overrides)

Next Steps: Start a new session to tackle the Data Views (grid, table, list, tree) as the next logical chunk.

Input from Gemini 3 Pro:

✦ Progress Update & Handoff Instructions

We have completed the implementation of dark theme support for all core component categories (Data Views, Navigation, Complex) and the main application overrides.

Completed:

• #8734 Data Views
• #8735 Navigation
• #8736 Complex Components
• #8737 Apps (Portal, Docs, AgentOS, Covid)

In Progress: Portal App Refactoring (#8738) We started refactoring the Portal App's source SCSS to support theming, but significant work remains. Many source files (e.g., in shared/content/) still use hardcoded hex values.

Instructions for Next Session:

1. Scan & Refactor: Continue scanning resources/scss/src/apps/portal/ (especially shared/content/) for hardcoded colors.
2. Strategy:
   • Do NOT change the Light Theme: Create app-specific CSS variables. In resources/scss/theme-neo-light/apps/portal/..., define these variables using the original hardcoded hex values.
   • Dark Theme Mapping: In resources/scss/theme-neo-dark/apps/portal/..., map these same variables to our semantic tokens (e.g., var(--sem-color-bg-neutral-default)).
   • Flexibility: This indirection allows us to tweak the dark theme implementation without risking any regressions in the default light theme.

Next Targets:

• resources/scss/src/apps/portal/shared/content/SectionsContainer.scss
• resources/scss/src/apps/portal/shared/content/TreeList.scss
• Any other files in src/apps/portal with hardcoded colors.

Input from Gemini 3 Pro:

✦ Refactoring complete. All identified SCSS files in the Portal App have been updated to support theming via CSS variables.

Summary of Refactoring:

• Core Components: shared/content/ (SectionsContainer, TreeList, Container, PageContainer)
• Header: HeaderToolbar
• Sub-apps: about, services, home (BaseContainer, How), news (tickets/Component)
• Navigation: shared/TabContainer

Approach:

• Light Theme: Variables map to original hardcoded hex values to ensure zero visual regression.
• Dark Theme: Variables map to semantic tokens (e.g., --sem-color-bg-neutral-default).

Remaining:

• FooterContainer (Black by design)
• examples/List & medium/List (Dark overlays by design)

We are now ready to tackle offscreen canvas theming in a separate effort.

Input from Gemini 3 Pro:

✦ Task complete. Theme persistence is implemented and refactored.

Input from Gemini 3 Pro:

✦ I have implemented the auto-detection logic.

Changes:

1. Updated DefaultConfig.mjs: Added prefersDarkTheme (default: false) with clear documentation.
2. Updated src/worker/Manager.mjs: Enhanced detectFeatures to check matchMedia('(prefers-color-scheme: dark)') and update Neo.config.prefersDarkTheme before workers are created. This ensures the correct value is propagated during the initial worker handshake without requiring a secondary remote call.
3. Updated ViewportController.mjs: Modified onConstructed to use Neo.config.prefersDarkTheme as the fallback if no local storage preference exists.

The implementation is efficient, avoiding unnecessary post-startup configuration synchronization.

Input from Gemini 3 Pro:

✦ I have implemented the automatic theme synchronization for the Monaco Editor wrapper.

Changes:

1. New Config: Added useThemeAwareness_ (Boolean, default true) to src/component/wrapper/MonacoEditor.mjs. This allows developers to opt-out of automatic theme mapping if they need a specific, fixed editor theme regardless of the application theme.
2. Theme Mapping Logic: Implemented afterSetTheme. It detects changes to the inherited theme config (propagated by container.Base), maps it (dark -> vs-dark, light -> vs), and updates the editorTheme config accordingly. This ensures both initial rendering and runtime switches are handled correctly.
3. Dynamic Toggling: Implemented afterSetUseThemeAwareness to immediately apply the current theme if the feature is enabled at runtime.

This solution provides a "batteries-included" experience for the Portal App and all other Neo.mjs applications using this wrapper, while maintaining flexibility.

Input from Gemini 3 Pro:

✦ I have resolved the 1px background glitch.

Changes:

1. Refactored SCSS: Updated resources/scss/src/component/wrapper/MonacoEditor.scss to use the CSS variable var(--monaco-editor-background-color).
2. Theme Definitions: Created the following theme files using the correct :root .neo-theme-... scoping pattern:
   • resources/scss/theme-neo-dark/component/wrapper/MonacoEditor.scss: Sets variable to #1e1e1e.
   • resources/scss/theme-neo-light/component/wrapper/MonacoEditor.scss: Sets variable to #fffffe.

This ensures the wrapper background visually matches the editor canvas, masking the sub-pixel rendering artifact.

Input from Gemini 3 Pro:

✦ I have corrected the dark theme colors for HighlightJS.

Changes:

1. Updated resources/scss/theme-neo-dark/util/HighlightJs.scss: Applied a GitHub Dark inspired palette (dark background #0d1117, light syntax highlighting colors) to replace the incorrect light theme values.
2. Updated resources/scss/theme-neo-dark/util/HighlightJsLineNumbers.scss: Applied dark background and dim text colors for line numbers.

Since the SCSS variables are scoped to .neo-theme-neo-dark, and Neo.util.HighlightJs ensures the CSS files are loaded, switching the theme on the Portal Viewport will now automatically apply these corrected styles to all markdown code blocks.

Input from Gemini 3 Pro:

✦ I have fixed the theme propagation issue for embedded Markdown components.

Changes:

1. Updated src/component/Markdown.mjs: Modified the render method to include theme: me.theme in the baseConfigs object.

Impact: All components instantiated by the Markdown renderer (LivePreview, Mermaid, custom components) will now inherit the current theme of the Markdown component upon creation. This ensures that when a user navigates to a new view (triggering a fresh Markdown render), the embedded components correctly initialize in Dark Mode if active, instead of falling back to the Light Mode default. This completes the loop with the useThemeAwareness feature added to the Monaco wrapper.