@motion-proto/live-tokens 0.33.1 → 0.35.0

package/dist-plugin/tokensCssMigrations/index.cjs

@@ -33,12 +33,16 @@ __export(tokensCssMigrations_exports, {
   TOKENS_CSS_MIGRATIONS: () => TOKENS_CSS_MIGRATIONS,
   collectDefinedTokens: () => collectDefinedTokens,
   collectReferencedTokens: () => collectReferencedTokens,
+  enforceBreakingRequiresMajor: () => enforceBreakingRequiresMajor,
   ensureScale: () => ensureScale,
+  findContractViolations: () => findContractViolations,
   readLiveTokensConfig: () => readLiveTokensConfig,
   removeToken: () => removeToken,
   removeTokensMatching: () => removeTokensMatching,
   renameToken: () => renameToken,
+  runAdditiveTokensCssMigrations: () => runAdditiveTokensCssMigrations,
   runTokensCssMigrations: () => runTokensCssMigrations,
+  semverBumpType: () => semverBumpType,
   validateTokensCss: () => validateTokensCss
 });
 module.exports = __toCommonJS(tokensCssMigrations_exports);
@@ -151,6 +155,7 @@ function escapeRe(s) {
 // vite-plugin/tokensCssMigrations/migrations/2026-05-29-typography-scale-additions.ts
 var tokensCssMigration_2026_05_29_typographyScaleAdditions = {
   id: "2026-05-29-typography-scale-additions",
+  kind: "additive",
   description: "Add --line-height-{xs..xl}, --letter-spacing-* and --ease-out-quart scales",
   apply(css) {
     let out = css;
@@ -189,6 +194,7 @@ var tokensCssMigration_2026_05_29_typographyScaleAdditions = {
 var KEEP_SEGMENTS = /* @__PURE__ */ new Set(["lg", "md", "sm"]);
 var tokensCssMigration_2026_05_29_sectiondividerLegacyAxisCleanup = {
   id: "2026-05-29-sectiondivider-legacy-axis-cleanup",
+  kind: "breaking",
   description: "Remove legacy --sectiondivider-* tokens not on the lg/md/sm axis",
   apply(css) {
     return removeTokensMatching(css, (name) => {
@@ -202,6 +208,7 @@ var tokensCssMigration_2026_05_29_sectiondividerLegacyAxisCleanup = {
 // vite-plugin/tokensCssMigrations/migrations/2026-06-03-transform-scale-additions.ts
 var tokensCssMigration_2026_06_03_transformScaleAdditions = {
   id: "2026-06-03-transform-scale-additions",
+  kind: "additive",
   description: "Add the --scale-{sm..2xl} transform-multiplier scale",
   apply(css) {
     return ensureScale(css, {
@@ -221,6 +228,7 @@ var tokensCssMigration_2026_06_03_transformScaleAdditions = {
 // vite-plugin/tokensCssMigrations/migrations/2026-06-04-remove-dead-size-icon-scale.ts
 var tokensCssMigration_2026_06_04_removeDeadSizeIconScale = {
   id: "2026-06-04-remove-dead-size-icon-scale",
+  kind: "breaking",
   description: "Remove the unused --size-icon-* scale (live scale is --icon-size-*)",
   apply(css) {
     return removeTokensMatching(css, (name) => name.startsWith("--size-icon-"));
@@ -230,6 +238,7 @@ var tokensCssMigration_2026_06_04_removeDeadSizeIconScale = {
 // vite-plugin/tokensCssMigrations/migrations/2026-06-04-easing-color-and-typescale-additions.ts
 var tokensCssMigration_2026_06_04_easingColorAndTypescaleAdditions = {
   id: "2026-06-04-easing-color-and-typescale-additions",
+  kind: "additive",
   description: "Add the full --ease-* scale, --color-white/black, and --font-size-7xl",
   apply(css) {
     let out = css;
@@ -345,9 +354,16 @@ var TOKENS_CSS_MIGRATIONS = [
   tokensCssMigration_2026_06_04_easingColorAndTypescaleAdditions
 ];
 function runTokensCssMigrations(css) {
+  return foldMigrations(css, () => true);
+}
+function runAdditiveTokensCssMigrations(css) {
+  return foldMigrations(css, (m) => m.kind === "additive");
+}
+function foldMigrations(css, include) {
   let out = css;
   const applied = [];
   for (const m of TOKENS_CSS_MIGRATIONS) {
+    if (!include(m)) continue;
     const next = m.apply(out);
     if (next !== out) {
       applied.push(m.id);
@@ -356,6 +372,45 @@ function runTokensCssMigrations(css) {
   }
   return { css: out, applied, changed: out !== css };
 }
+function findContractViolations(canonicalCss) {
+  const violations = [];
+  for (const m of TOKENS_CSS_MIGRATIONS) {
+    if (m.kind !== "additive") continue;
+    const before = collectDefinedTokens(canonicalCss);
+    const after = collectDefinedTokens(m.apply(canonicalCss));
+    const removed = [...before].filter((t) => !after.has(t)).sort();
+    if (removed.length) violations.push({ id: m.id, removed });
+  }
+  return violations;
+}
+function semverBumpType(prev, next) {
+  const p = parseSemver(prev);
+  const n = parseSemver(next);
+  if (n.major > p.major) return "major";
+  if (n.major === p.major && n.minor > p.minor) return "minor";
+  if (n.major === p.major && n.minor === p.minor && n.patch > p.patch) return "patch";
+  return "none";
+}
+function parseSemver(v) {
+  const [core] = v.replace(/^v/, "").split(/[-+]/);
+  const [major = 0, minor = 0, patch = 0] = core.split(".").map((n) => Number(n) || 0);
+  return { major, minor, patch };
+}
+function enforceBreakingRequiresMajor(args) {
+  const breakingIds = args.newMigrations.filter((m) => m.kind === "breaking").map((m) => m.id);
+  const bump = semverBumpType(args.prevVersion, args.nextVersion);
+  if (breakingIds.length === 0 || bump === "major") {
+    return { level: "ok", breakingIds, bump, message: "" };
+  }
+  const pre1 = parseSemver(args.nextVersion).major < 1;
+  const ids = breakingIds.join(", ");
+  return {
+    level: pre1 ? "warn" : "error",
+    breakingIds,
+    bump,
+    message: `Breaking token migration(s) [${ids}] are shipping in a ${bump} bump (${args.prevVersion} -> ${args.nextVersion}). Token names are public API; ` + (pre1 ? `pre-1.0 this is allowed, but the CHANGELOG must flag it under "Changed (breaking)".` : `from 1.0.0 a breaking token change requires a major bump.`)
+  };
+}
 function validateTokensCss(input) {
   const defined = /* @__PURE__ */ new Set([
     ...collectDefinedTokens(input.tokensCss),
@@ -385,11 +440,15 @@ function validateTokensCss(input) {
   TOKENS_CSS_MIGRATIONS,
   collectDefinedTokens,
   collectReferencedTokens,
+  enforceBreakingRequiresMajor,
   ensureScale,
+  findContractViolations,
   readLiveTokensConfig,
   removeToken,
   removeTokensMatching,
   renameToken,
+  runAdditiveTokensCssMigrations,
   runTokensCssMigrations,
+  semverBumpType,
   validateTokensCss
 });

package/dist-plugin/tokensCssMigrations/index.d.cts

@@ -16,6 +16,16 @@
 interface TokensCssMigration {
     /** Unique id; convention: `YYYY-MM-DD-<short-name>`. */
     id: string;
+    /**
+     * Whether this migration is backward-compatible.
+     *
+     * Token names are public API (see TOKENS.md). `'additive'` only ever inserts
+     * new names, so it is safe to auto-apply to a consumer's vendored `tokens.css`
+     * (the dev plugin's `autoMigrate`). `'breaking'` renames or removes a name a
+     * consumer may reference, so it ships only with a major version (post-1.0) and
+     * is never auto-applied — it rides an explicit `live-tokens migrate`.
+     */
+    kind: 'additive' | 'breaking';
     /** One-line summary shown by the CLI when the migration applies. */
     description: string;
     /** Pure, idempotent transform on the `tokens.css` source. */
@@ -113,6 +123,50 @@ interface RunResult {
 }
 /** Fold every registered migration over `css`. Pure and idempotent. */
 declare function runTokensCssMigrations(css: string): RunResult;
+/**
+ * Fold only the `additive` migrations. Additive changes only insert new token
+ * names, so applying them to a consumer's vendored `tokens.css` is always
+ * backward-compatible — this is what the dev plugin's `autoMigrate` runs. The
+ * `breaking` migrations (rename/remove) are deliberately skipped; they ride an
+ * explicit `live-tokens migrate` during a major upgrade.
+ */
+declare function runAdditiveTokensCssMigrations(css: string): RunResult;
+interface ContractViolation {
+    id: string;
+    /** Token names the migration removed or renamed away despite declaring `additive`. */
+    removed: string[];
+}
+/**
+ * Guardrail for the token-as-API contract: an `additive` migration must never
+ * remove or rename a token. We verify behaviorally rather than trusting the
+ * label — apply each additive migration to the package's own canonical
+ * `tokens.css` (which defines the full current vocabulary) and flag any token
+ * that disappears. A rename surfaces as the removal of its old name, so it is
+ * caught too. This catches the dangerous direction: a breaking change shipped as
+ * a backward-compatible one. (Over-labeling a no-op as `breaking` is harmless
+ * and not checked.)
+ */
+declare function findContractViolations(canonicalCss: string): ContractViolation[];
+type SemverBump = 'major' | 'minor' | 'patch' | 'none';
+/** Classify the bump from `prev` to `next` (leading `v` and pre-release tags ignored). */
+declare function semverBumpType(prev: string, next: string): SemverBump;
+interface BreakingGateResult {
+    level: 'ok' | 'warn' | 'error';
+    breakingIds: string[];
+    bump: SemverBump;
+    message: string;
+}
+/**
+ * The version side of the token contract: a `breaking` migration introduced in a
+ * release requires a major version bump. Pre-1.0 (next major is 0) this is only
+ * a warning, since semver permits breaking changes in 0.x minors; from 1.0.0 on
+ * it is an error. Pure so the release check and its tests share one rule.
+ */
+declare function enforceBreakingRequiresMajor(args: {
+    newMigrations: TokensCssMigration[];
+    prevVersion: string;
+    nextVersion: string;
+}): BreakingGateResult;
 interface ComponentSource {
     name: string;
     source: string;
@@ -141,4 +195,4 @@ interface ValidateInput {
  */
 declare function validateTokensCss(input: ValidateInput): MissingToken[];
 
-export { type ComponentSource, type MissingToken, type RunResult, TOKENS_CSS_MIGRATIONS, type TokensCssMigration, type ValidateInput, collectDefinedTokens, collectReferencedTokens, ensureScale, readLiveTokensConfig, removeToken, removeTokensMatching, renameToken, runTokensCssMigrations, validateTokensCss };
+export { type BreakingGateResult, type ComponentSource, type ContractViolation, type MissingToken, type RunResult, type SemverBump, TOKENS_CSS_MIGRATIONS, type TokensCssMigration, type ValidateInput, collectDefinedTokens, collectReferencedTokens, enforceBreakingRequiresMajor, ensureScale, findContractViolations, readLiveTokensConfig, removeToken, removeTokensMatching, renameToken, runAdditiveTokensCssMigrations, runTokensCssMigrations, semverBumpType, validateTokensCss };

package/dist-plugin/tokensCssMigrations/index.d.ts

@@ -16,6 +16,16 @@
 interface TokensCssMigration {
     /** Unique id; convention: `YYYY-MM-DD-<short-name>`. */
     id: string;
+    /**
+     * Whether this migration is backward-compatible.
+     *
+     * Token names are public API (see TOKENS.md). `'additive'` only ever inserts
+     * new names, so it is safe to auto-apply to a consumer's vendored `tokens.css`
+     * (the dev plugin's `autoMigrate`). `'breaking'` renames or removes a name a
+     * consumer may reference, so it ships only with a major version (post-1.0) and
+     * is never auto-applied — it rides an explicit `live-tokens migrate`.
+     */
+    kind: 'additive' | 'breaking';
     /** One-line summary shown by the CLI when the migration applies. */
     description: string;
     /** Pure, idempotent transform on the `tokens.css` source. */
@@ -113,6 +123,50 @@ interface RunResult {
 }
 /** Fold every registered migration over `css`. Pure and idempotent. */
 declare function runTokensCssMigrations(css: string): RunResult;
+/**
+ * Fold only the `additive` migrations. Additive changes only insert new token
+ * names, so applying them to a consumer's vendored `tokens.css` is always
+ * backward-compatible — this is what the dev plugin's `autoMigrate` runs. The
+ * `breaking` migrations (rename/remove) are deliberately skipped; they ride an
+ * explicit `live-tokens migrate` during a major upgrade.
+ */
+declare function runAdditiveTokensCssMigrations(css: string): RunResult;
+interface ContractViolation {
+    id: string;
+    /** Token names the migration removed or renamed away despite declaring `additive`. */
+    removed: string[];
+}
+/**
+ * Guardrail for the token-as-API contract: an `additive` migration must never
+ * remove or rename a token. We verify behaviorally rather than trusting the
+ * label — apply each additive migration to the package's own canonical
+ * `tokens.css` (which defines the full current vocabulary) and flag any token
+ * that disappears. A rename surfaces as the removal of its old name, so it is
+ * caught too. This catches the dangerous direction: a breaking change shipped as
+ * a backward-compatible one. (Over-labeling a no-op as `breaking` is harmless
+ * and not checked.)
+ */
+declare function findContractViolations(canonicalCss: string): ContractViolation[];
+type SemverBump = 'major' | 'minor' | 'patch' | 'none';
+/** Classify the bump from `prev` to `next` (leading `v` and pre-release tags ignored). */
+declare function semverBumpType(prev: string, next: string): SemverBump;
+interface BreakingGateResult {
+    level: 'ok' | 'warn' | 'error';
+    breakingIds: string[];
+    bump: SemverBump;
+    message: string;
+}
+/**
+ * The version side of the token contract: a `breaking` migration introduced in a
+ * release requires a major version bump. Pre-1.0 (next major is 0) this is only
+ * a warning, since semver permits breaking changes in 0.x minors; from 1.0.0 on
+ * it is an error. Pure so the release check and its tests share one rule.
+ */
+declare function enforceBreakingRequiresMajor(args: {
+    newMigrations: TokensCssMigration[];
+    prevVersion: string;
+    nextVersion: string;
+}): BreakingGateResult;
 interface ComponentSource {
     name: string;
     source: string;
@@ -141,4 +195,4 @@ interface ValidateInput {
  */
 declare function validateTokensCss(input: ValidateInput): MissingToken[];
 
-export { type ComponentSource, type MissingToken, type RunResult, TOKENS_CSS_MIGRATIONS, type TokensCssMigration, type ValidateInput, collectDefinedTokens, collectReferencedTokens, ensureScale, readLiveTokensConfig, removeToken, removeTokensMatching, renameToken, runTokensCssMigrations, validateTokensCss };
+export { type BreakingGateResult, type ComponentSource, type ContractViolation, type MissingToken, type RunResult, type SemverBump, TOKENS_CSS_MIGRATIONS, type TokensCssMigration, type ValidateInput, collectDefinedTokens, collectReferencedTokens, enforceBreakingRequiresMajor, ensureScale, findContractViolations, readLiveTokensConfig, removeToken, removeTokensMatching, renameToken, runAdditiveTokensCssMigrations, runTokensCssMigrations, semverBumpType, validateTokensCss };

package/dist-plugin/tokensCssMigrations/index.js

@@ -2,23 +2,31 @@ import {
   TOKENS_CSS_MIGRATIONS,
   collectDefinedTokens,
   collectReferencedTokens,
+  enforceBreakingRequiresMajor,
   ensureScale,
+  findContractViolations,
   readLiveTokensConfig,
   removeToken,
   removeTokensMatching,
   renameToken,
+  runAdditiveTokensCssMigrations,
   runTokensCssMigrations,
+  semverBumpType,
   validateTokensCss
-} from "../chunk-MJO4T3CM.js";
+} from "../chunk-D77VD4Z6.js";
 export {
   TOKENS_CSS_MIGRATIONS,
   collectDefinedTokens,
   collectReferencedTokens,
+  enforceBreakingRequiresMajor,
   ensureScale,
+  findContractViolations,
   readLiveTokensConfig,
   removeToken,
   removeTokensMatching,
   renameToken,
+  runAdditiveTokensCssMigrations,
   runTokensCssMigrations,
+  semverBumpType,
   validateTokensCss
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@motion-proto/live-tokens",
-  "version": "0.33.1",
+  "version": "0.35.0",
   "type": "module",
   "description": "Design token editor with live CSS variable editing. Svelte 5 + Vite 8.",
   "keywords": [
@@ -101,12 +101,13 @@
     "check:component-defaults": "node scripts/sync-component-defaults.mjs --check",
     "check:production-is-default": "node scripts/check-production-is-default.mjs",
     "check:docs-content": "node scripts/sync-docs.mjs --check",
+    "check:token-contract": "node scripts/check-token-contract.mjs",
     "sync:component-defaults": "node scripts/sync-component-defaults.mjs --write",
     "sync:docs": "node scripts/sync-docs.mjs --write",
     "collapse:manifest": "node scripts/collapse-manifest-to-default.mjs",
     "check:smoke-install": "bash scripts/smoke-install.sh",
     "check:smoke-create": "bash scripts/smoke-create.sh",
-    "prepublishOnly": "npm run check:no-style-imports && npm run check:slot-prose && npm run check:overlay-portal && npm run check:editor-font-isolation && npm run check:component-defaults && npm run check:production-is-default && npm run check:docs-content && npm run build:lib && npm run check:smoke-install && npm run check:smoke-create"
+    "prepublishOnly": "npm run check:no-style-imports && npm run check:slot-prose && npm run check:overlay-portal && npm run check:editor-font-isolation && npm run check:component-defaults && npm run check:production-is-default && npm run check:docs-content && npm run build:lib && npm run check:token-contract && npm run check:smoke-install && npm run check:smoke-create"
   },
   "peerDependencies": {
     "@sveltejs/vite-plugin-svelte": "^7.0",

package/src/editor/core/cssVarSync.ts

@@ -4,10 +4,10 @@
  * Writes to document.documentElement and — when running inside a same-origin
  * iframe (the live-preview overlay) — also writes to
  * window.parent.document.documentElement. This lets the overlay editor at
- * /editor drive the host site's :root in real time without any message-passing
- * infrastructure.
+ * /live-tokens/editor drive the host site's :root in real time without any
+ * message-passing infrastructure.
  *
- * When the editor runs standalone at /editor (not inside the overlay iframe),
+ * When the editor runs standalone at /live-tokens/editor (not inside the overlay iframe),
  * parentRoot is null and every call is a plain single-root write.
  *
  * Roots are resolved lazily — `init()` (or any setter call) populates them on

package/src/editor/core/routing/ownedRoutes.ts

@@ -0,0 +1,11 @@
+// The package's dev-only editor surfaces live under a reserved `/live-tokens/*`
+// namespace so they can never collide with a consumer's own routes — the
+// consumer owns the rest of the URL space. Keeping the defaults in one place
+// is the guard against the nav rail and the dispatcher drifting onto different
+// paths (the collision/shadow class these constants exist to prevent).
+//
+// A consumer relocates or disables each surface via the `editorRoutes` prop on
+// <LiveTokensRouter>; these are only the defaults.
+export const DEFAULT_EDITOR_PATH = '/live-tokens/editor';
+export const DEFAULT_COMPONENTS_PATH = '/live-tokens/components';
+export const DEFAULT_DOCS_PATH = '/live-tokens/docs';

package/src/editor/core/routing/router.ts

@@ -1,12 +1,13 @@
 import { writable } from 'svelte/store';
 import { storageKey } from '../store/editorConfig';
+import { DEFAULT_EDITOR_PATH } from './ownedRoutes';
 
 function prevKey(): string {
   return storageKey('prev-route');
 }
 
 function rememberPrev(current: string) {
-  if (current === '/editor') return;
+  if (current === DEFAULT_EDITOR_PATH) return;
   try { sessionStorage.setItem(prevKey(), current); } catch { /* ignore */ }
 }
 

package/src/editor/docs/Docs.svelte

@@ -39,6 +39,7 @@
 <script lang="ts">
   import { onMount, tick } from 'svelte';
   import { marked, type Tokens } from 'marked';
+  import { DEFAULT_COMPONENTS_PATH } from '../core/routing/ownedRoutes';
 
   import Button from '../../system/components/Button.svelte';
   import CodeSnippet from '../../system/components/CodeSnippet.svelte';
@@ -68,7 +69,7 @@
   let error = $state<string | null>(null);
   let chapterMeta = $state<Chapter | null>(null);
 
-  /* Parse `/docs#editing-tokens~palettes` → chapter `editing-tokens`, anchor `palettes`.
+  /* Parse `/live-tokens/docs#editing-tokens~palettes` → chapter `editing-tokens`, anchor `palettes`.
      Using `~` as the delimiter keeps each part valid for an HTML id. */
   let parsedHash = $derived.by(() => {
     const raw = hash.replace(/^#/, '');
@@ -269,7 +270,7 @@
               Demo Site
             </Button>
           </a>
-          <a href="/components" class="rail-action">
+          <a href={DEFAULT_COMPONENTS_PATH} class="rail-action">
             <Button variant="outline" size="small" icon="fas fa-puzzle-piece" fullWidth>
               Components
             </Button>

package/src/editor/docs/content/creating-components.md

@@ -26,13 +26,13 @@ Describe what you want in plain English. Phrases like these trigger the skill:
 
 Claude asks any clarifying questions it needs (which variants, which states,
 which parts), then writes the component, registers it with the editor, and runs
-its verification checklist. When it finishes, open `/components` to see your new
+its verification checklist. When it finishes, open `/live-tokens/components` to see your new
 component in the editor and confirm everything works.
 
 ## What you get
 
 - A runtime component whose editable properties default to your theme tokens.
-- An editor entry that appears under **Custom** in the `/components` view.
+- An editor entry that appears under **Custom** in the `/live-tokens/components` view.
 - The naming and wiring handled for you, so the component fits the system.
 
 Advanced authors who want to write a component by hand can read the naming and

package/src/editor/docs/content/getting-started.md

@@ -28,14 +28,14 @@ version upgrades never touch your styles. The package code stays in
 | Path | What it is |
 |------|------------|
 | `src/pages/Home.svelte` | The starter page. Replace it with your own content. |
-| `src/App.svelte` | Your routes. `<LiveTokensRouter>` adds the dev-only `/editor`, `/components`, and `/docs` routes. |
+| `src/App.svelte` | Your routes. `<LiveTokensRouter>` adds dev-only routes under a reserved `/live-tokens/*` namespace: `/live-tokens/editor`, `/live-tokens/components`, and `/live-tokens/docs`. |
 | `src/system/styles/tokens.css` | Your base token vocabulary, hand-authored. |
 | `src/styles/site.css` | Themed page typography, yours to edit. |
 
 ## Your first edit
 
 1. Run `npm run dev` and open the home page.
-2. Click **Open Token Editor**, or visit `/editor`. The editor opens beside
+2. Click **Open Token Editor**, or visit `/live-tokens/editor`. The editor opens beside
    the page.
 3. Open **Palettes**, pick **Brand**, and change the base hex. The page
    repaints as you type.

package/src/editor/docs/content.generated.ts

@@ -3,8 +3,8 @@
 
 export const docContent: Record<string, string> = {
   "01-overview": "# Overview\n\nLive Tokens is a design system for building Svelte microsites quickly. You\nstyle your site by editing tokens and components in a live editor. When it looks right, you save the manifest and ship it.\n\n## How it works\n\n- The editor runs in your dev server, on top of your real pages. You style in\n  context, not in a separate sandbox.\n- Every change updates a CSS variable, so the page repaints instantly. No\n  reload, no build step.\n- Saving writes a small JSON file into your project. Shipping bakes your chosen\n  theme into a plain CSS file that the build bundles.\n- The editor is dev-only. Production ships plain CSS variables and the\n  components you used, nothing else.\n\n## What you can edit\n\n- **Tokens**: the design-system primitives, colour palettes, type, spacing,\n  radius, shadow, and gradients, that apply across your whole site.\n- **Components**: the package ships about 25 editable components (Button, Card,\n  Dialog, Table, and more).You style components by changing the tokens assigned to each property.\n\n## Where to go next\n\n- **[Getting started](getting-started.md)**: scaffold a project and make your\n  first edit.\n- **[Editing tokens](editing-tokens.md)**: a tour of the editor.\n- **[Themes](themes-workflow.md)**: save, switch, and ship.\n- **[Creating components](creating-components.md)**: make your own components\n  editable.\n",
-  "creating-components": "# Creating components\n\nThe package ships about 25 editable components. When you need one it doesn't\nhave, you can make your own Svelte component editable, so anyone using the\neditor can re-point its colours, type, and spacing without touching code.\n\nThe simplest way is to ask Claude. The package bundles a Claude Code skill that\nknows the conventions, writes the files, and checks the result for you.\n\n## Install the skills\n\n```bash\nnpx @motion-proto/live-tokens setup-claude\n```\n\nThis copies the bundled skills into your project's `.claude/skills/`. Once\nthey're there, Claude Code picks them up automatically.\n\n## Ask for a component\n\nDescribe what you want in plain English. Phrases like these trigger the skill:\n\n- \"Add a Toggle component to live-tokens\"\n- \"Make this Svelte component editable in the live-tokens editor\"\n- \"Create a Stat component with a value and a label\"\n\nClaude asks any clarifying questions it needs (which variants, which states,\nwhich parts), then writes the component, registers it with the editor, and runs\nits verification checklist. When it finishes, open `/components` to see your new\ncomponent in the editor and confirm everything works.\n\n## What you get\n\n- A runtime component whose editable properties default to your theme tokens.\n- An editor entry that appears under **Custom** in the `/components` view.\n- The naming and wiring handled for you, so the component fits the system.\n\nAdvanced authors who want to write a component by hand can read the naming and\nstate-model conventions shipped in the package\n(`src/system/styles/CONVENTIONS.md` and the skill's own `SKILL.md`).\n",
+  "creating-components": "# Creating components\n\nThe package ships about 25 editable components. When you need one it doesn't\nhave, you can make your own Svelte component editable, so anyone using the\neditor can re-point its colours, type, and spacing without touching code.\n\nThe simplest way is to ask Claude. The package bundles a Claude Code skill that\nknows the conventions, writes the files, and checks the result for you.\n\n## Install the skills\n\n```bash\nnpx @motion-proto/live-tokens setup-claude\n```\n\nThis copies the bundled skills into your project's `.claude/skills/`. Once\nthey're there, Claude Code picks them up automatically.\n\n## Ask for a component\n\nDescribe what you want in plain English. Phrases like these trigger the skill:\n\n- \"Add a Toggle component to live-tokens\"\n- \"Make this Svelte component editable in the live-tokens editor\"\n- \"Create a Stat component with a value and a label\"\n\nClaude asks any clarifying questions it needs (which variants, which states,\nwhich parts), then writes the component, registers it with the editor, and runs\nits verification checklist. When it finishes, open `/live-tokens/components` to see your new\ncomponent in the editor and confirm everything works.\n\n## What you get\n\n- A runtime component whose editable properties default to your theme tokens.\n- An editor entry that appears under **Custom** in the `/live-tokens/components` view.\n- The naming and wiring handled for you, so the component fits the system.\n\nAdvanced authors who want to write a component by hand can read the naming and\nstate-model conventions shipped in the package\n(`src/system/styles/CONVENTIONS.md` and the skill's own `SKILL.md`).\n",
   "editing-tokens": "# Editing tokens\n\nA tour of the editor. The page behind it repaints on every change; saving\nwrites a theme file you can reload later.\n\nThe editor has two views:\n\n- **Tokens**: the design-system primitives (colour, type, spacing, and so on).\n  They apply everywhere your site uses them.\n- **Components**: per-component editors. Re-Assign what tokens a component uses\n  without changing the underlying system.\n\nThis page covers **Tokens**. For components, see\n[Creating components](creating-components.md).\n\n## Palettes\n\nMost colour work happens here. Each palette (Brand, Accent, Neutral, Canvas,\nSuccess, Warning, Info, Danger, and a few more) has:\n\n- **Base colour.** Pick a hex; the palette derives an 11-step ramp (100 to 950)\n  from it.\n- **Curves.** Two curves shape how lightness and saturation fall off across the\n  ramp. Drag the handles to bias it darker, lighter, or more saturated.\n- **Overrides.** Lock a single step to a hand-picked hex when the curve doesn't\n  land where you want.\n\nEditing a palette base ripples through every colour that depends on it, in real\ntime. Colours use OKLCH, so the ramp stays perceptually even across hues\nwithout muddy mid-tones.\n\n## Type\n\n- **Fonts.** Add sources from Google Fonts, Adobe (Typekit), a CSS URL, or an\n  inline `@font-face`. The font loads in the page as soon as you add it.\n- **Stacks.** Named font cascades you reference by token, such as a display\n  stack and a body stack.\n- **Sizes and weights.** A t-shirt scale (xs, sm, md, lg, xl, 2xl…) for size and\n  a numeric scale (100 to 900) for weight.\n\n## Spacing, radius, shadow\n\nNumeric scales with a slider per step.\n\n- **Spacing**: the padding, gap, and margin scale.\n- **Radius**: none through full.\n- **Shadow**: colour, offset, blur, spread, and opacity per step, with stacked\n  shadows supported.\n\nChange a step and every element using it repaints.\n\n## Overlays and gradients\n\n- **Overlays** are translucent tints layered over surfaces, like the subtle\n  tint a card gets on hover. Set a colour and opacity per state.\n- **Gradients** are reusable gradient tokens with a stop list and direction, for\n  hero panels and accent backgrounds.\n\n## Columns\n\nThe page-grid overlay. Set column count, gutter, and outer margin, and toggle\nthe visual guide with `Cmd/Ctrl+G`. Pages built on the column system reflow\nlive.\n\n## Saving\n\nThe editor saves to your browser continuously, so work survives a reload\nmid-edit. **Save** is a separate step: it writes a named theme file under\n`src/live-tokens/data/themes/`.\n\nThe header gives you undo/redo (`Cmd/Ctrl+Z`, `Cmd/Ctrl+Shift+Z`) and a file\nmenu for New, Save, Save as, Switch, and Delete. You can keep many themes side\nby side; one is active at a time. See [Themes](themes-workflow.md) for the full\nlifecycle.\n",
-  "getting-started": "# Getting started\n\nScaffold a live token site in a moments. You need Node 20 or later, a\npackage manager (npm, pnpm, or yarn), and a browser. Open claude code in your repo and start building.\n\n## Scaffold a new app\n\n```bash\nnpm create @motion-proto/live-tokens@latest my-app\ncd my-app\nnpm install\nnpm run dev\n```\n\nOpen the URL Vite prints (usually `http://localhost:5173`). You get a\none-page Svelte + Vite app that depends on the published package, with the\neditor wired up and the full component set ready to import.\n\n`npx @motion-proto/live-tokens create my-app` runs the same scaffold without\nthe initialiser package.\n\n### What the scaffold gives you\n\nEvery editable file lives under `src/` and is committed, so `npm install` and\nversion upgrades never touch your styles. The package code stays in\n`node_modules`.\n\n| Path | What it is |\n|------|------------|\n| `src/pages/Home.svelte` | The starter page. Replace it with your own content. |\n| `src/App.svelte` | Your routes. `<LiveTokensRouter>` adds the dev-only `/editor`, `/components`, and `/docs` routes. |\n| `src/system/styles/tokens.css` | Your base token vocabulary, hand-authored. |\n| `src/styles/site.css` | Themed page typography, yours to edit. |\n\n## Your first edit\n\n1. Run `npm run dev` and open the home page.\n2. Click **Open Token Editor**, or visit `/editor`. The editor opens beside\n   the page.\n3. Open **Palettes**, pick **Brand**, and change the base hex. The page\n   repaints as you type.\n4. Open the file menu and choose **Save as**. A theme appears as JSON under\n   `src/live-tokens/data/themes/`.\n5. Reload. Your saved theme is the active theme, so the page returns as you\n   left it.\n\n## What you just changed\n\nEvery edit sets a CSS custom property on `:root`. Your components read those\nproperties through `var(--...)`. There is no token build step and no\npreprocessor rewriting your code: the page renders against plain CSS variables\nthe editor swaps live.\n\nTo ship, promote a theme to production in the editor. That bakes the theme's\nvariables into `src/live-tokens/data/tokens.generated.css`, which your build\nbundles alongside `tokens.css`. The editor itself never reaches production.\n\nAlready have a Svelte 5 + Vite app? The\n[README](https://github.com/motionproto/live-tokens#readme) covers installing\ninto an existing project.\n\n## Where to go next\n\n- **[Editing tokens](editing-tokens.md)**: a tour of the editor.\n- **[Themes](themes-workflow.md)**: save, switch, and ship.\n- **[Creating components](creating-components.md)**: make your own component\n  editable.\n",
+  "getting-started": "# Getting started\n\nScaffold a live token site in a moments. You need Node 20 or later, a\npackage manager (npm, pnpm, or yarn), and a browser. Open claude code in your repo and start building.\n\n## Scaffold a new app\n\n```bash\nnpm create @motion-proto/live-tokens@latest my-app\ncd my-app\nnpm install\nnpm run dev\n```\n\nOpen the URL Vite prints (usually `http://localhost:5173`). You get a\none-page Svelte + Vite app that depends on the published package, with the\neditor wired up and the full component set ready to import.\n\n`npx @motion-proto/live-tokens create my-app` runs the same scaffold without\nthe initialiser package.\n\n### What the scaffold gives you\n\nEvery editable file lives under `src/` and is committed, so `npm install` and\nversion upgrades never touch your styles. The package code stays in\n`node_modules`.\n\n| Path | What it is |\n|------|------------|\n| `src/pages/Home.svelte` | The starter page. Replace it with your own content. |\n| `src/App.svelte` | Your routes. `<LiveTokensRouter>` adds dev-only routes under a reserved `/live-tokens/*` namespace: `/live-tokens/editor`, `/live-tokens/components`, and `/live-tokens/docs`. |\n| `src/system/styles/tokens.css` | Your base token vocabulary, hand-authored. |\n| `src/styles/site.css` | Themed page typography, yours to edit. |\n\n## Your first edit\n\n1. Run `npm run dev` and open the home page.\n2. Click **Open Token Editor**, or visit `/live-tokens/editor`. The editor opens beside\n   the page.\n3. Open **Palettes**, pick **Brand**, and change the base hex. The page\n   repaints as you type.\n4. Open the file menu and choose **Save as**. A theme appears as JSON under\n   `src/live-tokens/data/themes/`.\n5. Reload. Your saved theme is the active theme, so the page returns as you\n   left it.\n\n## What you just changed\n\nEvery edit sets a CSS custom property on `:root`. Your components read those\nproperties through `var(--...)`. There is no token build step and no\npreprocessor rewriting your code: the page renders against plain CSS variables\nthe editor swaps live.\n\nTo ship, promote a theme to production in the editor. That bakes the theme's\nvariables into `src/live-tokens/data/tokens.generated.css`, which your build\nbundles alongside `tokens.css`. The editor itself never reaches production.\n\nAlready have a Svelte 5 + Vite app? The\n[README](https://github.com/motionproto/live-tokens#readme) covers installing\ninto an existing project.\n\n## Where to go next\n\n- **[Editing tokens](editing-tokens.md)**: a tour of the editor.\n- **[Themes](themes-workflow.md)**: save, switch, and ship.\n- **[Creating components](creating-components.md)**: make your own component\n  editable.\n",
   "themes-workflow": "# Themes\n\nSave your work, switch between themes, and ship one to production.\n\n## How themes work\n\n- **Your live edits** are what the page shows right now. They save to your\n  browser automatically and survive a reload, but they are not yet a file.\n- **A saved theme** is a named JSON file in `src/live-tokens/data/themes/`. You\n  create one with **Save as**.\n- **The active theme** is the saved theme the page loads at startup. Exactly one\n  at a time.\n- **The production theme** is the one that ships. Promoting sets it.\n\n## Saving\n\nIn the editor header:\n\n- **Save** updates the current theme.\n- **Save as** names a new theme. Use it for your first save and for forking.\n\nNames are tidied to lowercase with underscores, so \"My Brand!\" becomes\n`my_brand`. There is a built-in `default` theme you can always return to; the\neditor never overwrites it.\n\n## Switching\n\nThe file menu lists every saved theme. Pick one to make it active; the page\nreloads with it applied. Your current edits are saved to the previous theme\nfirst, so you don't lose work.\n\n## Shipping\n\n**Promote to production** is the \"ship it\" step. It bakes the theme's variables\ninto `src/live-tokens/data/tokens.generated.css`, which your build bundles\nalongside `tokens.css`. Fonts regenerate to match.\n\nProduction builds (`npm run build`) ship only that plain CSS and your\ncomponents. No editor, no JSON loading, no runtime indirection. If you save\nwhile the production theme is active, the generated CSS updates immediately,\nwith no separate promote step.\n\n## Manifests\n\nA **manifest** bundles one theme plus a config for each component into a single\nnamed set. Useful when you run several brands and want each to apply its theme\nand component tweaks in one move. There is a protected default and an active\nmanifest; applying one swaps everything at once.\n\n## Keeping your work safe\n\nEverything under `src/live-tokens/data/` is plain JSON, so commit it. Themes\nshow up as readable diffs you can review per branch. There are no automatic\nbackups: git is your safety net. To experiment freely, **Save as** a new name\nfirst, then edit.\n\n## Where to go next\n\n- **[Creating components](creating-components.md)**: make your own components\n  editable in the same editor.\n",
 };

package/src/editor/overlay/LiveEditorOverlay.svelte

@@ -15,6 +15,7 @@
   import { fade } from 'svelte/transition';
   import { cubicInOut } from 'svelte/easing';
   import { route, navigate } from '../core/routing/router';
+  import { DEFAULT_EDITOR_PATH, DEFAULT_COMPONENTS_PATH } from '../core/routing/ownedRoutes';
   import { editorView } from '../core/store/editorViewStore';
   import { columnsVisible, toggleColumns } from './columnsOverlay';
   import { storageKey } from '../core/store/editorConfig';
@@ -27,6 +28,7 @@
   interface Props {
     open?: boolean | undefined;
     editorPath?: string;
+    componentsPath?: string;
     navLinks?: NavLink[];
     pageSources?: Record<string, string>;
     hidePageSourceOn?: string[];
@@ -35,7 +37,8 @@
 
   let {
     open = $bindable(undefined),
-    editorPath = '/editor',
+    editorPath = DEFAULT_EDITOR_PATH,
+    componentsPath = DEFAULT_COMPONENTS_PATH,
     navLinks = [],
     pageSources = {},
     hidePageSourceOn = [],
@@ -62,9 +65,9 @@
     overlayOpen.set(!!open);
   });
 
-  // The /components route renders the same component-editor surface as the
-  // overlay's components view. Pair them: on entering /components, flip the
-  // overlay to tokens so the two surfaces don't stack. Fires only on route
+  // The components route renders the same component-editor surface as the
+  // overlay's components view. Pair them: on entering it, flip the overlay to
+  // tokens so the two surfaces don't stack. Fires only on route
   // change, not on every editorView change — otherwise cross-window storage
   // sync re-triggers the rule, which writes editorView, which fires another
   // storage event, which fires the rule again. The result is heavy re-render
@@ -75,7 +78,7 @@
     const r = $route;
     if (r === prevRoute) return;
     prevRoute = r;
-    if (r === '/components') {
+    if (r === componentsPath) {
       editorView.update((v) => (v === 'components' ? 'tokens' : v));
     }
   });

package/src/editor/overlay/LiveTokensRouter.svelte

@@ -28,9 +28,11 @@
   }
 
   /**
-   * Override the default editor routes (`/editor`, `/components`, `/docs`).
-   * Pass a string to relocate the route; pass `false` to disable it entirely
-   * (no dispatch and, for `components`/`docs`, no auto-injected nav-rail entry).
+   * Override the package's dev-only routes, which default to the reserved
+   * `/live-tokens/*` namespace (`/live-tokens/editor`, `/live-tokens/components`,
+   * `/live-tokens/docs`) so they never collide with consumer pages. Pass a
+   * string to relocate a route; pass `false` to disable it entirely (no
+   * dispatch and, for `components`/`docs`, no auto-injected nav-rail entry).
    */
   export interface EditorRouteOverrides {
     editor?: string | false;
@@ -40,8 +42,8 @@
 
   /**
    * Resolve a path to the single entry that renders it. Precedence, after the
-   * package-owned routes (`/editor`, `/components`, `/docs`) have already been
-   * matched by the component:
+   * package-owned `/live-tokens/*` routes (editor, components, docs) have
+   * already been matched by the component:
    *
    *   1. `pages[route]` — exact static match.
    *   2. `resolve(route)` — consumer code, where params / prefixes / gating
@@ -66,6 +68,7 @@
   import LiveEditorOverlay from './LiveEditorOverlay.svelte';
   import ColumnsOverlay from './ColumnsOverlay.svelte';
   import { route, navigate } from '../core/routing/router';
+  import { DEFAULT_EDITOR_PATH, DEFAULT_COMPONENTS_PATH, DEFAULT_DOCS_PATH } from '../core/routing/ownedRoutes';
 
   interface Props {
     pages: Record<string, RouteEntry>;
@@ -84,9 +87,9 @@
   let editorEnabled = $derived(editorRoutes.editor !== false);
   let componentsEnabled = $derived(editorRoutes.components !== false);
   let docsEnabled = $derived(editorRoutes.docs !== false);
-  let editorPath = $derived(typeof editorRoutes.editor === 'string' ? editorRoutes.editor : '/editor');
-  let componentsPath = $derived(typeof editorRoutes.components === 'string' ? editorRoutes.components : '/components');
-  let docsPath = $derived(typeof editorRoutes.docs === 'string' ? editorRoutes.docs : '/docs');
+  let editorPath = $derived(typeof editorRoutes.editor === 'string' ? editorRoutes.editor : DEFAULT_EDITOR_PATH);
+  let componentsPath = $derived(typeof editorRoutes.components === 'string' ? editorRoutes.components : DEFAULT_COMPONENTS_PATH);
+  let docsPath = $derived(typeof editorRoutes.docs === 'string' ? editorRoutes.docs : DEFAULT_DOCS_PATH);
 
   const isDev = import.meta.env.DEV;
   let isEditor = $derived(isDev && editorEnabled && $route === editorPath);
@@ -176,7 +179,7 @@
   class:is-component-editor={isComponentEditor}
   onclick={handleClick}
 >
-  <LiveEditorOverlay {navLinks} {pageSources} {hidePageSourceOn} {editorPath} />
+  <LiveEditorOverlay {navLinks} {pageSources} {hidePageSourceOn} {editorPath} {componentsPath} />
   <ColumnsOverlay />
 
   {#await pagePromise then m}

package/src/editor/pages/Editor.svelte

@@ -5,6 +5,7 @@
   import { installEditorKeybindings } from '../core/store/editorKeybindings';
   import { initializeEditorStore } from '../core/store/editorStore';
   import { storageKey } from '../core/store/editorConfig';
+  import { DEFAULT_EDITOR_PATH } from '../core/routing/ownedRoutes';
   // Editor chrome + form controls + icon font must be JS imports (not @import
   // inside the style block) so Vite resolves them via the module graph
   // regardless of how the consumer compiles Svelte CSS (external ?lang.css vs
@@ -23,7 +24,7 @@
   function pickBackHref(): string {
     try {
       const prev = sessionStorage.getItem(storageKey('prev-route'));
-      if (prev && prev !== '/editor') return prev;
+      if (prev && prev !== DEFAULT_EDITOR_PATH) return prev;
     } catch {
       // ignore
     }

package/src/editor/ui/EditorViewSwitcher.svelte

@@ -1,6 +1,7 @@
 <script lang="ts">
   import { editorView } from '../core/store/editorViewStore';
   import { parentRoute } from '../core/routing/parentRouteStore';
+  import { DEFAULT_COMPONENTS_PATH } from '../core/routing/ownedRoutes';
 
   interface Props {
     condensed?: boolean;
@@ -8,11 +9,13 @@
 
   let { condensed = false }: Props = $props();
 
-  // On /components the host page is already the components editor — the
-  // overlay's components view would just stack on top of it, so disable the
+  // On the components route the host page is already the components editor —
+  // the overlay's components view would just stack on top, so disable the
   // switch. The switcher renders inside the editor iframe, so we read the
-  // *parent* route, not this iframe's own route.
-  let componentsDisabled = $derived($parentRoute === '/components');
+  // *parent* route, not this iframe's own. Compares the default path:
+  // editorRoutes.components relocation isn't plumbed across the iframe, so a
+  // relocated route won't disable the switch.
+  let componentsDisabled = $derived($parentRoute === DEFAULT_COMPONENTS_PATH);
 
   function set(v: 'tokens' | 'components') {
     editorView.set(v);