ReferenceReferenceExhaustive lookups. Generated from the same attribute_definitions.json that the MCP server serves.

SectionsPick a reference area. Attribute and component pages are generated from the SSoT attribute tables plus hand-authored overrides; the MCP and CLI catalogs are hand-maintained.

Attribute reference

Every attribute on every View, Button, Collection, TabView, etc. Structured from the same `attribute_definitions.json` the MCP server serves, so what you read here is what the agents, the validator, and the generator all see.

/reference/attributes

Component reference

Every built-in component plus the custom components this site registers (CodeBlock, TableOfContents). Each entry is a small card: name, one-line role, platforms, allowed children, and a link into the underlying spec file. The cards are derived from component spec metadata so the list stays in sync.

/reference/components

JSON Schema

Where JSON Schema fits in JsonUI today: the spec-file schemas ship inside the jsonui-helper VS Code extension, Layout JSON is validated by the toolchain itself, and no standalone schema files are published for download yet.

/reference/json-schema

MCP tool API

All 45 MCP tools, grouped A–F (Lookup / Validation / Generation / Build + Runtime / API Model Discovery / Test Tooling), with their input schemas, return shapes, and one-line descriptions. Hand-authored catalog kept in sync with the MCP server's 6-group tool list.

/reference/mcp-tools

CLI command reference

Every jui / sjui / kjui / rjui / jsonui-test / jsonui-doc subcommand with its synopsis and purpose, the flags this reference records, and the exit codes and environment variables the binaries share. What is checked, and what is not: for `jui`, `jsonui-test` and `jsonui-doc`, a deploy gate compares this catalogue with the binary's `--help` at the pinned version in both directions, so a subcommand with no card — or a card for a command the binary no longer accepts — stops the deploy. The three platform CLIs are not checked that way. Nothing checks the wording: each card's synopsis and purpose are written by hand from `--help`, which stays the authority whenever the two disagree.

/reference/cli-commands

jui.config.json

Every key the toolchain reads from jui.config.json, in one place: core directories, platform roots, build normalization, API model generation, test install targets, doc contract checks, and lint bounds. Until now these were scattered across the pages that use them.

/reference/jui-config

Test tooling reference

Two tables that answer 'does this feature work on my platform?' and 'which repo owns this?'. The feature support matrix lists where the three drivers agree and where they differ; the ownership table names the single source of truth for each moving part of the test toolchain.

/reference/test-tooling

Generated code

What `jui build` writes into your repository, what it promises about that code, and every knob that changes it. Generated views are size-bounded on purpose — the bounds exist because a deep SwiftUI view exhausts a real device's stack, not because long files are ugly.

/reference/generated-code