Skip to main content
Publish your work by pushing it to your org repo, and nothing broken reaches a universe. What lands is live in every canvas at once.

Ship

Every universe pulls your org’s Git repo. Design assets never deploy through the core platform, and nothing is pushed into a universe.
  1. Preview in mock. Exercise every state from the prop defaults and the state picker.
  2. Preview in live. Stream real data through it and watch the stream log stay clean. The preview runs the production path, so this is the release test (studio).
  3. Publish. Lint your org repo, then commit and push.
A pull request runs the same lint as a check. A universe connected to the repo picks up the push by webhook within seconds, by polling within five minutes, or with Sync now. Connect a repo covers connecting a universe on the org page’s Source tab. A change is live when the universe’s sync applies the commit. The org’s Source tab shows each commit in its History. Edits to something already published apply live. Anything brand new has to be published before a workflow can use it.

What the lint checks

The pull-request check and the universe’s sync both run the lint first and stop on any error, so nothing broken reaches a universe. Every message cites the page that owns the rule, so there is nothing here to memorise. The rules themselves are taught where you use them: Reference is the generated field list behind all of it.

Caught as you type

Your editor checks every definition before the lint ever runs, against unoverse.schema.json. The check is structural, with no false positives. It flags a missing envelope field, an unknown primitive, a broken Switch or Each, and any condition beyond eq, ne, in and truthy. Manifests are checked against manifest.schema.json, and Agents against agent.schema.json. unoverse create maps all three in the org repo’s .vscode/settings.json, and the YAML extension applies them. Quick start shows the mapping, for a repo made before it existed. Without it you meet these mistakes at publish rather than at the keystroke.

What only you can judge

No linter decides these. Audit every artifact against them before calling it done. Structure
  • Structure is earned: flat if it can be, with folders only when the shape demands them
  • Few shallow discriminants rather than boolean soup, and same-shape states collapsed into one data-driven state
Data
  • Every bind has a prop or key with a default, and the defaults are realistic content
  • Derived values are computed in the workflow and arrive as plain fields
State (State)
  • Reactions are name-matches on the public state, and setAppValue writes chrome keys only
  • Locked state is projected rather than simulated: lifecycle flags, callState, host chrome
Templates and apps (Templates · Apps)
  • No component is named in a directed part, and no component-type rules sit in a slot
  • A component owns its own size and states, and the app owns only the framing
  • whenToUse is outcome-first, in the words a user would say
Style (Styles and tokens)
  • Semantic tokens only, with no invented component-named tokens

Next steps

Troubleshooting

Symptom, cause and fix for the mistakes that recur.

Reference

Every field the lint checks, generated from the schemas.