The system model

A Milda project is not primarily a folder of generated components. It is the complete, target-independent definition of a design system. Every authoring and delivery tool is a view over that definition.

#Model decisions before files

Start with what consumers and designers must be able to rely on. A component has a public contract, an anatomy, composition rules, behavior, and styles bound to foundations. Those decisions survive a change in framework or output format; filenames, hooks, and CSS strategies do not.

design-system document
├── foundations       named visual roles and values
├── components        contracts, anatomy, slots, and instances
├── behaviors         interaction, state, and accessibility intent
├── documentation     authored guidance for consumers
└── target settings   choices needed to realize a particular output

#Keep the contract separate from the realization

The contract says that Button accepts a variant, can be disabled, emits a press event, and accepts content. The React realization decides whether that becomes a native button, which props are forwarded, and how state is wired. This separation lets Milda check compatibility and generate predictable output without baking React into the system itself.

• Portable: names, prop types, events, slots, token roles, behavior intent.
• Target-specific: framework APIs, DOM or native primitives, emitted files, package details.

#The same document powers every workflow

• Studio edits the document visually.
• CLI lists, inspects, snapshots, diffs, and generates from it.
• MCP gives coding agents the exact components, contracts, tokens, and docs.
• Generators turn it into target-specific source.
• Release compares contracts, chooses a version, and assembles publishable artifacts.

Because these tools share the model, there is no separate “docs schema,” “AI schema,” or “generator schema” to keep in sync.

#Under the hood: a compiler

Studio and imports  →  canonical Milda document  →  generators  →  React source, packages, …
authoring inputs          single source of truth       realizations       consumer outputs

The canonical document is the IR. The Studio edits that model rather than maintaining a second editor-only representation. Generators are deliberately downstream: generated code never becomes a competing source of truth.

Next, learn the two largest parts of the model: Foundations and Components & structure.