fix(dashboard,widget): align design tokens with the editorial system - #81
Merged
DamienBattistella merged 1 commit intoJul 22, 2026
Merged
Conversation
The dashboard is declared `baseColor: neutral`, uses a neutral gray focus
ring, and squares off every shadcn primitive (`rounded-none`) with mono
type — an editorial, monochrome language the widget explicitly says it
mirrors ("neutral palette, no heavy primary accents"). But the dashboard
still carried stock shadcn-blue `--primary`, `--chart-*`, and
`--sidebar-primary` tokens, painting every CTA, badge, checked box,
"fresh" heartbeat dot and inbox selection bar blue.
Dashboard:
- Neutralize `--primary`/`--primary-foreground` to black-on-white
(light) / white-on-black (dark), mirroring the widget's monochrome
primary button.
- Replace the all-blue `--chart-*` ramp with a neutral grayscale ramp
(the tokens had no consumer yet but were off-language).
- Neutralize the unused `--sidebar-primary(-foreground)` tokens.
- Square the five stray `rounded-sm`/`rounded-md` elements in
Overview/Onboarding to match the fully-square primitives.
Widget:
- Make the documented `theme.radius` knob actually work: every chrome
surface (panel, launcher, buttons, fields, vote controls) now reads
`--koe-radius` via `koe-rounded-koe`, defaulting to 0 (square).
- Honor the documented `accentColor` contract: focus rings now tint to
the host accent, falling back to the neutral foreground when unset.
- Fix a dark-mode bug where the roadmap link (`koe-text-koe-accent`) fell
back to `#0a0a0a` — invisible on the dark background — by defaulting
the accent token to `--koe-text`.
- Correct the `accentColor`/`radius` doc comments (shared type + widget
CSS) to match the implementation.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AtRMjyJkW3M3RvkmCYM5NU
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contexte
Analyse du design system Koe (widget + dashboard) et correction des écarts entre l'intention de design déclarée et l'implémentation.
L'intention de design est explicite : type monospace, coins carrés, filets fins neutres, palette monochrome sans accent primaire lourd. C'est écrit en toutes lettres dans l'en-tête CSS du widget, et confirmé côté dashboard par
components.json("baseColor": "neutral"), l'anneau de focus gris neutre, et les primitives shadcn toutes passées enrounded-none+ type mono.Le dashboard trahissait pourtant cette intention en gardant les tokens bleus shadcn par défaut (
--primary,--chart-*,--sidebar-primary), colorant chaque CTA, badge, case cochée, point « fresh » du heartbeat et barre de sélection de l'inbox. Le widget avait de son côté des options de thème documentées mais inertes ou boguées.Discrepancies relevées et corrigées
Dashboard
--primary/--primary-foregroundpassent en noir-sur-blanc (clair) / blanc-sur-noir (sombre), à l'image du bouton primaire monochrome du widget.--chart-*toute bleue → rampe de gris neutre (tokens sans consommateur actuel mais hors-langage).--sidebar-primary(-foreground)neutralisés (tokens morts : l'état actif de la sidebar utilisesidebar-accent).rounded-sm/rounded-mddans Overview/Onboarding) →rounded-none, pour coller aux primitives entièrement carrées.Widget
theme.radiusrendu fonctionnel. Toutes les surfaces du chrome (panel, launcher, boutons, champs, votes) lisent désormais--koe-radiusviakoe-rounded-koe, avec un défaut à0(carré). L'option était typée et documentée mais consommée nulle part.accentColorhonoré. Les anneaux de focus se teintent maintenant de l'accent hôte, avec repli sur le premier plan neutre quand il n'est pas défini.koe-text-koe-accent) retombait sur#0a0a0a— invisible sur le fond sombre — faute d'accent défini ; le token accent retombe désormais sur--koe-text.accentColor/radiusdans le type partagé + en-tête CSS du widget).Vérifications
pnpm typecheck: 5/5 packages OKpnpm test: 90/90 tests API OKkoe-rounded-koe{border-radius:var(--koe-radius, 0)}et repli accent présents dans le bundle widgetAucun changement de comportement par défaut : le widget reste carré (radius 0) et monochrome (accent → foreground) tant que l'hôte ne configure rien.
🤖 Generated with Claude Code
Generated by Claude Code