[WSL2] Dashboard.jsx: residual hardcoded #0d0b12 in info tooltip — light-theme contrast gap (companion to PR #865 / 30c1c34)

[yasinBursali]

Environment

• OS: Windows / WSL2 Ubuntu, kernel 6.6.87.2-microsoft-standard-WSL2
• Docker version: 29.3.1
• DreamServer commit: local QA branch off upstream/main cd11612 + merged PRs feat(dashboard): status tooltips, legend, and Extensions visual alignment Light-Heart-Labs/DreamServer#865, fix(macos-installer): guard Bash 4+ and auto-install via Homebrew Light-Heart-Labs/DreamServer#889, fix(dashboard-api): invalidate .compose-flags via host agent on mutations Light-Heart-Labs/DreamServer#890, fix(extensions): clean up stale progress files on disable/uninstall Light-Heart-Labs/DreamServer#891, fix(extensions): clean up stale progress files on purge Light-Heart-Labs/DreamServer#892
• GPU: NVIDIA RTX 3070 Laptop (not relevant — UI bug)

Description

Upstream commit 30c1c34 ("fix: replace hardcoded colors with theme variables for light theme compat") landed alongside PR Light-Heart-Labs#865 and replaced hardcoded #0d0b12 color literals with theme variables (bg-theme-card, etc.) on dashboard/src/pages/Extensions.jsx. The commit message lists "Tooltip backgrounds, toast notifications, input fields, card footers, filter pills, and GPU badges" as the in-scope items.

A grep of the built dashboard JS bundle in the running dream-dashboard container finds one residual #0d0b12 literal in Dashboard-BOq-Uz6E.js (a Vite code-split chunk for the Dashboard page, which 30c1c34 did not touch — git show --stat 30c1c34 lists only Extensions.jsx).

Source location

dream-server/extensions/services/dashboard/src/pages/Dashboard.jsx, line 518 — the group/info info tooltip:

className="... bg-[#0d0b12]/95 px-3 py-2 text-[11px] leading-4 text-theme-text-muted"

Steps to reproduce

docker exec dream-dashboard sh -c 'grep -o ".\{40\}#0d0b12.\{40\}" /usr/share/nginx/html/assets/Dashboard-*.js'
# -> ... bg-[#0d0b12]/95 px-3 py-2 text-[11px] leading-4 text-theme-text-muted ...

grep -n '#0d0b12' /home/rosenrot/DreamServer/dream-server/extensions/services/dashboard/src/pages/Dashboard.jsx
# -> 518: ...bg-[#0d0b12]/95...

Expected behavior

In light theme, this info tooltip should use a theme-aware background (the same bg-theme-card substitution that 30c1c34 used elsewhere) so it stays legible against light backgrounds. Currently it forces a near-black tooltip background regardless of theme.

Actual behavior

The tooltip is hardcoded to #0d0b12 with 95% opacity, identical to the old (pre-30c1c34) Extensions.jsx pattern that was explicitly fixed.

Suggested fix

One-line substitution mirroring 30c1c34's pattern:

- bg-[#0d0b12]/95
+ bg-theme-card/95

(Or whichever theme token 30c1c34 chose for the equivalent Extensions.jsx tooltip.)

Severity

Low. Cosmetic / accessibility — only affects the info tooltip on the Dashboard page and only when the user is in light theme. Does not block any functionality.

Out-of-scope context

This issue is not a regression in PR Light-Heart-Labs#865 — both PR Light-Heart-Labs#865 and 30c1c34 explicitly scoped only Extensions.jsx. Filing this as a follow-up so the same theme cleanup can be applied to Dashboard.jsx. Found during a QA pass on the merged PR stack while validating PR Light-Heart-Labs#865.

[yasinBursali]

Verification Result — CONFIRMED (still present on main)

Verified against: upstream/main at c0600ca3
Platform scope: All platforms (Linux, macOS, Windows/WSL2) — reasoning below

Evidence

File: dream-server/extensions/services/dashboard/src/pages/Dashboard.jsx, line 518

<div className="pointer-events-none absolute bottom-[calc(100%+0.45rem)] right-0 z-20 w-52 rounded-lg border border-white/10 bg-[#0d0b12]/95 px-3 py-2 text-[11px] leading-4 text-theme-text-muted opacity-0 shadow-2xl transition-all duration-150 group-hover/info:translate-y-0 group-hover/info:opacity-100 translate-y-1">

Commit 30c1c343 (git show --stat 30c1c34):

 .../services/dashboard/src/pages/Extensions.jsx    | 34 +++++++++++-----------
 1 file changed, 17 insertions(+), 17 deletions(-)

Dashboard.jsx was not touched by 30c1c34. The fix was scoped exclusively to Extensions.jsx.

Scope of #0d0b12 across the entire src/ tree: Only one occurrence — Dashboard.jsx:518. No other residuals.

Analysis

The hardcoded bg-[#0d0b12]/95 on the info tooltip at line 518 is confirmed present on upstream/main at c0600ca3. Commit 30c1c34 replaced the equivalent pattern in Extensions.jsx but Dashboard.jsx was outside that commit's diff. The issue reporter's source location, line number, and class string are all exact matches to the live code.

The WSL2 label is misleading — this is a pure React/Tailwind theming issue in a static JSX class string. The tooltip renders with the same hardcoded dark background on all platforms (Linux, macOS, Windows/WSL2) whenever the user selects a light theme. There is no OS-specific code path involved.

---

Verified via static code analysis on 2026-04-11. This comment was added by an automated verifier.

[yasinBursali]

Live Browser Verification (supplement to static analysis)

Environment: Fresh install of upstream/main @ c0600ca on macOS Apple Silicon, running at http://localhost:3001/, visually tested via Claude-in-Chrome on 2026-04-11.

Confirmed via live DOM inspection

The tooltip element at Dashboard.jsx:518 renders on the live Dashboard page. Its computed background is locked to rgba(13, 11, 18, 0.95) regardless of which theme is active:

Theme	Page background	Tooltip background
dream (dark, default)	rgb(15, 15, 19)	rgba(13, 11, 18, 0.95) — matches intent
light	rgb(244, 244, 245)	rgba(13, 11, 18, 0.95) — near-black bubble on white page
lemonade	rgb(240, 232, 207)	rgba(13, 11, 18, 0.95) — near-black bubble on cream page
arctic	rgb(240, 247, 255)	rgba(13, 11, 18, 0.95) — near-black bubble on pale-blue page

Nuance on the "contrast gap" framing

The issue title says "light-theme contrast gap". Worth noting that the actual WCAG text-on-tooltip contrast is identical across all themes (7.63:1, passes AAA) because the text-theme-text-muted token resolves to rgb(161, 161, 170) in every theme. So there is no WCAG accessibility failure inside the tooltip.

The real defect is visual-system inconsistency: the tooltip ignores the theme surface tokens entirely, so on any non-dark theme it renders as a dark rectangle floating on a light page. It's a design-system leak, not a contrast-ratio violation.

Scope

Three non-dark themes are affected (light, lemonade, arctic), not just light / WSL2. Platform scope remains all platforms — the JSX class string is static.

---

Live browser verification via Claude-in-Chrome at http://localhost:3001/ on 2026-04-11. Automated verifier.

[yasinBursali]

Fixed by Light-Heart-Labs#895 (draft).

[yasinBursali]

Verified at runtime — PR Light-Heart-Labs#895's theme token holds on the integration branch

Environment: WSL2 / Ubuntu 24.04 / NVIDIA RTX 3070 Laptop / Tier 1
Branch: local/integration-test (PR stack Light-Heart-Labs#893–909 merged onto Light-Heart-Labs/DreamServer@c0600ca)
Install: bash install.sh --all --non-interactive --no-comfyui → phase 13, 17 healthy containers (dream-dashboard rebuilt from source during the install)

What I tested

1. Source check on the integration branch's Dashboard.jsx for the literal #0d0b12 and the new bg-theme-card token usage.
2. Bundle check inside the deployed dream-dashboard container — confirmed the rebuilt assets contain references to the theme token.

Result

Source (integration branch):

$ grep -n "0d0b12" dream-server/extensions/services/dashboard/src/pages/Dashboard.jsx
(no match — hardcoded color is gone)

$ grep -n "bg-theme-card" dream-server/extensions/services/dashboard/src/pages/Dashboard.jsx
206:        <div className="h-8 bg-theme-card rounded w-1/3 mb-4" />
210:            <div key={i} className="h-40 bg-theme-card rounded-xl" />
350:        <div className="liquid-metal-frame liquid-metal-frame--soft flex items-center gap-4 text-xs text-theme-text-muted font-mono bg-theme-card border border-theme-border rounded-lg px-3 py-2">

Built bundle inside the live container:

$ docker exec dream-dashboard sh -c 'grep -lE "bg-theme-card|--theme-card" /usr/share/nginx/html/assets/*.css /usr/share/nginx/html/assets/*.js'
/usr/share/nginx/html/assets/index-ZKvbaKnW.css
/usr/share/nginx/html/assets/Dashboard-B5PGRDYw.js
/usr/share/nginx/html/assets/Extensions-DkkjpvxK.js
/usr/share/nginx/html/assets/Models-wDME1MUL.js
/usr/share/nginx/html/assets/Settings-K1hZ2xyK.js

Theme token is referenced in both the source and the deployed bundle. #0d0b12 is gone from Dashboard.jsx. The --theme-card CSS variable is defined in index.css for all four theme modes (dark, lemonade, light, high-contrast — confirmed in Phase 1 static review).

Status

PR Light-Heart-Labs#895's fix holds. This issue can stay closed.

What was NOT tested

Visual / pixel-level validation in a real browser — Claude Code's chrome integration isn't supported on WSL2. The structural evidence is solid: the JSX renders the token, the bundle contains it, the theme defines it.

---

Verified during full-stack integration test of open PR stack Light-Heart-Labs#893–909.