Skip to content
sdlc

B-X2AF-the-sdf-dashboard-hardcodes-hexes-and-light-mode-is

The sdf desktop dashboard paints itself with hardcoded hexes in scoped <style> blocks instead of --d-* tokens. The hexes are dark-mode values stated unconditionally, with no .dark guard, so light mode renders dark ink on a light ground. The result is user-visible: text that is nearly invisible.

Found during the visual pass on T-ROYV-design-language-layer-consumer-hygiene. Pre-existing, and independent of that change — it reproduces on origin/main.

The failing surface

Section titled “The failing surface”

solutions/ontological/desktop/src-nuxt/app/components/dashboard/ActiveWorkView.vue declares, at line 101, inside <style scoped>:

main {
  color: #d7dce5;
}

#d7dce5 is the dark-theme ink. It is stated on main with no mode guard, so it applies in light mode too. The <h1>SDF Active Work</h1> at line 42 inherits it and renders near-white on the light --d-bg-base (#eaecf0). The heading is effectively unreadable.

The same block dresses the polling and Reload buttons as dark pills on a light page:

button {
  background: #222836;
  color: #d7dce5;
  border: 1px solid #262b36;
}

Extent

Section titled “Extent”

Within solutions/ontological/desktop/src-nuxt/app/components/:

  • 22 files contain a six-digit hex.
  • 219 hex occurrences, 37 distinct values.

Ten files carry the specific #d7dce5 / #222836 pair, so the pattern is consistent rather than a single slip:

dashboard/ActiveWorkView.vue        dashboard/TasksPanel.vue
dashboard/TaskOperationalPanel.vue  dashboard/LeasesPanel.vue
dashboard/OrchestratorLogPanel.vue  dashboard/PrVerdictBoard.vue
dashboard/TokenSettings.vue         dashboard/LocalWorkPanel.vue
dashboard/PullRequestsPanel.vue     agent-pants/SkillRosterPanel.vue

The remaining hexes are status and accent literals (#f97316, #ef4444, #8a93a3, #3b4658), which are their own --d-* token gaps.

Why this is worth an entry rather than a note

Section titled “Why this is worth an entry rather than a note”

It is a direct S-0010-design-language-consumption violation: a live UI surface expressing appearance in raw hexes rather than through --d-* tokens, with the dark-mode branch baked in rather than routed through the .dark seam.

It is the third instance of one pattern this program has produced — an unreadable surface that every static check passed. The augmented_web ink-token inversion and the agent-pants theme-blind accent were the first two. Nothing in typecheck, lint or unit tests catches a wrong-but-valid colour; only looking at the rendered page does.

It also sits inside a counted baseline. The raw-palette guard being built in a sibling stream enrols ontological/desktop at baseline 221 for hex. Without this entry, a reader of that number sees a debt figure and not a broken heading.

Fix direction

Section titled “Fix direction”

Replace the hardcoded pairs with the contract tokens they are impersonating: --d-text-primary for the ink, --d-bg-elevated and --d-border for the button chrome, --d-text-muted for the secondary greys. The theme preset in solutions/ontological/desktop/src-nuxt/app/assets/css/d-tokens.css already supplies correct values for both modes, so the tokens resolve mode-correctly on arrival and no new vocabulary is needed.

Verify by looking at the app in both modes, not by rerunning the type checks — they were green throughout.

← Back to Backlog