The 4 client-action SCSS files I shipped in Phase 6 ignored the
project's documented design system (CLAUDE.md "Card Styling" + "Dark
Mode" rules) and used hardcoded hex / var(--bs-*) for surfaces.
Result: dark mode rendered white-text-on-white-card.
Companion to "changes" (22573e7) which already landed
_fp_jobs_tokens.scss + the job_plant_overview.scss refactor.
This commit finishes the job:
- Refactored job_process_tree.scss, job_manager_dashboard.scss and
job_tablet.scss to reference the $fp-* tokens — zero hardcoded
hex on theme-sensitive surfaces. Three-layer contrast applied per
CLAUDE.md (page → container → card).
- Process tree keeps the intentional Steelhead-style dark-slate
card fill in BOTH bundles (deliberate visual choice, not a theme
bug); page / header / connectors / empty state are now token-
driven so they look right against light or dark page surfaces.
- Manifest assets list reordered so _fp_jobs_tokens.scss compiles
first in web.assets_backend (CLAUDE.md rule: SCSS variables in
earlier files are visible to later files in the same bundle).
This is what makes the compile-time
$o-webclient-color-scheme branch in the partial actually take
effect for the four consumer files.
Verified on entech: light bundle (web.assets_backend) and dark
bundle (web.assets_web_dark) both compile without SCSS errors and
emit distinct surface hexes (light: #f3f4f6 page / #ffffff card;
dark: #1a1d21 page / #22262d card).
Manifest 19.0.3.0.0 → 19.0.3.1.0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>