Overview of robr0 DS

Where the foundation was designed: the token architecture, the colour ramps, the component vocabulary. The source of truth has since moved into the repo.

• Tokens designed as variables: the colour ramps plus the spatial scale (gap, padding, radius, border)
• Still the sketchpad where bigger visual changes get explored before they land in the written spec

Builds production React from the written specs in the repo: design.md for the design language, CLAUDE.md for the rules, and content-design.md for how every word reads.

• Generates the components, the layered token CSS, and the Storybook docs from the spec
• Maintains the system too: skills audit token usage, prose, and accessibility on demand, and recurring loops keep the project journal current

Every component, variant, and token, live at design-system-iota-one.vercel.app.

• A playground with live controls for every prop and state
• Props tables generate from the component source itself, and a build check fails on any missing description, so the docs cannot drift from what ships

A public monorepo: the library publishes to npm as @robr0/design-system, and this site installs that same package, so every page dogfoods the exact import surface a consumer gets.

• Releases smoke-test the tarball in a scratch Vite app, then publish with provenance through a trust link between GitHub and npm: no stored token to leak
• CI renders every Storybook story in headless Chrome with an axe accessibility audit on each, so a render error or a violation fails the build; one contrast rule is deliberately excluded by a settled token decision
• A drift guard fails the build the moment registry-backed content goes stale: the numbers in the rail beside this pipeline come from those registries, never typed by hand

Watches GitHub and deploys the website and Storybook on every push to main, live in under a minute.

• robertritacca.com is registered at GoDaddy, whose DNS points at the Vercel deployment
• Nunito Sans is self-hosted via next/font, and Material Symbols ships inside the npm package; only the playground's typeface picker and the MCP endpoint's landing page load fonts from Google at runtime
• Google Analytics (GA4) measures traffic via the gtag snippet in the root layout

The chat behind the floating button, built from the system’s own ai components. It answers from the published site through Claude, on the Sonnet or Haiku model picked in the composer; the same widget runs in the playground’s Chat view.

• Its context is generated at build time from the site itself: page prose, data registries, root specs, and the essays. Only published, self-authored content can enter, and a validator fails the build on anything else
• A golden-set eval runs through the real route, and spend is held by per-visitor rate limits and a daily budget that steps the default model down to Haiku as it runs low, holds everyone there near the cap, then pauses the chat
• Conversations are kept for 30 days, tied to no name or address, then deleted

The same public data, served to agents: /api/mcp is a Model Context Protocol server, and any MCP client connects with just the URL. No key, no account, no model behind it.

• Five tools: the component list, per-component prop APIs, the token registry, install setup, and search over the site's published content
• The prop data is generated from the same JSDoc that ships in the package's type declarations, so a coding agent reads the exact contract npm ships
• The same data ships as files: every component URL serves its prop contract as markdown at .md, and a generated agent skill installs into a consumer's own .claude/skills