@momoi-labs/kiso 0.1.0

package/kiso/docs/patterns/sorting.md

@@ -0,0 +1,121 @@
+# Sorting
+
+Column sorting with visible indicators and consistent cycle. This pattern
+governs how a [Table / DataTable](../components/table.md) orders its rows by a
+sortable column, and how that order is communicated.
+
+User story #7.
+
+## Purpose
+
+Sorting lets the person reorder the current result set by a comparable column —
+name, lag, modified date, row count. It answers "which of these is most/least
+X?" without the person scrolling to compare manually. Sorting orders the set
+that [Search](search.md) and [filtering](filtering.md) have already narrowed.
+
+## Component composition
+
+| Region | Compose with | Role |
+| --- | --- | --- |
+| Sortable header | [Table / DataTable](../components/table.md) ColumnHeaderCell with sort control | Button inside the header that toggles sort |
+| Sort indicator | icon in the header (▲ / ▼) | Visual + accessible direction; not color alone |
+| Unsortable header | plain `<th>` | No sort control, no `aria-sort` |
+| Sort announcement | polite live region | "Sorted by lag, descending" when not obvious from focus |
+
+The sort control is a button (or a nested button) inside the `<th>`. It is not
+a separate "Sort" dropdown outside the table.
+
+## Flow
+
+1. Person views the table with its default sort (or unsorted).
+2. Person activates a sortable header (click or keyboard `Enter`/`Space` on
+   the header button).
+3. Sort cycles: unsorted → ascending → descending → unsorted (or
+   ascending → descending → ascending if a default sort is required and
+   "unsorted" is not meaningful).
+4. The rows reorder. If server-side, the region shows
+   [Skeleton](../components/skeleton.md) rows during the fetch; if client-side,
+   the set reorders immediately.
+5. The header's `aria-sort` and visible indicator update.
+6. The sort interacts with [pagination](pagination.md): changing sort on a
+   paged set resets to page 1 (the person should see the top of the new order).
+
+## States
+
+| State | Header behavior | Tokens |
+| --- | --- | --- |
+| unsorted | No indicator. `aria-sort="none"`. Sort control still present on sortable headers. | Header default tokens. |
+| ascending | ▲ indicator. `aria-sort="ascending"`. | Indicator `--color-foreground` or `--color-primary`. |
+| descending | ▼ indicator. `aria-sort="descending"`. | Same as ascending. |
+| applying | Server-side: body shows Skeleton rows; `aria-busy` on the region. Header indicator already shows the new direction. | |
+| error | Sort query failed → [Alert](../components/alert.md). Do not leave a stale sort indicator with mismatched rows. | |
+
+The sort indicator must be visible without relying on color alone. Use an icon
+(▲ / ▼ or an equivalent) plus `aria-sort`.
+
+## Layout sketch
+
+```text
+┌──────────────────────────────────────────────────────────────────────┐
+│ Toolbar                                                              │
+│ [🔍 Search replicas...] [Status▾]                                   │
+│ 18 replicas                                                          │
+├──────────────────────────────────────────────────────────────────────┤
+│ Table / DataTable                                                    │
+│ ┌────────────────────────────────────────────────────────────────┐  │
+│ │ Name ▲      Host            Status     Lag ▼      Region       │  │
+│ │ analytics   db.an.example   ok        1.2 s      ap            │  │
+│ │ replica-01  db.eu.example   degraded  820 ms     eu            │  │
+│ │ replica-03  db.eu.backup    degraded  410 ms     eu            │  │
+│ │ replica-07  db.eu.dr        ok          —        eu            │  │
+│ │ ...                                                            │  │
+│ └────────────────────────────────────────────────────────────────┘  │
+│ ← 1 2 3 … →                                                         │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+`Lag ▼` is the active sort (descending): highest lag first. `Name ▲` shows a
+previous or secondary direction indicator only if the surface supports
+multi-sort; otherwise only one column carries an indicator at a time.
+
+## Rules
+
+- One primary sort column at a time unless the product explicitly supports
+  multi-sort. Multi-sort is rare; if supported, document the precedence order
+  and show secondary indicators subtly.
+- Default sort is allowed and often sensible (e.g. "Modified, descending").
+  The default-sorted column shows its indicator on first render.
+- The sort cycle is consistent across the product. Pick one —
+  unsorted → asc → desc → unsorted, or asc → desc → asc — and keep it.
+- Sort changes the **order of the current result set** (client) or the
+  **query** (server). Document which on the screen or in its notes.
+- Changing sort on a paged set resets to page 1. The person expects to see the
+  top of the new order, not page 3 of the old one.
+- Do not sort by a column the person cannot see. If a column is hidden by
+  responsive collapse ([large-data-tables](large-data-tables.md)), it should
+  not be the active sort — or its sort must transfer to a visible column.
+- Unsortable columns (e.g. row actions, a Badge-only status that has no natural
+  order) have no sort control and no `aria-sort`.
+- Sort interacts with [filtering](filtering.md) and [Search](search.md): the
+  filtered/searched set is what gets sorted. Sorting does not widen the set.
+
+## Accessibility
+
+- Sortable headers use a button with `aria-sort` on the `<th>`:
+  `ascending`, `descending`, or `none`.
+- The sort direction is announced when it changes, especially when focus does
+  not remain on the header (e.g. server-side sort that swaps rows). Use a
+  polite live region: "Sorted by lag, descending."
+- The header button has an accessible name that includes the column: "Sort by
+  lag". The visible label plus icon is the name; do not rely on the icon alone.
+- Keyboard: `Tab` reaches sortable headers; `Enter` / `Space` toggles sort.
+  Arrow-key grid navigation, if implemented, follows the
+  [Table](../components/table.md) keyboard model.
+
+## Related patterns
+
+- [Search](search.md) — narrows the set before sorting.
+- [Filtering](filtering.md) — narrows the set before sorting.
+- [Pagination](pagination.md) — pages the sorted set.
+- [Large data tables](large-data-tables.md) — tables where sort + scroll is the
+  primary navigation.

package/kiso/docs/principles.md

@@ -0,0 +1,122 @@
+# Design Principles
+
+These principles govern *how Momoi Labs product interfaces are designed*. They
+are the design analog to the repository's
+[engineering principles](../../docs/PRINCIPLES.md) — separate in domain, but
+philosophically coherent with them.
+
+Use them when a design choice has more than one correct answer. When a
+principle and a convenience conflict, the principle wins. When two principles
+conflict, the order below is the tie-breaker.
+
+## Relationship to engineering principles
+
+The engineering principles (`docs/PRINCIPLES.md`) govern *how this repository
+is built*: smallest viable change, commit history tells a story, interfaces are
+a compatibility contract, no silent defaults, decisions are recorded
+append-only.
+
+These design principles govern *how product interfaces look and feel*. They do
+not duplicate the engineering principles. They are coherent with them in
+spirit:
+
+- Engineering's "no silent defaults" has a design analog — "no ad-hoc
+  tokens/components when an equivalent exists" — which will live in
+  `kiso/AGENTS.md` (a later epic), not here.
+- Engineering's "smallest viable change" echoes in design's "useful over
+  decorative": both ask *does this need to be here?*
+- Engineering's "decisions are recorded" echoes in design's "opinionated, not
+  restrictive": have a position, and make it findable.
+
+Do not conflate the two. When an engineering question arises in design work
+(e.g. "should this be a new component?"), defer to the engineering principles.
+
+## 1. Useful over decorative
+
+Every element in a product interface must serve a purpose. Decoration that does
+not help the person do something is removed — not minimized, removed.
+
+When choosing between two directions, prefer the one that:
+
+- helps the person understand or act, rather than merely impresses;
+- uses whitespace and hierarchy instead of ornament to create structure;
+- defers any visual flourish that the task does not require.
+
+This is the first principle because it is the most common question: *should
+this be here?* If it does not help, it does not belong.
+
+## 2. Clarity over cleverness
+
+A clear interface is better than a clever one. Novelty for its own sake makes a
+product harder to learn and harder to maintain.
+
+When choosing between two directions, prefer the one that:
+
+- uses familiar patterns where a familiar pattern already works;
+- makes the current state and available actions obvious;
+- resists a novel solution unless the novel solution is materially better — and
+  if it is, records why.
+
+## 3. Technical, not intimidating
+
+Momoi builds developer tools, DB/infra tooling, and data-heavy interfaces.
+These can be dense and precise without being hostile.
+
+When choosing between two directions, prefer the one that:
+
+- trusts the person's competence — show exact values, raw data, and technical
+  terms where they are the clearest language;
+- adds context and affordance rather than dumbing down — explain, don't hide;
+- keeps density high where density aids understanding, and uses hierarchy to
+  keep it navigable.
+
+## 4. Quiet interfaces, strong hierarchy
+
+Calm surfaces with strong information hierarchy. Visual noise is low; the
+structure does the guiding.
+
+When choosing between two directions, prefer the one that:
+
+- uses one accent for attention, not a palette competing for it;
+- lets typography and spacing establish rank, rather than color or weight
+  escalation;
+- reserves emphasis for the thing that matters most on the screen right now.
+
+## 5. Opinionated, not restrictive
+
+Momoi has a position on how things should look and sound. That position makes
+decisions faster and products more consistent. But it should never block a
+legitimate need.
+
+When choosing between two directions, prefer the one that:
+
+- has a clear default and a documented reason for it;
+- allows escape hatches when a genuine case demands it — and records the
+  escape;
+- does not invent a rule just to forbid something; every restriction should
+  trace back to a principle above.
+
+## Conflict resolution (tie-breaker)
+
+When two principles conflict, resolve in this order:
+
+1. **Useful over decorative** — if one option serves the person and the other
+   decorates, the useful one wins. This is almost always the first cut.
+2. **Clarity over cleverness** — if both are useful, the clearer one wins.
+3. **Technical, not intimidating** — if both are clear, prefer the one that
+   respects and engages the person's competence.
+4. **Quiet interfaces, strong hierarchy** — if both are technical, prefer the
+   calmer, more hierarchically structured one.
+5. **Opinionated, not restrictive** — apply defaults and positions, but yield
+   to a documented, genuine exception.
+
+The order moves from *does it belong?* through *is it clear?* through *is it
+respectful?* through *is it calm?* to *is it consistent?* — a funnel from
+existence to polish. If a conflict is not resolved after walking this list, the
+design principle is missing and should be added (in a later epic, through real
+product need — not speculatively here).
+
+---
+
+*Design principles are separate from engineering principles but philosophically
+coherent. Read both. Do not duplicate.*

package/kiso/docs/tokens.md

@@ -0,0 +1,95 @@
+# Kiso design tokens
+
+Kiso tokens are a two-layer interface. `tokens/tokens.json` is the single DTCG
+2025.10 source: `color.*` contains raw palette primitives, while `semantic.*`
+names the roles a product needs. Components consume semantic colors only; they
+must not use a primitive, a generated primitive variable, or a raw hex value.
+If no semantic role fits, propose a role instead of bypassing this interface.
+
+Install dependencies and build with Style Dictionary v5:
+
+```sh
+npm ci
+npm run build
+```
+
+The build emits `tokens/build/tokens.css`, `tokens.json`, `tokens.d.ts`, and
+`tokens.scss`. CSS contains the dark default in `:root`, light overrides in
+`[data-theme="light"]`, and the reduced-motion override. Import `tokens.css`,
+then toggle the light theme on an ancestor; application CSS should need no raw
+color values.
+
+```css
+@import "../../tokens/build/tokens.css";
+
+.panel {
+  color: var(--color-foreground);
+  background: var(--color-surface);
+  border: 1px solid var(--color-border);
+}
+```
+
+## Semantic colors
+
+| Role | Meaning and use | Dark primitive | Light primitive |
+| --- | --- | --- | --- |
+| `background` | Application canvas; never text. | `neutral.900` | `neutral.200` |
+| `surface` | Cards, panels, and table rows. | `neutral.800` | `neutral.100` |
+| `elevated-surface` | Menus, popovers, and dialogs. | `neutral.700` | `white` |
+| `foreground` | Primary text and content that must carry the strongest hierarchy. | `neutral.100` | `neutral.900` |
+| `muted-foreground` | Secondary text and labels. It remains normal-text eligible. | `neutral.400` | `neutral.600` |
+| `subtle-foreground` | Placeholders, timestamps, and non-essential hints; large text only, never body copy. | `neutral.500` | `neutral.500` |
+| `border` | Dividers and control outlines; never text. | `neutral.600` | `neutral.300` |
+| `primary` | The main interactive action: links, active states, and primary controls. | `accent.base` | `accent.base` |
+| `accent` | Secondary emphasis and highlights, not the page's main action. | `accent.300` | `accent.800` |
+| `success` | Positive or completed state. | `status.success` | `status.success` |
+| `warning` | Caution or a condition needing attention. | `status.warning` | `status.warning` |
+| `danger` | Error or destructive action. | `status.danger` | `status.danger` |
+| `info` | Neutral informational state. | `status.info` | `status.info` |
+| `focus` | Keyboard focus ring; never text. | `accent.300` | `accent.base` |
+| `disabled` | Disabled text and controls only. | `neutral.600` | `neutral.400` |
+
+Use `foreground` for default reading, `muted-foreground` when content is
+secondary but still needs normal-text contrast, and `subtle-foreground` only
+for large or non-essential supporting copy. Use `primary` for the action that
+drives the current task; use `accent` to draw secondary attention without
+creating another primary action.
+
+The semantic aliases deliberately point at different primitives by theme.
+Status primitives and `accent.base` are themselves mode-aware, so the same
+semantic role preserves its meaning and contrast rather than preserving a
+literal color.
+
+## AA gate
+
+`scripts/check-contrast.mjs` is the build-time AA gate. In both dark and light
+themes it resolves the semantic aliases and checks:
+
+- `foreground`, `muted-foreground`, `primary`, `accent`, `success`, `warning`,
+  `danger`, and `info` at **4.5:1** or better against `background`, `surface`,
+  and `elevated-surface`;
+- `subtle-foreground` at **3:1** or better against those surfaces, restricting
+  it to large text and non-essential metadata;
+- `focus` at **3:1** or better against `background` for visible focus rings.
+
+`disabled` is intentionally outside the gate because inactive controls are
+exempt from WCAG 1.4.3. `background`, `surface`, `elevated-surface`, and `border`
+are not text roles. Run the gate with:
+
+```sh
+node scripts/check-contrast.mjs tokens/tokens.json
+```
+
+## Generated files
+
+All four files in `tokens/build/` are committed. This makes the published
+artifacts directly consumable without requiring downstream projects to install
+Style Dictionary. Do not edit them: change `tokens/tokens.json` or the build
+configuration and regenerate. CI rebuilds the artifacts and fails if the
+committed output has drifted, so `tokens/build/` is intentionally not ignored.
+
+Published releases expose the artifacts as `@momoi-labs/kiso/tokens.css`,
+`@momoi-labs/kiso/tokens.json`, `@momoi-labs/kiso/tokens.scss`, and
+`@momoi-labs/kiso/tokens.d.ts`. Kiso's Markdown contracts are available below
+`@momoi-labs/kiso/contracts/` so consumers can pin the contracts and generated
+tokens to the same version.

package/kiso/docs/voice-and-tone.md

@@ -0,0 +1,154 @@
+# Voice and Tone — Product UI Microcopy
+
+This document governs how product UI copy **sounds**. It is the voice layer of
+the [brand](./brand.md), made concrete for the words on screen.
+
+It covers **product UI** — labels, buttons, states, errors, empty states,
+confirmations. It does not cover marketing copy, documentation prose, or the
+marketing site's voice. The marketing site is more experimental; products are
+lived in.
+
+## The core decision: universal directness vs reserved terminal flourish
+
+Momoi's marketing site has a terminal-inspired voice. For products, that voice
+splits into two layers with different rules:
+
+### Universal directness (applies everywhere)
+
+All product UI copy is **direct, brief, and structured**. This is not a style
+preference — it is a baseline requirement for every word on screen.
+
+- **Direct.** Say what the thing is and what it does. No hedging, no
+  filler, no "please" or "sorry" in functional copy.
+- **Brief.** The fewest words that are still clear. If a label works at two
+  words, it does not need three.
+- **Structured.** Prefer scannable structure (labels, lists, known patterns)
+  over prose paragraphs. Dense data gets a table, not a sentence.
+
+### Reserved terminal flourish (chrome and metadata only)
+
+The site's literal terminal flourishes — "~/ABOUT" navigation prefixes, "$
+export THEME=light" command-style actions — are **reserved for chrome and
+metadata**. They do not appear in:
+
+- **Body copy.** Explanatory text is plain and direct.
+- **Error messages.** Errors follow their own mandatory structure (below).
+- **Functional UI text.** Buttons, form labels, status indicators, and
+  navigation use plain language.
+
+Terminal flourish is appropriate in chrome where it reinforces identity without
+costing clarity — e.g. a subtle metadata label, a decorative section eyebrow.
+When in doubt, leave it out. Directness always works; flourish is optional.
+
+## Error messages (hard rule)
+
+Error messages **must** follow this three-part structure:
+
+1. **What happened.** State the problem in plain language.
+2. **Why, when possible.** If the cause is knowable, explain it briefly. If it
+   is not, skip this part rather than guess.
+3. **What the person can do now.** Offer a concrete next step or recovery
+   action.
+
+This is a **hard rule**, not a suggestion. An error without a recovery path is
+incomplete.
+
+**Examples:**
+
+> Connection to the database failed. The server at `db.example.com:5432` did
+> not respond within 5 seconds. Check that the database is running and
+> reachable, then retry.
+
+> This query was canceled. It exceeded the 30-second timeout. Narrow the query
+> scope or increase the timeout in Settings.
+
+> You don't have permission to delete this record. Only workspace admins can
+> delete records. Ask an admin to perform this action or to grant you the
+> role.
+
+**Anti-patterns** (never do these):
+
+- Cryptic codes without context: `Error: ECONNREFUSED`
+- Accusatory tone: "You entered an invalid value."
+- Apologetic filler: "Oops! We're sorry, but something went wrong."
+- No recovery path: "Operation failed."
+
+## Specific UI states
+
+### Empty states
+
+Helpful and actionable, not apologetic or cute. State what is empty, why it
+might be, and what to do next.
+
+> No queries yet. Create your first query to see it here.
+
+> This workspace has no members. Invite people to collaborate.
+
+Do not say "Nothing to see here" or "It's lonely in here." Empty states are a
+signpost, not a joke.
+
+### Loading states
+
+Informative without being chatty. State what is happening; do not narrate
+enthusiasm.
+
+> Loading queries…
+
+> Connecting to database…
+
+Do not say "Hang tight!" or "Cooking something up…". A loading state that takes
+longer than a moment may add a reason ("Loading 1,240 rows…").
+
+### Destructive actions and confirmations
+
+Clear without being alarming. Name the action and its consequence; let the
+person decide.
+
+> Delete "production-db"? This cannot be undone.
+
+> Disconnect from `staging-db`? Active queries will be terminated.
+
+Do not say "Are you absolutely sure?" or wrap confirmations in warning colors
+that imply danger beyond the actual stakes. Match the confirmation's weight to
+the action's irreversibility.
+
+### Permission denied
+
+Explain clearly without sounding accusatory or corporate. State what was
+denied, why, and what to do.
+
+> You can't edit this query. Only the query author and workspace admins can
+> edit it. Ask an admin to grant you access.
+
+Do not say "Access Denied" in red with no context. Do not say "You are not
+authorized to perform this action" — it is corporate and unhelpful.
+
+## Product UI voice vs documentation tone
+
+Product UI copy is **terse and structural**. Documentation is **prose that
+explains**. They share directness but differ in form:
+
+- **Product UI:** "Delete query" / "3 of 12 rows selected" / "Reconnect"
+- **Documentation:** "To delete a query, open its menu and choose Delete. The
+  query is removed from the workspace; its results are not exported anywhere."
+
+Do not write product UI copy as documentation, and do not write documentation
+as a series of labels. If a UI element needs more explanation than a label
+allows, link to documentation rather than inflating the label.
+
+## Quick reference
+
+| Situation | Rule |
+| --- | --- |
+| Any copy | Direct, brief, structured |
+| Error | What happened → why (if possible) → what to do now |
+| Empty state | What's empty → why → what to do |
+| Loading | What's happening, no chatter |
+| Destructive | Name action + consequence, match weight to stakes |
+| Permission denied | What was denied → why → what to do |
+| Terminal flourish | Chrome/metadata only, never body/errors/functional text |
+
+---
+
+*Directness is universal. Terminal flourish is reserved. Errors always have a
+recovery path.*

package/package.json

@@ -0,0 +1,42 @@
+{
+  "name": "@momoi-labs/kiso",
+  "version": "0.1.0",
+  "description": "Kiso design-system contracts and generated design tokens",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/momoi-labs/blueprint.git"
+  },
+  "type": "module",
+  "files": [
+    "kiso/",
+    "tokens/build/"
+  ],
+  "exports": {
+    "./tokens.css": "./tokens/build/tokens.css",
+    "./tokens.json": "./tokens/build/tokens.json",
+    "./tokens.scss": "./tokens/build/tokens.scss",
+    "./tokens.d.ts": "./tokens/build/tokens.d.ts",
+    "./contracts/*": "./kiso/*"
+  },
+  "scripts": {
+    "build": "style-dictionary build --config style-dictionary.config.mjs",
+    "check": "npm run build && npm run check:generated && npm run check:tokens",
+    "check:generated": "git diff --exit-code -- tokens/build/",
+    "check:tokens": "node scripts/validate-dtcg.mjs && node scripts/check-contrast.mjs tokens/tokens.json && node scripts/check-component-token-refs.mjs",
+    "changeset": "changeset",
+    "release": "changeset publish"
+  },
+  "publishConfig": {
+    "access": "public",
+    "provenance": true
+  },
+  "devDependencies": {
+    "@changesets/cli": "^2.29.7",
+    "ajv": "^8.17.1",
+    "style-dictionary": "^5.0.0"
+  },
+  "engines": {
+    "node": ">=24"
+  }
+}

package/tokens/build/tokens.css

@@ -0,0 +1,143 @@
+/* Kiso design tokens — generated from tokens/tokens.json. Do not edit. */
+
+:root {
+  --color-white: #ffffff;
+  --color-black: #000000;
+  --color-neutral-100: #faf9f7;
+  --color-neutral-200: #f4f2ee;
+  --color-neutral-300: #e0dcd6;
+  --color-neutral-400: #b6b2ae;
+  --color-neutral-500: #8a857f;
+  --color-neutral-600: #5f5b57;
+  --color-neutral-700: #312f37;
+  --color-neutral-800: #26252b;
+  --color-neutral-900: #1b1a1e;
+  --color-accent-200: #ede8fd;
+  --color-accent-300: #ded5fb;
+  --color-accent-400: #c4b4f5;
+  --color-accent-600: #7d68d1;
+  --color-accent-700: #6552b8;
+  --color-accent-800: #46309e;
+  --color-accent-900: #2e2170;
+  --color-accent-base: #cbbdf7;
+  --color-status-success: #4ed69a;
+  --color-status-warning: #e8c05a;
+  --color-status-danger: #f4867f;
+  --color-status-info: #8fc9f5;
+  --color-background: var(--color-neutral-900);
+  --color-surface: var(--color-neutral-800);
+  --color-elevated-surface: var(--color-neutral-700);
+  --color-foreground: var(--color-neutral-100);
+  --color-muted-foreground: var(--color-neutral-400);
+  --color-subtle-foreground: var(--color-neutral-500);
+  --color-border: var(--color-neutral-600);
+  --color-primary: var(--color-accent-base);
+  --color-accent: var(--color-accent-300);
+  --color-success: var(--color-status-success);
+  --color-warning: var(--color-status-warning);
+  --color-danger: var(--color-status-danger);
+  --color-info: var(--color-status-info);
+  --color-focus: var(--color-accent-300);
+  --color-disabled: var(--color-neutral-600);
+  --font-heading: Inter, system-ui, sans-serif;
+  --font-body: Inter, system-ui, sans-serif;
+  --font-mono: JetBrains Mono, ui-monospace, monospace;
+  --type-size-metadata: 11px;
+  --type-size-label: 13px;
+  --type-size-body: 16px;
+  --type-size-h3: 19px;
+  --type-size-h2: 23px;
+  --type-size-h1: 28px;
+  --type-size-display: 33px;
+  --type-weight-regular: 400;
+  --type-weight-medium: 500;
+  --type-weight-semibold: 600;
+  --type-weight-bold: 700;
+  --type-line-height-tight: 1.2;
+  --type-line-height-normal: 1.5;
+  --type-line-height-relaxed: 1.6;
+  --type-letter-spacing-heading: -0.01rem;
+  --type-letter-spacing-normal: 0rem;
+  --type-letter-spacing-label: 0.02rem;
+  --type-role-display-font-family: var(--font-heading);
+  --type-role-display-font-size: var(--type-size-display);
+  --type-role-display-font-weight: var(--type-weight-medium);
+  --type-role-display-letter-spacing: var(--type-letter-spacing-heading);
+  --type-role-display-line-height: var(--type-line-height-tight);
+  --type-role-heading-font-family: var(--font-heading);
+  --type-role-heading-font-size: var(--type-size-h1);
+  --type-role-heading-font-weight: var(--type-weight-semibold);
+  --type-role-heading-letter-spacing: var(--type-letter-spacing-heading);
+  --type-role-heading-line-height: var(--type-line-height-tight);
+  --type-role-body-font-family: var(--font-body);
+  --type-role-body-font-size: var(--type-size-body);
+  --type-role-body-font-weight: var(--type-weight-regular);
+  --type-role-body-letter-spacing: var(--type-letter-spacing-normal);
+  --type-role-body-line-height: var(--type-line-height-normal);
+  --type-role-label-font-family: var(--font-body);
+  --type-role-label-font-size: var(--type-size-label);
+  --type-role-label-font-weight: var(--type-weight-medium);
+  --type-role-label-letter-spacing: var(--type-letter-spacing-label);
+  --type-role-label-line-height: var(--type-line-height-normal);
+  --type-role-metadata-font-family: var(--font-body);
+  --type-role-metadata-font-size: var(--type-size-metadata);
+  --type-role-metadata-font-weight: var(--type-weight-regular);
+  --type-role-metadata-letter-spacing: var(--type-letter-spacing-normal);
+  --type-role-metadata-line-height: var(--type-line-height-normal);
+  --type-role-code-font-family: var(--font-mono);
+  --type-role-code-font-size: var(--type-size-label);
+  --type-role-code-font-weight: var(--type-weight-regular);
+  --type-role-code-letter-spacing: var(--type-letter-spacing-normal);
+  --type-role-code-line-height: var(--type-line-height-normal);
+  --type-role-numeric-font-family: var(--font-body);
+  --type-role-numeric-font-size: var(--type-size-body);
+  --type-role-numeric-font-weight: var(--type-weight-regular);
+  --type-role-numeric-letter-spacing: var(--type-letter-spacing-normal);
+  --type-role-numeric-line-height: var(--type-line-height-normal);
+  --spacing-xs: 4px;
+  --spacing-sm: 8px;
+  --spacing-md: 12px;
+  --spacing-lg: 16px;
+  --spacing-xl: 24px;
+  --spacing-2xl: 32px;
+  --spacing-3xl: 48px;
+  --spacing-4xl: 64px;
+  --radius-sm: 4px;
+  --radius-md: 8px;
+  --radius-lg: 12px;
+  --radius-full: 9999px;
+  --shadow-sm: 0px 1px 2px 0px rgba(0, 0, 0, 0.24);
+  --shadow-md: 0px 2px 8px 0px rgba(0, 0, 0, 0.32);
+  --motion-duration-fast: 120ms;
+  --motion-duration-normal: 200ms;
+  --motion-easing-standard: cubic-bezier(0.2, 0, 0, 1);
+  --breakpoint-sm: 640px;
+  --breakpoint-md: 768px;
+  --breakpoint-lg: 1024px;
+  --breakpoint-xl: 1280px;
+  --font-variant-numeric: tabular-nums;
+}
+
+[data-theme="light"] {
+  --color-accent-base: #5b3fc4;
+  --color-status-success: #0c6b43;
+  --color-status-warning: #7a5000;
+  --color-status-danger: #ad2f29;
+  --color-status-info: #15559e;
+  --color-background: var(--color-neutral-200);
+  --color-surface: var(--color-neutral-100);
+  --color-elevated-surface: var(--color-white);
+  --color-foreground: var(--color-neutral-900);
+  --color-muted-foreground: var(--color-neutral-600);
+  --color-border: var(--color-neutral-300);
+  --color-accent: var(--color-accent-800);
+  --color-focus: var(--color-accent-base);
+  --color-disabled: var(--color-neutral-400);
+}
+
+@media (prefers-reduced-motion: reduce) {
+  :root {
+    --motion-duration-fast: 0s;
+    --motion-duration-normal: 0s;
+  }
+}