Build On It

The only path allowed below the semantic layer: the token IR, pure renderers, core↔tokens parity, factories, the SSR path, deterministic builds, and release discipline. Every change here should state its impact on the layers above.

1. The engine's architecture

Components are visual only; a factory layer composes styled-components from tokenized props, and third-party libraries stay swappable behind wrappers.

• Architecture at a Glance — the folder shape, zero-business-logic rule, and the three co-resident doc layers.
• Vendor Isolation — why every external lib lives behind src/vendors/<Lib>/, and the terminal case (Culori's own color engine).

2. Tokens: IR, renderers, parity

@apollion-dsi/tokens duplicates core's derivation logic on purpose (Strangler Fig) — a parity test suite pins the two implementations byte-for-byte, so the published static surface can never silently diverge from the runtime theme.

• Output formats — the token IR's pure projections: CSS, TS, DTCG 2025.10 + Resolver, Design.md.
• Theming, Config-First — the canonical-dark seed swap that makes dark emission byte-exact with the runtime.

3. Server-side rendering

Deterministic class names, a validated ServerStyleSheet path, and a React-less CSS-vars surface for static output.

• Server-Side Rendering — deterministic componentIds, the SSR/SSG checklist, per-request theming rules.

4. Release discipline

SemVer via changesets, lockstep core+tokens versions, atomic + idempotent builds, publish only from a clean main with green gates.

• Build CLI — the CLI's atomicity and idempotency contract (--check for CI drift gates).

Layer guard, upward

This is the only design-facing page that may reference engine internals — and the duty runs the other way: a change that leaks engine complexity into Theme It's config surface or Use It's token vocabulary is wrong even when it's technically sound. State the layer impact of a proposed engine change in one line before shipping it.

Common questions → where to go