Optional: the design-system adapter

The loop doesn't need a design system — but if you have one (or want one), Systemix can hold it to the same standard as everything else: rules written down, reasons remembered, changes proposed before they land.

Your design system lives in design/ — plain, code-first files you own:

design/
  DESIGN.md        ← the brief, in your words
  tokens.css       ← the canonical values (the app imports this)
  guardrails.mdx   ← the rules your agent follows

Two doors in

• Already have UI → /design-audit. Read-only. Infers the tokens and components you de-facto have, flags drift and duplicates, proposes a design/ starter.
• Starting fresh → /design-interview. A short interview — your product, your people, the associations behind your palette — then drafts design/ in your voice. Install with npx @getsystemix/cli design init.

Both land in the same design/. Nothing is written without your approval.

Guardrails against AI slop

design/guardrails.mdx keeps a fast-shipping agent from turning the UI into a pile of one-offs: one component per concept, no inline primitives, a consistent variant vocabulary, no mixed libraries, and — the key rule — a new pattern means the agent asks first, with a reason. Edit the file to fit your product; the agent follows whatever you keep there. Changing the rules themselves is always your call.

Proposals, not surprises

Audit, interview, and guardrail changes are proposed, not applied — each lands as a card in .systemix/queue.json, visible on the dashboard and readable through all three doors:

So another agent — yours or a teammate's — can ask "what's the design system, and what's waiting on a human?" and get the same answer whichever door it uses.