v3 used the green wash #eaf3ea for --surface-primary, the page background,
which read as too green. Replaced with the palette read from the DEPLOYED
CSS of the dashboard, portal and panel (identical across all three):
--surface-primary #eaf3ea -> #faf8f5 (cream, page background)
--surface-tertiary green -> #f4f2ec (warm chip)
--surface-hover green -> #f0ede6 (warm hover)
--surface-composer-hover -> #f0ede6
--border-light #cde0cb -> #e4e0d8 (warm neutral border)
--presentation #eaf3ea -> #faf8f5 (composer band)
--link #4a7a4a -> #4e7a4d (deeper green, 4.70:1 on cream)
Accents are unchanged (green-deep #5b8c5a, green-mid #6ba86b) — they are
the earthy greens the co-op design system already uses. Dark mode is
untouched. Also fixed the two hard-coded washes: the #loading-container
flash and the bare html/body background, plus custom2.js COOP_BG.light,
which was still painting the browser/PWA chrome #eaf3ea while the
manifest said cream.
The Oct 19 theming (light = #eaf3ea dashboard green wash, white cards/surfaces,
per approval) was never committed - the Oct 21 pin-migration rebuild from this
repo silently reverted the deployed theme to the older cream iteration.
- custom.css: light block restored to the approved green-wash palette
(primary #eaf3ea, white secondary/chat cards, green hover/tertiary/border);
loading screen + bare page background match.
- Dockerfile: manifest theme_color/background_color and the index.html
theme-color media pair now follow the live palette (#eaf3ea light /
#22271f deep pine dark).
- custom2.js: sync ONE meta theme-color to the app's resolved theme
(html.dark class + prefers-color-scheme listener) so Android status/nav
bands and iOS safe areas track the theme at runtime; the static media
pair remains as the no-JS fallback.
inference-bot
Nathan Schneider