Untitled Design System

### Spacing System

• Base unit: 8px (with finer 1/2/4px steps available for tight inline gaps).

• Tokens (front matter): {spacing.xxs} (1px) · {spacing.xs} (4px) · {spacing.sm} (8px) · {spacing.md} (12px) · {spacing.lg} (16px) · {spacing.xl} (24px) · {spacing.xxl} (32px) · {spacing.section} (96px).

• Universal section rhythm: every page in the set uses {spacing.section} (96px) as the vertical gap between major content blocks. This is the largest spacing token in the system and is the dominant layout cue across the home, /zen, and /enterprise pages.

• Section internal padding: content rows inside a section sit at {spacing.lg} (16px) vertical with no horizontal padding — text starts flush at the section's left edge.

### Grid & Container

• Max width: ~960px content column for body sections; the dark hero TUI mockup is full-bleed within an outer ~1100px content frame.

• Two-column split: /enterprise pairs a left text block (~360px wide) with a right-aligned form column (~480px wide). The home page is single-column reading.

• Footer: 5-up horizontal link row (GitHub / Docs / Changelog / Discord / X) at desktop, collapsing to 2-up at tablet and 1-up at mobile.

### Whitespace Philosophy

Whitespace is structural and generous. Sections sit 96px apart with no decorative dividers between them — the {colors.hairline} 1px rule is the only signal of separation. Inside a section, content is left-flush against the column edge with no internal indentation; bullets use ASCII bracket prefixes ([+] / [-]) instead of indent-based layout. The result is a page that feels like a printed code listing rather than a styled marketing layout.

### Border Radius Scale

| Token | Value | Use |

|---|---|---|

| {rounded.none} | 0px | Sections, hero TUI mockup, primary nav, footer, list rows — every container that isn't a button |

| {rounded.sm} | 4px | Every interactive element — primary CTA, secondary CTA, text inputs, install snippet, badges, prompt rows |

| {rounded.full} | 9999px | Avatar circles in testimonials |

The radius vocabulary is two values: 4px for interactive elements and 0px for everything else. Avatar circles in testimonial rows are the only fully-rounded element in the system.

### Photography Geometry

There is no photography. Visual elements are limited to:

• ASCII block-pixel wordmark in the nav and hero TUI mockup.

• Inline ASCII charts inside the stat-block section — abstract sparse-line and dotted plots without specific data points.

• Avatar dots (~32px) inside testimonial rows on /zen — flat colored circles in {rounded.full}.

• In-product icons (kbd, A+, ⊕, ↻, K, Z) rendered as small monospaced character glyphs, not bitmaps or SVG.

### Breakpoints

| Name | Width | Key Changes |

|---|---|---|

| desktop-large | 1280px+ | Default — 960px content column, 5-up footer link grid |

| desktop | 1024px | Same layout; nav remains horizontal |

| tablet | 850px | Footer collapses to 2-up grid; /enterprise two-column form stacks |

| tablet-narrow | 768px | Primary nav becomes hamburger drawer; Download CTA stays visible |

| mobile | 640px | Single-column everything; hero display drops 38px → ~28px; section padding tightens |

### Touch Targets

All interactive elements meet WCAG AA at the ~36–40px height range. {component.button-primary} sits at ~36px with 20px horizontal padding. {component.text-input} and {component.textarea} sit at ~40px. {component.button-tab} rows in the install-method strip sit at ~32–36px depending on label length but extend to a full 44px tappable cell via inline padding. Footer links use {typography.caption-md} (14px) but receive ~28px line-height (caption-md is 2.0) plus 8px vertical padding for a comfortable ~44px tappable row.

### Collapsing Strategy

• Primary nav: desktop horizontal cluster → tablet-narrow hamburger drawer at 768px. The dark "Download" CTA stays visible at all widths.

• Hero TUI mockup: maintains its full-bleed dark surface at every breakpoint; the ASCII wordmark scales proportionally and the keybinding-hint row may wrap to two lines on narrow screens.

• Install snippet + tab strip: desktop fixed-width pill → mobile full-width pill with horizontal scroll on the tab strip if labels overflow.

• Footer: 5-up horizontal link grid → 2-up at tablet → 1-up at mobile (each link becomes a full-width row).

• `/enterprise` two-column layout: desktop 50/50 → tablet stacks to single-column with the form below the text block.

• Section padding: {spacing.section} (96px) desktop → 64px tablet → 48px mobile.

• Hero headline: {typography.display-xl} (38px) at desktop, scaling to ~28px at mobile, line-height holding at 1.5.

### Image Behavior

There are no raster images in the system aside from the favicon and OG share image. Every visual element — wordmarks, charts, icons — is rendered as type or inline SVG and scales without aspect-ratio considerations.

1. Focus on ONE component at a time. Pull its YAML entry and verify every property resolves.

2. Reference component names and tokens directly ({colors.ink}, {component.hero-tui-mockup}, {rounded.sm}) — do not paraphrase.

3. Run npx @google/design.md lint DESIGN.md after edits — broken-ref, contrast-ratio, and orphaned-tokens warnings flag issues automatically.

4. Add new variants as separate component entries (-active, -disabled) — do not bury them inside prose.

5. Default body to {typography.body-md}; reach for {typography.body-strong} for emphasis; reserve {typography.display-xl} strictly for the page-top hero headline.

6. Keep {colors.surface-dark} scarce — at most one full-bleed dark mockup per page. The dark surface is a narrative device, not a chrome treatment.

7. When introducing a new component, ask whether it can be expressed with the existing ASCII-bracket + 4px-radius + Berkeley-Mono vocabulary before adding new tokens. The system's strength is that it almost never needs new ones.

• Mobile screenshots not captured — responsive behavior synthesizes OpenCode's mobile pattern (hamburger drawer, single-column, footer accordion) from desktop evidence and the breakpoint stack.

• Hover states not documented by system policy.

• In-product TUI screenshots beyond the marketing hero mockup are not in the captured set; the actual opencode terminal interface (full keybindings, panels, status bar) is not documented here.

• `/go` page not extracted — the marketing page for the Go SDK likely shares the same chrome but introduces code-sample blocks not documented above.

• Form validation state styling (success / error inline messages) not present in the captured surfaces.