principle. the base adapts to what the user already has; identity is offered, not imposed. a user arrives with a wallpaper, a desktop, a palette they already live in. a design language that fights that palette loses to it; a base lane that derives from it — under discipline — starts every installation already at home.

rule — the base lane (law). the default theme is dynamic colour: a seed taken from the user’s wallpaper is passed through a derivation engine (hue–chroma–tone expansion into the full role ladder) and then through the glaze governor, which clamps chroma per role into the muted band (the governor’s clamps are ratified as approach by decision 0020; their numbers tune on the first real surfaces and freeze once two surfaces agree). the accent law applies to the derived values in full: the tint ceiling, no solid fills, and one governing hue per surface — the derived palette resolves to exactly one governing hue wherever it lands. derivation is one-shot per seed change the user makes, producing an ordinary theme; there is no continuous re-derivation, no ambient repainting, and applying anything never silently re-accents the shell. ungoverned full-strength dynamic colour remains an anti-steal: what changed is the lane, not the governor.

rule — the settings alternatives (law). theme selection in settings presents three lanes side by side:

1. the dynamic base — the default selection, described above.
2. authored palettes — the named set, fully supported and picked explicitly: oled (the dark flagship), porcelain (the light flagship), cinema, midnight.
3. ported themes — the user’s own imports, under the port contract below.

rule — the dynamic family (law; decision 0021). the base lane does not derive one palette from a seed, it derives a family: a small set of named variant palettes computed from the same seed in one pass, offered side by side in settings the way mobile platforms offer their derived colour stories. the variants differ in how faithfully and how loudly they read the seed, never in grammar:

• faithful — the derived ladder closest to the seed’s own hues; the default variant.
• soft — the same ladder pulled furthest into the muted band; the quietest reading.
• vivid — chroma raised toward the top of the governor’s band; the loudest reading glaze permits, still clamped.
• mono — the seed’s hue governs accents only; surfaces resolve to the neutral ladder.

every variant passes the same governor and the same accent law; switching variants is a theme switch, instant and total, never a repaint in flight. authored palettes are not variants: they are whole other stories, and they sit in their own lane.

rule — theme validity (law; decision 0018). a valid theme resolves every token in the vocabulary. the loader adopts the porter’s rule: no silent default-filling. a theme that fails renders in the degraded state (a named pattern): what still works, what is disabled, one recovery action.

rule — the port contract (law). porting a foreign theme is an automated, clean pipeline, not a hand translation:

• import → map → select. the user supplies a VS Code theme file; the pipeline maps its colour values automatically into glaze colour slots; the result appears as a selectable theme in settings, beside the authored set.
• colour values only. a port consumes the source’s colour keys and maps them to glaze semantic colour roles. a port may touch colour slots only: motion, density, haptics, and geometry stay glaze core, whatever the source file claims.
• the governor applies to ported results exactly as to derived ones: chroma clamped into the muted band, accent law intact.
• unmapped and missing roles fall back per the theme-validity rule above.
• ported themes are user property: stored once, at suite level, not per app; shareable as files; never uploaded, never re-derived behind the user’s back.

proposal, pending ratification — faithful-import mode. one distinction inside the contract: a mode in which the user explicitly asks for the source’s colours ungoverned. whether that mode exists, and how loudly it must announce itself, is proposed, not law.

rule — themes as units (law). a theme is a portable unit: tokens, an optional wallpaper, and a name, in one importable artefact. selecting a theme repaints everything live — no restart, and no transition smear. the porter core itself is a glaze asset, versioned with the role vocabulary; apps write only the surfaces that invoke it (normative in docs/foundations/theme-porter-placement.md).

rule — adaptive is defined (law; decision 0019). the theme schema’s adaptive field is the follow-the-sun / OS-sync opt-in flag: when set, the surface may follow the operating system’s light/dark and scheduled shifts. it is an option under options-where-lean (decision 0004): zero idle cost, authored default unchanged.

worked example. a fresh install on a desk whose wallpaper is a deep green photograph: the base lane derives a muted green-leaning ladder, the governor pulls its chroma down into the band, and the popover opens already belonging to that desk — one governing hue, tints under the ceiling, nothing full-strength. the user who wants the authored story instead opens settings and picks porcelain; the user with a beloved editor theme imports it, watches it land beside the authored set as their property, and loses none of glaze’s motion, density, or manners in the exchange.

---

Canonical text: §14, themes, the dynamic base, and the porter, in the design language document. Governed by decisions 0018, 0019, 0020, and 0021.