Design System & Brand Foundation

<role>
You are a senior brand and design systems designer who also writes production CSS. You have shipped design systems for real products (tokens, type scales, component libraries) and you have strong, specific taste. You do not default to generic "AI SaaS" styling.
</role>

<context>
Brand: [brand_name]
Industry / product: [industry]
Brand personality (pick 3-4 adjectives, be specific, not "modern and clean"): [brand_personality]
Target audience: [target_audience]
Reference feelings or comparable brands/spaces (name real things: e.g. "the quiet confidence of a Muji catalog," "a vintage trading floor," "a field notebook"): [reference_feelings]
Mode: Light (light, dark, or both with a toggle)
</context>

<task>
Design a complete, opinionated design system/brand foundation for [brand_name] and deliver it as a single self-contained HTML file that both DOCUMENTS and DEMONSTRATES the system. This is a design token deliverable, not a marketing page: treat it like a living style guide a team would actually reference.

Work through this sequence and show your reasoning briefly in HTML comments above each section before the code:

1. **Design point of view first.** Before touching color or type, state in one or two sentences the specific visual direction you're committing to, derived from the brand personality and reference feelings, not a generic default. Reject the purple-gradient/glassmorphism/floating-dashboard SaaS look explicitly if that's not what this brand is.

2. **Color system.** Build the palette using OKLCH (or another perceptually uniform space) so lightness steps are visually even. Produce:
   - 1 primary hue with a full ramp (roughly 50-900, 9-10 steps)
   - 1 secondary or accent hue with its own ramp
   - A neutral/gray ramp with a slight tint toward the primary or secondary hue (not pure gray)
   - Semantic tokens: success, warning, danger, info
   - Every text-on-background and button-label pairing you use must hit WCAG AA (4.5:1 for body text, 3:1 for large text/UI). State the actual contrast ratio you calculated for at least the 5 most-used pairings, don't just assert "AA compliant."
   - Express every color as a CSS custom property named semantically (e.g. `--color-surface`, `--color-text-primary`, `--color-action-primary`, `--color-border-subtle`), never as raw hex referenced directly in components.

3. **Typography.** Choose a type pairing on a REAL contrast axis, not two similar-looking humanist sans fonts. Pick one of: serif display + grotesk body, monospace + humanist sans, slab + neutral sans, or a single distinctive family used at contrasting weights/optical sizes with a monospace for data/labels. Justify the pairing against the brand personality in one sentence. Define a modular type scale (e.g. ratio 1.25 or 1.333) from a small caption size up through a hero display size, as CSS custom properties (`--font-size-xs` through `--font-size-5xl` or similar), plus line-height and letter-spacing tokens for each step. Use real font stacks (system fonts or common Google Fonts loaded via a single self-hosted-safe method or system stack, since this file must work standalone with no external network calls), if you cannot load external fonts, choose the closest high-quality system font stack that still expresses the contrast axis (e.g. ui-serif vs ui-monospace).

4. **Spacing, radius, elevation, motion tokens.** Define a spacing scale (e.g. 4px/8px base) as `--space-1` through `--space-12`+, a radius scale (`--radius-sm/md/lg/full`), a small shadow/elevation scale (2-4 steps, tuned to the mode), and a motion scale (`--duration-fast/base/slow`, one easing curve). Wrap all transitions/animations in `@media (prefers-reduced-motion: reduce)` so they collapse to near-instant.

5. **Core components, built from the tokens only (no hardcoded values).** Render live, interactive examples of:
   - Buttons: primary, secondary, ghost/tertiary, and disabled state
   - Form input with label, helper text, and an error state
   - Card component
   - Badge/tag in at least 2 semantic colors
   - Navigation element (tabs or a nav bar)
   Show each component's states (default, hover, focus-visible, disabled) actually working, not just described. Focus states must be visibly distinct (not just a faint outline) and keyboard-navigable.

6. **Token reference table.** Include a visible, readable table (or grid) listing every CSS custom property you defined, its value, and a one-line usage note, so this file doubles as documentation.

Make it fully responsive (mobile, tablet, desktop) using relative units and fluid type where appropriate (clamp() is encouraged for the display sizes). Test your own layout mentally at 375px and 1440px widths and adjust.
</task>

<constraints>
- Single self-contained HTML file: inline `<style>`, no external requests, no CDN links, no external images (use CSS shapes/gradients/SVG inline if you need visual texture).
- All colors defined once as CSS custom properties on `:root` (and a `[data-theme="dark"]` block if both modes are requested); components consume the variables, never raw values.
- Meet WCAG AA contrast everywhere, including on hover/focus/disabled states where text remains readable.
- No purple-to-blue gradient hero, no glassmorphism-by-default, no generic floating dashboard mockup, no identical icon-over-heading card grids repeated 3+ times, no small uppercase eyebrow label slapped above every section header. If you use any of these patterns, it must be a deliberate, justified choice tied to the brand brief, not a default.
- Do not use em dashes anywhere in the copy or comments. Use commas, periods, colons, or parentheses instead.
- Avoid AI-slop vocabulary in all headings, labels, and body copy: no "delve, seamless, supercharge, leverage, elevate, robust, unleash, game-changing, cutting-edge, effortless."
- Respect `prefers-reduced-motion` for every transition and animation.
- Use semantic HTML5 (proper heading hierarchy, `<button>` for actions, `<label for>` on inputs, landmark regions) so it is screen-reader navigable.
</constraints>

<output_format>
Return one complete HTML file starting with `<!doctype html>`
- A short intro section stating the design point of view (from step 1).
- The full color system with visible swatches and their contrast ratios labeled on or beside each swatch.
- The type scale rendered live (each size shown at actual size with its token name and pixel/rem value labeled).
- Spacing/radius/elevation/motion tokens shown visually (e.g. spacing as a row of bars, radius as a row of boxes, shadows as a row of cards).
- The live component examples from step 5.
- The full token reference table from step 6, in a scrollable container if needed on small screens.
No explanatory prose outside the HTML file itself: all reasoning goes in brief HTML comments or on-page copy within the style guide.
</output_format>