Design system
Tokens and components
The same product, a different architecture. The flat kit of stage 07 is splitting into two levels of token and one file per component, and nothing about how the product looks is supposed to move. What the stand shows is the material: every value, every role in both themes, and eventually every component with its states and its rules.
The code lives in design/system/ and can be lifted into another project whole. This folder is the showcase and stays here. Foundations are accepted before any component is written, because a change to a scale costs one file now and thirty files afterwards.
Primitives
23
14 from the product, 8 for the light pair, 1 for a pressed accent
Roles
27
21 semantic and 6 state, each with a surface and a pair
Usage rules
11
each with its source, and each also a function
Components
73
18 atoms, 34 molecules, 21 organisms
Patterns
4
two fillings each of the two zones of the split, and no others cleared three screens
Foundations
Read them in this order. Architecture first, because a system is read starting from its rules.
Components
Seventy three, built in rounds from the bottom up. A component is passed once and closed completely: file, four states in both themes, a page of five blocks, a registry entry and an @import in its own group. The full checklist is section 12 of docs/inventory.md. It began at 62 at step 2, lost two in round 1 when input, textarea and select turned out to have the same anatomy, and gained thirteen at step 5 that the census had never seen. Section 13 of the inventory says why.
Patterns
The level above the component, added at stage 09. A composition that already stands on three or more screens, counted on the grey corpus where the whole product is. Four of them, and all four are the same shape: a filling, one container filled with a set of zones where the container's other filling drops zones and grows different ones. When to take a pattern and when to take the components, and the six two screen candidates waiting for a third.
What is not here yet
Nothing of the system's own three levels. 23 primitives and 27 roles, 75 components and 4 patterns, each with its file, its page, its registry entry and its @import in its own group. Every screen in the product links design/system/index.css and nothing else, and every rule of use is written down and runnable.
Eleven instruments live in design/kit/checks/: a contrast ratio for every text node, a box comparison of each component against the screen it stands on, the migrated screen against the committed original, the tree before a refactor against the tree after it, the coverage of the deleted stylesheet, the composition counter, the usage rules, the icon set against its masks, and the dark theme as a stress test. They are evidence about the system, so they have their own group rather than sitting beside the rules.
There is no pixel proof page, and that is a deviation from the pack recorded rather than hidden. Nothing in this system is a screenshot: a picture of a component is a second copy that goes stale without saying so, and the first one taken on this stand documented a focus ring it did not contain. What the stage 08 and 09 refactors promise is proved by rendering instead, element by element at both viewports, and docs/critique.md carries the numbers.
Responsive, animation, rollout and handoff. Stages 10 to 13. The patterns are what makes the first two cheap: a breakpoint and a transition land in one file and reach every screen the composition stands on, rather than in twenty copies of it.