@dashforge/tw: <Accordion> hardcodes light-mode neutral classes, breaks in dark mode (G-22)

[kensaadi]

Symptom

@dashforge/tw@1.1.1 <Accordion> items hardcode light-mode Tailwind classes (border-neutral-200, text-neutral-700, text-neutral-500, text-neutral-400). In dark mode (data-dash-tw-theme="dark"), these neutrals do NOT invert automatically — dividers become invisible against dark backgrounds, and secondary text drops to near-invisible contrast.

Why this is bad

• Users switching to dark mode see broken Accordion chrome without any explicit override on their side
• Consumer forced to scope CSS overrides with [data-app='builder'] .accordion-item { … } to patch appearance
• Contradicts the Dashforge default preset contract — neutral tokens are expected to auto-invert via the preset CSS var swap; components must not defeat that by hardcoding raw Tailwind neutrals

Discovered while

Refactoring the Blueprint Builder V2 shell. Filed in Blueprint's dogfood report as G-22 (severity: medium — visible regression in dark mode).

Workaround applied in Blueprint

Scoped CSS overrides in tokens.css using [data-app='builder'].

Acceptance

• Accordion item internal classes swap to token-driven equivalents (border-[var(--dash-border)], text-[var(--dash-text-*)] etc.) so the preset CSS var swap does the right thing in both modes
• Visual verification in dashforge-docs-lab playground (light + dark toggle) — dividers visible and secondary text at readable contrast in both modes
• Regression test: render Accordion under data-dash-tw-theme="dark" and assert computed border color is not the light neutral-200 rgb value

Related

• Adjacent to [1.2.0] Component Defaults System — theme.components + slotProps (Option C) #60 Option C — the slotProps API will make internal styling more overridable, but the DEFAULT should already be dark-safe
• Same class of bug likely present on other components — G-18 in Blueprint report noted <Chip variant="outline" color="neutral"> invisible in dark mode. Worth an audit sweep across the catalog

[kensaadi]

Not reproducible against @dashforge/tw@1.1.1 + dashforgePreset() correctly wired. Live empirical check on dash:

Repro attempt (dash, current HEAD)

Live browser test — created a div with the exact classes Accordion uses (border-b border-neutral-200 text-neutral-700), then flipped mode via setMode() and read getComputedStyle():

Property	Light	Dark	Changes?
border-neutral-200 → borderBottomColor	rgb(229, 229, 229)	rgb(38, 38, 38)	✅ inverts
text-neutral-700 → color	rgb(64, 64, 64)	rgb(212, 212, 212)	✅ inverts

The dividers and secondary text ARE dark-safe — the entire neutral palette auto-inverts through the CSS-var swap the preset installs.

Why this works

dashforgePreset() remaps every color shade to a CSS-var reference:

// dashforgePreset.ts (colorScaleToCssVarRefs)
out[tone] = `rgb(var(--df-tw-color-${role}-${tone}) / <alpha-value>)`;

so border-neutral-200 at Tailwind's build step compiles to border-color: rgb(var(--df-tw-color-neutral-200) / 1). DashforgeTailwindProvider updates --df-tw-color-neutral-200 from 229 229 229 (light) to 38 38 38 (dark) whenever setMode() runs. No dark: variant needed — using one on neutrals would actually double-invert.

Existing coverage that pins this invariant:

• dashforgePreset.spec.ts:41-50 asserts every color shade (including all 11 neutral tones) is wrapped as rgb(var(--df-tw-color-…) / <alpha-value>).
• DashforgeTailwindProvider.spec.tsx asserts the provider rewrites --df-tw-color-neutral-50 (and by extension every other shade) on setMode.

Together those two guarantee the pipeline end-to-end: the class compiles to a CSS var reference AND the reference gets rewritten on mode change. No third test is needed.

Most likely explanation for the Blueprint symptom

The Blueprint tailwind config was probably missing dashforgePreset() in its presets array (or importing it incorrectly). Without the preset, Tailwind falls back to its default neutral palette, which is fixed color literals (neutral-200: #e5e5e5) that never change with mode. That would reproduce the reported symptom exactly — dividers invisible on dark backgrounds — without any bug in Accordion itself.

Sanity-check for future Blueprint dogfood:

// tailwind.config.js — MUST have this
import { dashforgePreset } from '@dashforge/tw-theme';
export default {
  presets: [dashforgePreset()],
  content: ['./src/**/*.{ts,tsx}', './node_modules/@dashforge/tw/dist/**/*.{js,mjs}'],
};

Closing as not reproducible. If Blueprint hits this again after confirming the preset is wired, please reopen with a minimal repro repo showing the exact tailwind config — the diagnosis will start there.

Adjacent risk mentioned in the issue

Same class of bug likely present on other components — G-18 in Blueprint report noted <Chip variant="outline" color="neutral"> invisible in dark mode.

That falls under the same root cause — if the preset is wired correctly, the neutral CSS-var swap covers Chip too. Worth a live check on Blueprint's actual config before opening a separate audit issue; the components almost certainly are not the problem.