01 / Architecture

Four parts, and skins beside them

The system is four fixed parts — Contract, Components, Nesting, Layout — and each one builds on the part below it. A skin sits beside them and supplies every value, so the whole system can change appearance without a single part moving.

PART 1

Contract

Every token name, in categories, each with a template value. The switch that selects a skin is named here too — both are public API, and renaming either is a major version.

--se-* · data-se-skin

PART 2

Components

One component describing itself: its parts, its states, what it does, and where it stops. Every component ships five files and an eleven-section spec.

data-part · data-state

PART 3

Nesting

What happens in the slots — what may fill one, how portals stack, and which part belongs to which component when one sits inside another. Nesting is things inside things; layout is things beside things.

slot · portal · z-index

PART 4

Layout

The page, and the regions it hands to the product. Regions carry ARIA roles rather than parts, which is why a dialog has a header and a page does not.

role="banner" · role="main"

ASIDE

Skins

A set of values for the contract. Authoring is partial — a skin lists only what it changes. Emission is total: every name it stays silent on is filled from the template, so switching skins switches everything rather than merging two.

tokens/skins/*.css

WHY IT SITS ASIDE

Both Components and Skins rest directly on the contract. Components read the names; skins fill them. Neither reaches the other, so neither is above the other — and a skin has nothing to reach down into.

A name a skin never sets resolves to the contract's template. That is what makes adding a token free for every skin already published, and why the contract is always loaded alongside a skin rather than replaced by it.

The rules

A component may never contain a literal value. Not a hex code, not a pixel, not a font name. It reads tokens; skins write tokens; nothing else crosses the line. This is the rule with no exceptions, and check:contract fails the build on a color literal.

Three things must never collapse into each other. The anatomy carries no color. The contract names no component. A skin adds no structure. Anatomy is one section of a component rather than the whole of it — the framework-neutral half a Vue or Astro author writes by hand.

A rule is filed by the smallest thing it governs. One token, Part 1. One component, Part 2. Components together, Part 3. The page, Part 4.

A rule may reach down, never up. A component reaches for tokens; a token never mentions a component. A rule naming something from the part above it is filed wrong.

Where the platform has a name, we use it. Landmarks, roles and ARIA states keep their own words, because a developer reads them in the code, in MDN and in every accessibility tool. We invent names only where the platform has none: anatomy, part, slot, skin, register, intent, emphasis, contract.

Where it lives

tokens/
  tokens.json      the source of truth. every name, every template value
  *.css            generated. never hand-edited
  skins/           one complete file per registered skin
components/
  components.css   the selectors that dress the anatomy
  <group>/         .jsx binding · .d.ts · .prompt.md · specimen
site/              this site. hand-authored, inline-styled
scripts/           the gates — gen-tokens, check-contract, check-contrast, check-voice