Style Board

Style Board is the documentation model for the Style tab on a created project page. It explains how a generated page is converted into a reusable visual system: typography, colors, layout, spacing, surfaces, buttons, icons, shapes, and design guidance.

The tab was previously labeled Design System. The product-facing name is now Style, while the implementation can still use design-system data structures internally.

Binding Contract

Style Board is bound to the created-project Style tab.

UI source: src/components/work-design-system-board.tsx, Style tab panel.
Document source: docs/STYLE_BOARD.md.
Reader route: /[locale]/docs/style-board.
Sync rule: when the Style tab cards, extracted evidence, visual samples, field labels, or empty states change, update this document in the same change.
Reverse sync rule: when this document changes the Style Board template or functional contract, update the Style tab implementation to match.
Naming rule: user-facing tab copy should say Style; internal class names, data keys, and parser names may remain design-system until a broader refactor is explicitly planned.

Purpose

The Style tab should help a user answer six questions:

What reusable visual identity did this generated project establish?
Which typography, color, layout, spacing, and surface rules can be reused?
Which component treatments are proven by the generated HTML and prompt evidence?
Which rules should be preserved or avoided in future generations?
Which special skills are influencing the style?
Which extracted details are trustworthy enough to copy into another prompt or skill?

This makes the created project page useful as a style analysis surface, not only a generated-result preview.

Board Structure

The Style tab is a visual board made of evidence cards. Cards appear only when the project has enough evidence from design.md, full prompt text, generated HTML, parsed tokens, or work analysis.

Recommended card order:

Typography
Colors
Layout
Spacing
Buttons
Icons
Elevation & Depth
Shapes
Do's and Don'ts
Interface Lab Skills
Empty evidence state

The board should stay dense enough to support analysis, but each card must describe one reusable style layer.

1. Typography

Typography records the type system that can be reused across generated work.

It should show:

Heading system
Body system
Font family
A letter and number specimen
Copy action for the typography evidence

Evidence can come from parsed typography tokens, design.md, generated HTML classes, inline styles, or full prompt instructions about type hierarchy.

2. Colors

Colors captures the project palette and color usage signal.

It should show:

Named color swatches
Hex or CSS color values
Usage ratio signal
Color ramps when a color can be normalized
Gradient samples when gradients are detected
Copy action for color evidence

The card should avoid inventing palettes. If no color evidence exists, the card should not render.

3. Layout

Layout explains the structural composition of the generated page.

It should show:

Layout type
Content width
Grid or framing mode
Detected page regions
A simple wireframe preview
Copy action for layout evidence

Use this card to preserve the page's structural rhythm instead of only its surface look.

4. Spacing

Spacing extracts the project rhythm from tokens, code, and prompt evidence.

It should show:

Common spacing values
Padding, margin, or gap measurements
A compact spacing specimen
Copy action for spacing evidence

The goal is to make spacing reproducible in future prompts and skills.

5. Buttons

Buttons documents reusable action treatments.

It should show:

Button labels detected from HTML
Background and text color signals
Radius and padding signals
Primary, secondary, or supporting action samples
Copy action for component evidence

This card should describe actual interactive chrome rather than generic component theory.

6. Icons

Icons describes the icon treatment used by the generated project.

It should show:

Icon style
Representative icon samples
Icon alignment or stroke/fill guidance
Copy action for icon evidence

Evidence may come from icon libraries, SVG usage, class names, or prompt directives.

7. Elevation & Depth

Elevation & Depth captures how surfaces create hierarchy.

It should show:

Surface style
Border treatment
Shadow treatment
Blur or backdrop-filter usage
Gradient-border or glass techniques when present
Copy action for elevation evidence

This card should explain material logic, not decorative effects in isolation.

8. Shapes

Shapes records the radius and silhouette system.

It should show:

Radius tokens or measured border-radius values
Surface, field, and tag samples
Guidance for cards, buttons, inputs, badges, and supporting surfaces
Copy action for shape evidence

Use this card to keep future generations from drifting into unrelated geometry.

9. Do's and Don'ts

Do's and Don'ts turns style analysis into reusable constraints.

It should show:

Positive rules to preserve
Negative rules to avoid
Copy action for guideline evidence

This card is the style lint layer for future prompt generation.

10. Interface Lab Skills

Interface Lab Skills connects the generated page to reusable skills.

It should show:

Skill name
Skill category
Influence level
Targets such as typography, layout, motion, WebGL, icons, or surfaces
A short reason why the skill matters

This card explains which reusable skill layers are shaping the current project.

11. Empty Evidence State

If the project does not expose enough design.md, prompt, generated HTML, or analysis evidence, the Style tab should show an explicit empty state.

The empty state should explain that the board cannot be trusted yet, instead of filling the UI with guessed style rules.

Template Rules

Use these rules when building or maintaining the Style tab:

Keep the user-facing tab label as Style.
Preserve the visual evidence board as the first tab in the created-project analysis node.
Render cards only when there is enough source evidence.
Prefer extracted tokens, generated HTML, full prompt, and work analysis over invented content.
Keep each card copyable at the section level.
Keep visual samples compact and comparable.
Use empty states instead of fabricated style analysis.
Keep Style Board documentation synchronized with Style tab behavior.

Functional Contract

The Style board is complete when:

The tab is labeled Style.
Typography, colors, layout, spacing, buttons, icons, elevation, shapes, guidelines, and skill influence render when evidence exists.
Each rendered card exposes a focused reusable style layer.
Empty evidence is handled explicitly.
The document and UI remain synchronized through the binding contract.

This contract lets created project pages become reusable style templates instead of isolated screenshots.