ui-foundations 0.1.1 → 0.3.0

package/docs/agentic/skills/README.md

@@ -0,0 +1,51 @@
+# Agentic Skills
+
+This directory contains repo-specific skills for AI-assisted design-system work.
+
+## Available skills
+
+### design-ops-specialist
+
+Use for tactical, proposal-first work:
+
+- minimal component drafts
+- token naming proposals
+- CSS pattern structure suggestions
+- optional React wrapper API sketches
+- docs/playground integration plans
+
+Best when the question is close to implementation and should stay incremental and non-breaking.
+
+Path:
+- `docs/agentic/skills/design-ops-specialist/SKILL.md`
+
+### design-system-architect
+
+Use for strategic, system-level work:
+
+- foundation reviews
+- token governance decisions
+- component boundary decisions
+- Figma/code reconciliation
+- architecture-level handoff and system recommendations
+
+Best when the question is about whether something belongs in the system at all, how foundations should evolve, or how to restore consistency across Figma, tokens, code, and docs.
+
+Path:
+- `docs/agentic/skills/design-system-architect/SKILL.md`
+
+## Quick selection guide
+
+Use `design-ops-specialist` when the question sounds like:
+
+- "Propose a draft for this component"
+- "How should the token names look?"
+- "What files would change?"
+- "How would the CSS and docs be structured?"
+
+Use `design-system-architect` when the question sounds like:
+
+- "Should this be a standalone component or composition?"
+- "Do we need new semantic tokens?"
+- "Are the foundations still coherent?"
+- "How do we reconcile Figma and code drift?"

package/docs/agentic/skills/design-ops-specialist/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: design-ops-specialist
+description: "Tactical proposal-first guidance for token-first component work in this repo and package consumers. Use when a request asks for a minimal component draft, token naming proposal, CSS pattern structure under src/ui/patterns, optional React wrapper API, docs/playground integration, or a concrete implementation plan that should stay incremental and non-breaking. Prefer design-system-architect instead when the request is about foundations, token governance, component-boundary decisions, Figma/code drift, or system-wide architecture."
+---
+
+# Design Ops Specialist
+
+## Intent
+
+Use this skill for tactical, proposal-first work before or just ahead of implementation.
+
+This skill is narrower than `design-system-architect`.
+
+- Use `design-ops-specialist` for concrete component drafts and repo-shaped implementation proposals.
+- Use `design-system-architect` for system-wide reviews, governance, and architecture decisions.
+
+## Workflow
+
+1. Confirm scope and constraints:
+   - component name
+   - parts / variants / states
+   - platform or framework constraints
+   - whether the ask is proposal-only or implementation-adjacent
+2. Align with source rules:
+   - `docs/foundations/`
+   - `docs/agentic/assistant-behavior-rules.md`
+   - `docs/agentic/team-ai-playbook.md`
+3. If the request implies a new system component, call out that boundary validation is required and defer the strategic decision to `design-system-architect` when needed.
+4. Produce a concise proposal by default, with no code changes unless explicitly requested.
+5. Keep proposals minimal, incremental, and non-breaking.
+
+## Output format
+
+Provide these sections:
+
+1. Boundary assumption
+   - whether this is assumed to be composition or a valid standalone candidate
+   - if unclear, say so briefly
+2. Token naming proposal
+   - prefix, variants, parts, states
+   - alignment to foundations naming rules
+3. CSS pattern structure
+   - target files under `src/ui/patterns` or existing family integration
+   - expected class names and token hookups
+4. Optional React wrapper API
+   - only when requested or clearly needed
+   - props mapped to token variants/states
+5. Docs + playground integration
+   - required docs pages/sections
+   - playground additions or updates
+6. Implementation surface
+   - exact repo paths likely to change
+
+## Guardrails
+
+- Prefer extending existing patterns over introducing new frameworks.
+- Keep recommendations compatible with token-first and Figma-aligned architecture.
+- Do not broaden into foundations governance unless explicitly asked.
+- If requirements are underspecified, ask targeted clarifying questions or state minimal assumptions.
+- If the task is really about whether something belongs in the system at all, hand off conceptually to `design-system-architect`.

package/docs/agentic/skills/design-system-architect/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: design-system-architect
+description: "Strategic design-system architecture for this repo. Use when reviewing or evolving foundations, deciding token governance, evaluating component boundaries, reconciling Figma/code drift, auditing semantic coverage, or making architecture-level decisions that span beyond a single component proposal. Prefer this skill over design-ops-specialist when the request is system-wide, governance-heavy, or about whether something should enter the system at all."
+---
+
+# Design System Architect
+
+## Intent
+
+Use this skill for system-level decisions, reviews, and governance.
+
+This skill is broader than `design-ops-specialist`.
+
+- Use `design-ops-specialist` for tactical, proposal-first component drafts.
+- Use `design-system-architect` for architecture, boundaries, token governance, and Figma/code alignment decisions.
+
+## Required source alignment
+
+Before responding, align to these repo sources:
+
+- `docs/foundations/`
+- `docs/agentic/assistant-behavior-rules.md`
+- `docs/agentic/team-ai-playbook.md`
+
+At minimum, check these when relevant:
+
+- `docs/foundations/foundation-001-token-layering.md`
+- `docs/foundations/foundation-002-naming-and-grouping.md`
+- `docs/foundations/foundation-003-color-semantics-and-status.md`
+- `docs/foundations/foundation-009-component-boundaries-and-utility.md`
+- `docs/foundations/foundation-010-implementation-and-pipeline-workflow.md`
+- `docs/foundations/foundation-011-branching-and-release-governance.md`
+
+## Task types
+
+### 1. Foundation review
+
+Use when reviewing the health of the system.
+
+Check for:
+
+- layering integrity
+- semantic gaps
+- naming drift
+- duplicate concepts
+- hard-coded or leaky component decisions
+- weak state coverage
+- Figma/code mismatch
+
+### 2. Token governance
+
+Use when deciding whether to create, alias, rename, or reject token changes.
+
+Report:
+
+- correct layer
+- rationale
+- consumer scope
+- theme/mode impact
+- migration implications
+
+### 3. Boundary decision
+
+Use before proposing or implementing a new component.
+
+Decide:
+
+- composition inside an existing family, or
+- standalone system component
+
+Apply the Snowflake check from `foundation-009`.
+
+### 4. Figma/code reconciliation
+
+Use when system contracts drift between Figma and implementation.
+
+Review:
+
+- token exports in `figma/exports/`
+- Code Connect mappings in `figma/connections/`
+- implementation in `src/ui/` and `src/react/`
+- docs/playground representation in `site/components/`
+
+### 5. System handoff
+
+Use when another designer or engineer needs a structured architectural recommendation.
+
+## Output format
+
+Provide these sections when relevant:
+
+1. Task type
+2. Current system reading
+3. Decision
+4. Rationale
+5. Repo surfaces affected
+6. Risks / mismatches
+7. Recommended next step
+
+## Guardrails
+
+- Do not invent raw values inside components.
+- Keep the 4-layer architecture intact.
+- Treat token work and component boundary decisions as separate questions.
+- Prefer small, reviewable changes and feature-branch delivery.
+- Say explicitly when something should remain local instead of entering the system.

package/docs/agentic/team-ai-playbook.md

@@ -0,0 +1,226 @@
+# AI Playbook
+
+This playbook defines how to use AI as an engineering copilot in this repository.
+
+## Goal
+
+Use AI to speed up component incubation and implementation while keeping output:
+
+- token-first
+- reviewable in Git
+- consistent with existing architecture
+
+## Principles
+
+1. Keep changes small and incremental.
+2. Prefer existing patterns over introducing new abstractions.
+3. Keep Figma and code aligned through explicit token roundtrips.
+4. Always validate with local checks before pushing.
+
+## Component Boundary Check (Mandatory)
+
+Run this decision gate before implementing a "new component":
+
+1. Start with composition-first:
+   - If the new idea is primarily grouping, layout, or orchestration of existing components, implement it as composition within the existing component family and document it there.
+2. Promote to standalone only when needed:
+   - The candidate introduces distinct semantics (own role/responsibility), a stable API surface, or independent lifecycle/behavior that is not just a wrapper.
+3. Apply a utility test ("Snowflake check"):
+   - One-off/local case -> keep it local or document as composition.
+   - Reusable across contexts/products -> valid candidate for system-level component.
+4. Keep token work independent:
+   - New tokens may be needed in both paths.
+   - Token creation does not automatically justify a new standalone component.
+5. Source of truth:
+   - `docs/foundations/foundation-009-component-boundaries-and-utility.md`
+
+## Standard Workflow: New Component
+
+1. Run the Component Boundary Check and decide:
+   - standalone component, or
+   - composition inside existing component docs/API.
+2. Ask AI for a first proposal:
+   - structure: HTML/CSS/React
+   - token names and states
+   - docs + playground example
+3. Review and adjust naming before implementation.
+4. Add/import proposed tokens in Figma.
+5. Export tokens from Figma to `figma/exports/`.
+6. Let AI integrate implementation:
+   - `src/ui/patterns/<component>.css`
+   - `src/react/<component>.js` and `src/react/index.js` (if needed)
+   - `site/components/<component>.md`
+   - `site/components/<component>-playground.md`
+   - `figma/connections/web-<component>.figma.ts` (if needed)
+7. Run validation:
+   - `npm run ci:check`
+8. Iterate naming/states/a11y until stable.
+
+## Skill selection
+
+Use the repo skills intentionally:
+
+- `design-ops-specialist` for tactical, proposal-first component work
+- `design-system-architect` for strategic, system-level reviews and decisions
+
+See also:
+- `docs/agentic/skills/README.md`
+
+## Proposal Mode: Design Ops Specialist
+
+Use this mode when the request is explicitly a proposal (no implementation yet).
+
+1. Confirm scope and constraints first:
+   - component name
+   - variants/sizes/states/parts
+   - platform constraints
+2. Review source rules before proposing:
+   - `docs/foundations/`
+   - `docs/agentic/assistant-behavior-rules.md`
+   - this playbook
+3. Deliver a concise proposal with these sections:
+   - token naming proposal (variants/parts/states)
+   - CSS pattern structure under `src/ui/patterns`
+   - optional React wrapper API (only if requested/needed)
+   - docs + playground integration plan
+4. Keep recommendations minimal and non-breaking by default.
+
+## Standard Workflow: Token Roundtrip
+
+1. Create or update tokens in Figma.
+2. Export into `figma/exports/*.tokens.json`.
+3. Run:
+   - `npm run build:all`
+   - `npm run tokens:validate`
+4. Check output consistency:
+   - `dist/tokens/css/*.tokens.css`
+   - `dist/tokens/json/*.json`
+   - `dist/tokens/tokens.yaml`
+5. If warnings appear (missing/invalid WEB syntax, alias issues), fix in Figma first.
+
+## Standard Workflow: Figma Drift Reconciliation
+
+Use this when the component was scaffolded in code first and component variables/variants are created or changed in Figma afterwards.
+
+1. Define the contract first:
+   - component API (props/states/semantics)
+   - token names and expected usage
+2. Update Figma variables/variants and export tokens:
+   - `figma/exports/*.tokens.json`
+3. Rebuild token artifacts:
+   - `npm run build:all`
+   - `npm run tokens:validate`
+4. Reconcile Code Connect mappings:
+   - update `figma/connections/web-<component>.figma.ts`
+   - align node-id targets and property names with actual Figma top-level component/component set
+   - run `figma connect parse`
+   - run `figma connect publish --dry-run`
+5. Reconcile implementation only where needed:
+   - adjust CSS/React/docs/playground to match agreed contract
+   - avoid broad rewrites; keep changes minimal
+6. Validate and stabilize:
+   - `npm run lint`
+   - `npm run test:unit`
+   - `npm run ci:check`
+7. Commit with explicit scope, for example:
+   - `chore(figma): reconcile <component> code-connect mapping`
+   - `feat(<component>): align states and tokens with figma`
+
+## Standard Workflow: Refactor and Quality
+
+1. Ask AI to identify one small refactor target.
+2. Implement only one focused change set.
+3. Add or update tests when behavior is touched.
+4. Run:
+   - `npm run lint`
+   - `npm run test:unit`
+   - `npm run ci:check`
+5. Commit with clear scope in message.
+
+## Prompt Templates
+
+### 1) New component incubation
+
+```text
+You are my Design OPS Manager. Propose a token-first setup for a new <component>.
+Include:
+- token naming proposal (variants/parts/states)
+- CSS pattern structure under src/ui/patterns
+- optional React wrapper API
+- docs + playground integration
+Keep changes minimal and aligned with existing repository conventions.
+```
+
+### 2) Token integration after Figma export
+
+```text
+I updated figma/exports. Please run the token/build pipeline, review warnings,
+and apply minimal fixes so docs and bundles are green.
+```
+
+### 3) Safe refactor
+
+```text
+Refactor <target file/module> for maintainability in small steps only.
+No behavior changes. Add tests if needed. Keep ci:check green.
+```
+
+### 4) Prompt to UI component (scaffold + implement)
+
+```text
+Scaffold and implement a new UI component named <component-name> in this repository.
+
+Follow these sources strictly:
+- docs/agentic/team-ai-playbook.md
+- docs/agentic/assistant-behavior-rules.md
+- docs/foundations/*
+
+Execution requirements:
+1) Run the Component Boundary Check first and state the decision (composition vs standalone).
+2) Keep scope small, incremental, and reviewable in Git.
+3) Implement token-first and reuse existing patterns:
+   - src/ui/patterns/<component>.css
+   - src/react/<component>.js and src/react/index.js (if needed)
+   - site/components/<component>.md
+   - site/components/<component>-playground.md
+   - figma/connections/web-<component>.figma.ts (only if a publishable top-level Figma component/component-set exists)
+4) Validate before handoff:
+   - npm run lint
+   - npm run test:unit
+   - npm run ci:check
+
+Mandatory progress tracker for this task type:
+- Start with: Tasks completion: 0/4
+- Update after each phase: 1/4, 2/4, 3/4, 4/4
+
+Handoff format:
+- boundary decision result
+- files changed
+- validation results
+- open follow-ups (if any)
+```
+
+## Definition of Done (AI Task)
+
+- Scope is clear and minimal.
+- Affected files are easy to review.
+- No broken exports or docs.
+- `npm run ci:check` passes.
+- README/docs updated when behavior or workflow changes.
+
+## Worked example: Button Group
+
+This repository now includes a concrete walkthrough based on a `Button Group`:
+
+1. AI proposal:
+   - layout model (`orientation`, `attached`, `justify`)
+   - token proposal (`--button-group-gap`, `--button-group-border-radius`)
+2. Implementation in code:
+   - integrated button family CSS: `src/ui/patterns/button.css`
+   - React wrapper API in `src/react/button.js` (`ButtonGroup`)
+3. Documentation:
+   - integrated in `site/components/button.md` under grouped usage
+4. Validation:
+   - `npm run ci:check`
+
+Use this pattern as the reference baseline for future AI-assisted component incubation where wrappers extend an existing component family.

package/docs/foundations/foundation-010-implementation-and-pipeline-workflow.md

@@ -0,0 +1,82 @@
+# Foundation-010: Implementation and Pipeline Workflow
+
+## Purpose
+
+Define the stable implementation workflow for adding or updating UI foundations artifacts, including token generation, component integration, docs updates, and validation.
+
+## Rules
+
+1. Follow this sequence for new components:
+   - Run boundary + utility check first (see Foundation-009).
+   - Add/update Figma token exports in `figma/exports/`.
+   - Regenerate artifacts via `npm run build:all`.
+   - Add or update CSS pattern in `src/ui/patterns/`.
+   - Export pattern in `src/ui/index.css`.
+   - Add React wrapper only when needed.
+   - Add docs + playground pages in `site/components/`.
+
+2. Keep changes token-first:
+   - Components consume semantic/foundation tokens.
+   - Do not introduce component-local hard-coded colors.
+
+3. Treat generated output as build artifacts:
+   - `dist/tokens/` and `dist/` are generated outputs.
+   - Build scripts in `scripts/` are the source for generation behavior.
+
+4. Keep package runtime mode policy consumer-owned:
+   - Token outputs define scopes/selectors.
+   - Consumers decide when/how `data-mode` and `data-brand` are applied.
+
+## Build and Validation
+
+Use these commands as the baseline:
+
+- `npm run lint`
+- `npm run test:unit`
+- `npm run ci:check`
+
+Additional useful commands:
+
+- `npm run tokens:generate`
+- `npm run build:css`
+- `npm run build:all`
+- `npm run docs:site`
+
+## Token Pipeline Notes
+
+`scripts/extract-tokens.js` orchestrates generation.
+
+Key helpers:
+
+- `scripts/extract-tokens.utils.js`
+- `scripts/extract-tokens.lookup.js`
+- `scripts/extract-tokens.value.js`
+- `scripts/extract-tokens.scope.js`
+
+Scope behavior from export filenames:
+
+- `Brand X.tokens.json` -> `:root[data-brand="x"]`
+- `Mode Light.tokens.json` -> `:root`
+- `Mode Dark.tokens.json` -> `:root[data-mode="dark"]`
+
+Fallback behavior:
+
+- Missing or invalid `com.figma.codeSyntax.WEB` falls back to auto-derived CSS variable names and is reported.
+- Missing alias targets and alias cycles fall back to literal values and are reported.
+
+## AI-Assisted Workflow
+
+When using assistants for component incubation:
+
+1. Define boundary (composition vs standalone).
+2. Propose token naming + component structure.
+3. Align/update Figma tokens.
+4. Regenerate and integrate in code.
+5. Update docs/playground.
+6. Run validation commands before handoff.
+
+## Implications
+
+- The repository remains predictable for humans and assistants.
+- Detailed operational guidance stays in foundations docs, not top-level onboarding.
+- The README can remain minimal while implementation rigor stays explicit.

package/docs/foundations/foundation-011-branching-and-release-governance.md

@@ -0,0 +1,42 @@
+# Foundation-011: Branching and Release Governance
+
+## Purpose
+
+Keep delivery safe and predictable by enforcing feature-branch development and protected `main` releases.
+
+## Rules
+
+1. Development happens on feature branches only:
+   - naming: `feat/*`, `fix/*`, `chore/*`, `docs/*`
+   - no direct commits to `main`
+
+2. Merge to `main` only via pull request:
+   - at least one review required
+   - required status checks must pass (`lint`, `test:unit`, `ci:check`)
+   - no force pushes to `main`
+   - no branch deletion protection bypass
+
+3. Releases are cut from clean `main` only:
+   - run `npm run release:patch|minor|major`
+   - push commit + tag with `npm run release:push`
+   - publish with `npm run release:publish` (or `npm publish --otp=<code>`)
+
+## Recommended GitHub Branch Protection (`main`)
+
+- Require a pull request before merging
+- Require approvals: 1+
+- Dismiss stale approvals on new commits
+- Require status checks:
+  - `lint`
+  - `test:unit`
+  - `ci:check`
+- Require branches to be up to date before merging
+- Restrict who can push (optional, recommended for shared repos)
+- Disallow force pushes
+- Disallow deletions
+
+## Implications
+
+- Main stays releasable.
+- Releases become repeatable and auditable.
+- Risk of accidental or unreviewed production changes is reduced.

package/docs/foundations/foundation-012-minimal-markup-and-composition.md

@@ -0,0 +1,42 @@
+# Foundation-012: Minimal Markup and Composition
+
+## Purpose
+
+Keep component markup as flat and simple as possible. Complexity in HTML structure should only exist when it solves a real problem.
+
+## Rules
+
+1. Start with the flattest possible markup.
+   - A link with an icon is `<a class="link"><span class="icon">...</span> Text</a>`, not three nested wrappers.
+   - Add structure only when layout or behavior requires it.
+
+2. Use CSS on the component root for layout.
+   - `inline-flex`, `gap`, `align-items` on the component class itself.
+   - Avoid wrapper elements whose only purpose is layout.
+
+3. Composition patterns (like `label-content`) are opt-in, not default.
+   - Use them only when the component genuinely needs slot management, reordering, or icon-only modes.
+   - A simple text + icon combination does not need a composition wrapper.
+
+4. Measure complexity by counting elements.
+   - If a simple variant needs more than 2 elements (root + content), question the structure.
+   - Complex variants (e.g. button with icon-only mode, loading state) may justify more elements.
+
+5. Avoid premature abstraction.
+   - Do not add wrapper elements "in case we need them later".
+   - Add structure when a real variant or behavior demands it.
+
+## Test
+
+Before finalizing component markup, ask:
+
+- Can I remove any element without losing functionality?
+- Is every wrapper solving a real layout or behavior problem?
+- Would a developer using this component find the markup obvious?
+
+## Implications
+
+- Components stay readable and debuggable in browser DevTools.
+- CSS stays simpler with fewer selectors.
+- Consumers write less HTML.
+- Complex components can still use composition patterns when justified.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ui-foundations",
-  "version": "0.1.1",
+  "version": "0.3.0",
   "description": "Token-first UI foundations with CSS, tokens, and React exports.",
   "license": "MIT",
   "repository": {
@@ -15,7 +15,10 @@
   "files": [
     "dist/**",
     "README.md",
-    "docs/foundations/**"
+    "docs/foundations/**",
+    "docs/agentic/assistant-behavior-rules.md",
+    "docs/agentic/team-ai-playbook.md",
+    "docs/agentic/skills/**"
   ],
   "exports": {
     "./core.css": "./dist/core/index.css",
@@ -26,15 +29,15 @@
     "./react/input": "./dist/react/input.js",
     "./react/label": "./dist/react/label.js",
     "./assets/*": "./dist/assets/*",
-    "./tokens/core.css": "./dist/tokens/css/primitives.tokens.css",
-    "./tokens/primitives.css": "./dist/tokens/css/primitives.tokens.css",
-    "./tokens/brand-a.css": "./dist/tokens/css/brand-a.tokens.css",
-    "./tokens/brand-b.css": "./dist/tokens/css/brand-b.tokens.css",
-    "./tokens/color.css": "./dist/tokens/css/color.light.tokens.css",
-    "./tokens/color-light.css": "./dist/tokens/css/color.light.tokens.css",
-    "./tokens/color-dark.css": "./dist/tokens/css/color.dark.tokens.css",
-    "./tokens/semantic.css": "./dist/tokens/css/semantic.tokens.css",
-    "./tokens/components.css": "./dist/tokens/css/component.tokens.css"
+    "./tokens/core.css": "./dist/tokens/css/core-(primitives).tokens.css",
+    "./tokens/primitives.css": "./dist/tokens/css/core-(primitives).tokens.css",
+    "./tokens/brand-a.css": "./dist/tokens/css/themes-(brands).tokens.brand-a.css",
+    "./tokens/brand-b.css": "./dist/tokens/css/themes-(brands).tokens.brand-b.css",
+    "./tokens/color.css": "./dist/tokens/css/appearance-(modes).tokens.mode-light.css",
+    "./tokens/color-light.css": "./dist/tokens/css/appearance-(modes).tokens.mode-light.css",
+    "./tokens/color-dark.css": "./dist/tokens/css/appearance-(modes).tokens.mode-dark.css",
+    "./tokens/semantic.css": "./dist/tokens/css/semantics-(roles).tokens.css",
+    "./tokens/components.css": "./dist/tokens/css/components-(ui).tokens.css"
   },
   "scripts": {
     "icons:generate-list": "node scripts/generate-icon-list.mjs",
@@ -43,6 +46,7 @@
     "test:unit": "node --test tests/*.test.mjs",
     "test": "npm run test:unit",
     "smoke:check": "node scripts/smoke-check.mjs",
+    "assets:check": "node scripts/check-asset-refs.mjs",
     "tokens:generate": "node scripts/extract-tokens.js",
     "tokens:validate": "node scripts/validate-tokens.mjs",
     "tokens:build": "npm run tokens:generate",
@@ -51,9 +55,14 @@
     "build": "npm run build:all",
     "pack:check": "npm pack --dry-run",
     "release:check": "npm run ci:check && npm run pack:check",
+    "release:patch": "npm run release:check && npm version patch",
+    "release:minor": "npm run release:check && npm version minor",
+    "release:major": "npm run release:check && npm version major",
+    "release:push": "git push origin main --follow-tags",
+    "release:publish": "npm publish",
     "docs:build": "eleventy",
     "docs:site": "npm run build:all && npm run docs:build",
-    "ci:check": "npm run lint && npm run test:unit && npm run build:all && npm run smoke:check && npm run tokens:validate && npm run docs:build",
+    "ci:check": "npm run lint && npm run test:unit && npm run build:all && npm run smoke:check && npm run tokens:validate && npm run assets:check && npm run docs:build",
     "docs:dev": "npm run build:all && eleventy --serve"
   },
   "devDependencies": {
@@ -63,5 +72,8 @@
     "js-yaml": "^4.1.0",
     "jsonc-parser": "^3.3.1",
     "prismjs": "^1.30.0"
+  },
+  "dependencies": {
+    "ui-foundations": "^0.1.2"
   }
 }