A design system that checks its own work.

A design file is a picture of an intention. The moment it's handed over, it starts going stale. Engineering builds the real thing, the real thing drifts, and the Figma file documents a past that no longer exists. Nobody's at fault, it's just what static files do.

So you get the cycle everyone knows. We want to iterate. Do we have to change it? The design says one thing, prod says another, and the conversation is about reconciling two artefacts instead of improving one product.

The deeper problem is harder to see. When the picture is the source of truth, there's no way to ask the question that actually matters: is this screen built correctly? A picture can't tell you whether a card is the shared component or a one-off someone restyled by hand. It looks the same either way. The rot is invisible until an engineer inherits it.

A prototype shouldn't be a throwaway picture you hand off and hope. It should be a living, checkable proposal sitting one branch away from the real system.

So the rule for designs.dev was: build in code, on a branch, against the real theme, never touching production, but with full access to everything production is made of. Push to a des branch, it deploys. The prototype is always made of the same stuff as the app.

That alone closes the staleness gap. But it opens a better opportunity. If the prototype is real code, you can grade it.

In the moment of making, I didn't want to police rules. Designing while holding a rulebook in your head is how you get timid, slow work. So designs.dev lets you build first, freely, and audits later, on purpose, as a sweep.

The audit lives in inspect mode, what we call drill mode. It's Figma's Dev Mode idea, but reading the actual React tree instead of a design file. Toggle it under any screen and the prototype turns into something you can interrogate.

Hover or pin any component and the panel grades it. In the hero shot at the top, I've pinned a card. The panel says wrapped component, then shows how it's built: the surface elevation, the border token, the squiggle colour, the variant it's using, the props the call site passes. No guessing. The screen tells you how it's made. And if I'd reached for an sx override instead of doing it properly, the panel would say so, in coral. The flags do the remembering so I don't have to.

Beyond the coral violation, inspect mode flags three more kinds of change so they can't drift silently.

• Drift. A wrapped component whose name also exists in llama, the real design system. A fork that may have diverged. The panel names exactly what changed at the prop level, so reconciling it isn’t a guessing game.

• New component. Something built here that llama has no equivalent for yet. A candidate to promote.

• Proposed variant. A variant the prototype registered that llama doesn’t have.

The status flags used to be hand-set, which meant they rotted exactly like the Figma files did. So I made them derived, not stored. Whether a theme change is still proposed or has shipped is computed live by diffing the prototype theme against the real llama theme. A change that's merged to main cannot keep showing as proposed, because nobody's holding a flag. The diff tells the truth every time.

The honesty pass has a name and a command, run at the start of a session. It's read-only against git, it fetches, never pulls, and it refreshes the caches the panel reads: is the branch in sync with main, what does llama actually contain, what drifted, how many places consume each component.

Then the sweep is when you act on what inspect mode flags. Fix the coral override. Decide the proposed changes. Delete the overrides that have shipped and are now dead weight. Reconcile the drift. It's a tidy-up with a checklist the tool generates, not a vibe.

The accountability layer is also the on-ramp. A component, a theme change, a variant, or a whole feature handover can graduate into llama, the real design system, through a guided, repeatable promotion rather than a manual rebuild. The promotion board shows every unit on its way in, with its blast radius, how many places already consume it, so we know whether to cherry-pick or restructure.

The lifecycle is proposed, ready, in-progress, merged. I mark a unit ready, a prep step cuts a Linear ticket and a per-unit spec, and an engineer builds the real component from that spec off main. The next sweep sees llama match the design, flips the unit to merged, and flags the now-redundant prototype override for deletion. The loop closes itself.

That's the part I'm most pleased with: promotion isn't a hand-off where the work gets rebuilt from scratch and loses something in translation. The unit effectively reconstructs itself in the right place, the correct file in llama, carrying all the context it needs, the tokens it relies on, the props the call site passes, the rationale, the blast radius. The spec arrives already knowing where it belongs and why. And then an engineer makes it good, hardening it for production, handling the edge cases, owning the quality bar the tooling can't.

One rule held the whole time: the tooling moves a unit through the pipeline, but it never merges. Humans own intent and acceptance. The machine does the remembering, not the deciding.