feat: 2.0 design system, tokens, and the full shadcn set

[TurtIeSocks]

Plan 3 of 5. The 2.0 client gets its design language: the fonts actually loading, a light and dark token set, a data palette deliberately kept apart from the brand, shadcn wired up, and the existing shell restyled so the language is visible rather than theoretical. Nothing in src/ or server/ changes.

What is here

Fredoka and Nunito, self-hosted rather than linked from Google so an operator behind a restrictive network still gets them and nothing about their users leaves the server. They were already named in the token block before this branch and nothing loaded them, so both silently fell back to system UI.

One token set on :root with a single dark override. Not two parallel systems: shadcn's init tried to add a .dark class variant alongside the existing media query, and it was stripped along with the rest of what it wanted to bring, including a @theme inline block that quietly replaced Nunito with Geist.

A data palette in its own file for team, league and IV colours. It imports nothing and derives nothing from the accent, and a test enforces that, including by literal value.

The full shadcn component set, all 61 of them, plus lucide icons. The plan originally installed two and deferred the rest on YAGNI grounds. That was the wrong call for this phase: an agent that cannot see a component builds a worse one by hand, and during heavy iteration that cost compounds in a way unused files do not.

The bottom nav, hub and profile now consume the tokens. Until something did, the tokens were a file nobody read and their values were unverified guesses.

What the review caught

Every finding below passed typecheck, lint, a clean build and 110 tests. There is no gate in this repo that can see a contrast ratio, so a green suite carried no information at all about whether the design system was usable. All ratios here were computed, and then recomputed independently by a second pass that served the app in a real browser and read back painted pixels, because color-mix(in oklch, ...) cannot be resolved reliably on paper.

The active bottom-nav item failed contrast in dark mode. --color-primary aliases the accent, the accent has no dark override, and text-primary is what marks the current destination. It shipped at 3.82:1, an AA failure on the most important state in the navigation. Now 4.78:1.

--color-muted held a text colour while the vendored shadcn components use it as a background. Foreground on it computed to 2.27:1 in dark, a light grey slab with near-white text. The token set had shadcn's contract inverted and nothing filled the surface role. Now 14.09:1, with the text value moved to --color-muted-foreground where the components expect it.

Six placeholder pages were left on a stock Tailwind grey with no dark override, sitting next to restyled siblings using the token. 3.81:1 against 6.94:1, two different greys for the same role, one failing.

The bottom nav's top edge was the only thing separating a fixed bar from content scrolling under it, at 1.37:1. Now 3.40:1. The hairline and card ring stay deliberately soft at about 1.95:1: they are decorative rather than boundaries that identify a control, and flattening the palette to satisfy every number would have satisfied the numbers and lost the brief.

Three found afterwards

--color-destructive had the same defect as the accent, in a second place: no dark override, so 3.74:1 as text and 3.18:1 on its own tint. Nothing renders a destructive control yet, but leaving the second instance of a defect the review had just found seemed strange.

Class names quoted in prose in docs/ were being compiled into real CSS rules. Tailwind v4 auto-detects sources across the repo and that includes markdown, so text-neutral-500, text-violet-600 and border-neutral-200 all shipped while being used in zero source files. Small in bytes, worse as a signal: a stylesheet containing a class nothing uses misleads whoever greps it to confirm a change landed, which is exactly how the contrast fixes were verified.

The data palette was absent from the build entirely, before this branch and after it. Tailwind v4 prunes theme variables nothing references, and nothing references these yet, so every team and league colour shipped as nothing. All the care taken sourcing them character by character from the 1.0 client, and the test proving they stay firewalled from the brand, applied to variables the browser never received. Marking the block static keeps them. Relying on usage would not be safe here, because the scanner only sees literal names and a map layer picks its colour from data, so a pruned token resolves to nothing and markers render colourless without erroring.

What installing all 61 broke

Worth reading, because most of it was silent.

It overwrote both components we had already fixed. button.tsx lost the two hover fills a contrast audit had just computed, reverting the default variant to upstream's hover:bg-primary/80, the exact value measured at 3.31:1. card.tsx was damaged too, rounded-card reverting to rounded-xl in four places and ring-border to ring-foreground/10. Only git had a copy of that one. Vendored source is ours only until the next overwrite.

Three token families arrived undefined: popover, sidebar and chart, all at zero, alongside eleven bare var(--primary)-style names the components read and this project never declared. Every one of them resolves to nothing and errors nowhere. They are defined now, each with a dark override and each pair's contrast computed in both themes rather than eyeballed.

chart.tsx emitted its series variables under a .dark class selector, which would have reintroduced the second dark mechanism this branch has now stripped twice. It is wrapped in the same prefers-color-scheme query as everything else.

Six components failed exactOptionalPropertyTypes, which upstream does not write to. They are patched individually rather than by relaxing the flag or excluding the directory. A type error is the one kind of damage this repo actually detects, since the pre-commit hook runs a strict tsc and blocks, so a re-broken component surfaces in seconds. The button fix was lost silently for the opposite reason: no gate here can see a contrast ratio.

The chart series colours went into the data palette rather than the chrome tokens, because they are a data language in the same sense the team and league colours are. Five tints of the brand accent would look tasteful and make two adjacent series indistinguishable. They are checked for separation under normal vision and the three dichromacies, with the weakest pair at 19.3 dE against a 15 dE floor.

Security note

chart.tsx interpolates caller-supplied colour strings into a <style> element with no escaping, and noDangerouslySetInnerHtml is now switched off for the vendored directory, so the rule that would flag it will not. This is upstream's code and is safe while the config is a literal we write. It stops being safe if a colour ever arrives from operator config or stored user settings, both of which exist here. CSS injection is not cosmetic: attribute selectors paired with a background-image URL exfiltrate values, and absolute positioning redresses controls. Commented at the site; sanitising belongs at the first caller that feeds it non-literal data. Nothing renders a chart today.

Verification

bun test        120 pass, 0 fail, 204 expect() calls, 24 files
bun run typecheck   clean
bun run lint        clean
bun run build       both entries, separate stylesheets, 8 font files

Leakage into 1.0 was checked by building the base commit and this one from clean and diffing the two 1.0 stylesheets by selector set. The entire delta is 8 @font-face rules, zero selector rules, and Tailwind's reset does not reach 1.0 in either build. Those font rules land there because the chunking rule buckets CSS by path and the font packages resolve inside node_modules. They are inert, since nothing in 1.0 names either family, so no browser fetches the files.

Every pre-existing test still passes without being edited. The nav labels, the aria-current behaviour, the hub's hrefs and profile's three states are contract, and a restyle that changed an accessible name would have been a regression arriving as a green suite.

Known limitations

The hairline border and card ring sit below the 3:1 boundary target, as a judgement that they are decorative. If a later plan gives a card a selected or focused state, that state's boundary needs the stronger token.

--radius-sheet and --color-accent-to are declared and unused. The pink half of the accent has no gradient to appear in yet. Defensible while someone is tracking them; if the next plan does not use them they should go.

Popover and sidebar both alias the page surface, so this token set has no elevated-surface tone and a floating menu is separated from content only by a ring and a shadow. That matches how the card already behaves, which is why it was aliased rather than invented, but a menu is a stronger case for elevation than a card. Worth deciding before the first dropdown ships.

Vendored panels draw their edges with ring-foreground/10 while our card uses ring-border. Only one of those is a token, so they drift the moment either moves.

@base-ui/react arrived as a second headless primitives library alongside radix-ui, pulled in by combobox.tsx alone.

MUI is untouched. The spec's dependency delta removes it, but 204 files in src/ import it and that is the shell almost everyone is still served. It leaves when 1.0 retires.

🤖 Generated with Claude Code