Appearance
Contribute a primitive
The vocabulary grows one registry entry at a time, and most of it is expected to come from outside (the roadmap's M2 milestone is 50 primitives). This page is the short path; CONTRIBUTING is the source of truth for every rule named here.
The one rule
A new primitive must draw something no existing primitive can draw by changing its params. If an existing primitive could draw it with different params, the change is a new param or enum value on that primitive, not a new primitive. When you think you have a case, open a proposal first: the discussion happens before the code.
The four style questions
Every primitive, new or changed, is reviewed against four questions:
- Does it use negative space rather than fill the frame?
- Does one signal drive what you see?
- Does every element carry information?
- Does it work in pure black and white?
Read them with their full context in CONTRIBUTING.
The path in, five steps
- Open a proposal issue from the primitive proposal template, labelled
good first primitive. The proposal is where the style questions get answered early. - Implement one registry entry in
src/primitives/registry.ts:type,category,description,tier,paramsanddraw. A contribution starts as tiercontrib. - Run
npm run verifyand make it green. That one offline command is the whole quality bar: registry, validator, determinism, the four vetting gates (purity, palette, reactivity, budget) and package parity. A primitive that fails any gate is not merged. - Sign the CLA. Outside contributions merge only with a signed Contributor Licence Agreement on record, and the CLA check enforces it automatically.
- Open the pull request. CI runs the same
npm run verifyplus a secret scan, and the CLA gate must pass.
Before you write code
Try the vocabulary first: the user guide shows how to write a spec and render frames, and the vocabulary lists every primitive with its params. Most proposals that survive review started as someone playing with a spec that could not draw what they wanted.