DESIGN.md

Give these instructions to the coding agent you already use. It reads your repository and writes the file; you review it and land it the way you land anything else. Installing Crocotaste does the same, in one issue holding them.

Replace "your repository" with the repo name, or let the setup flow do it.

You are working in the repository your repository. Write a DESIGN.md at the repository root that describes this codebase's design system as it actually is, in the Google Labs DESIGN.md format (https://github.com/google-labs-code/design.md).

Read the code first, and take every value from it:
- Tokens: the design tokens defined in CSS custom properties (`--color-*`, `--spacing-*`, `--radius-*`, `--font-*`), a Tailwind config, or a theme file. Copy each name and value exactly as the code writes it, and where light and dark are both defined, record both.
- Components: the components the app imports from its own library (`components/`, `ui/`, or the package it depends on), with their variants and sizes.
- Conventions: the rules the code already follows. Which component is used for which role, how a spacing or radius value gets chosen, and what this codebase never does.

Write the file in this shape:
1. YAML front matter. `name` and `colors` are the only keys the format requires; add `version: alpha`, and `typography`, `spacing`, `rounded` and `components` wherever the code has them. Reference another token with `{path.to.token}`.
2. Markdown sections, in this order and each at most once: `## Overview`, `## Colors`, `## Typography`, `## Layout`, `## Elevation & Depth`, `## Shapes`, `## Components`, `## Do's and Don'ts`. Leave out any section this codebase has no answer for and list what you left out under `omitted` in the front matter. A repeated heading makes the file invalid.
3. Last, `## Decisions`, the one section Crocotaste adds to the format, holding this line and nothing else yet: `_Team decisions are recorded here as undated entries; each one is a rule, its reason, and its source._`

Two of those sections carry most of the weight:
- `## Overview` names the files the tokens and the components actually live in, so anyone reading a rule can go and check the value behind it.
- `## Do's and Don'ts` is one rule per bullet, each one something a reviewer could hold a diff against, and it names the patterns this codebase never uses as well as the ones it prefers.
- Every rule names the token, component, class or value it means (`Dialog actions: right-aligned, gap-3, the safe choice last`), never an adjective alone (`dialogs look clean`): each reader takes an adjective its own way, and a rule nobody can check a diff against is never enforced.
- Beyond tokens, record what a design reviewer checks, wherever the code already has an answer: accessibility (every image has alt text, an icon-only button has an aria-label, focus stays visible, tap targets are at least a given size), interaction states (which controls carry hover, pressed, focus, disabled and loading states, and how empty and error states look), copy (casing, the words the product uses and the ones it avoids), and dark mode (how it is switched on and which tokens change with it). Only rules the code already follows; leave out any it does not.

Hold to these:
- Every value comes from the code. Where the repository has no token for something, say so instead of inventing one.
- Prefer the 20 tokens the app really uses to the 200 it defines and never reads, and keep the file under 400 lines.
- Check the result with `npx -p @google/design.md designmd lint DESIGN.md` and fix what it reports.
- Write DESIGN.md and change no other file.