Most design systems start from a Figma file. This one started from a **live
site** — we pulled the palette, spacing, and type scale straight from the DOM,
distilled them into tokens, and had a working theme by the afternoon.

## Read the surface, not the spec

The fastest source of truth is what's already shipped. We sampled computed
styles across the real pages — backgrounds, borders, the accent — and grouped
them into a small set of semantic roles rather than raw values.

| Role       | Token            | Used for                    |
| ---------- | ---------------- | --------------------------- |
| Surface    | `background`     | the page and card fills     |
| Line       | `border-strong`  | dividers and focus rings    |
| Accent     | `accent`         | one hue, used sparingly     |

> A token isn't a color. It's a decision you only make once.

## Lock it behind a gate

Once the tokens existed, we added a drift gate that fails the build on any raw
color literal. The rule lives in the tooling, so a theme change is a one-file
edit and every surface repaints as one system.

```bash
pnpm gate   # scans source for non-token colors; exits non-zero on a leak
```

The payoff compounds: nothing can hardcode a color, so light ↔ dark flips
cleanly and rebranding stays a single change. If you take one thing from this,
make it *this* — put the rule where it can't be ignored.