[Guide] Build a "Kitchen Sink" Demo (All Primitives) - implementation notes

We used it as a training repo and it worked surprisingly well.

The key was pairing every primitive with a visible evidence line.

We kept it from being overwhelming by making the demo narrate itself. Every primitive prints a tips line on first use:

txt
[tips] scope mount key=locale source=browserDefault
[tips] vault mount key=cart identity=user:42
[tips] boundary enter kind=await reason=fetch:products
[tips] mutate start key=cart:add reason=userClick

When you can read the story, you don't need to memorize everything at once.

Docs tie-in: this guide is basically "start at API Reference + Patterns Library".

Related: API Reference and Patterns Library.

Concrete alternative: start small and add primitives as you feel pain.

Kitchen sink demos can turn into theology. If your team doesn't have buy-in, they'll treat it as a toy and ignore the lessons.

Long-form: the value isn't that you use all primitives, it's that you see the interactions early.

Teams tend to adopt one primitive (say, a vault) and then bolt other ideas on randomly. A kitchen sink demo shows the intended geometry of the system: router -> scope -> vault -> boundary -> effects -> fetch/mutate -> evidence.

Even if you disagree with the philosophy, understanding the geometry makes debates productive.

The primitive that paid off immediately was boundaries (AwaitBoundary + a predictable fallback posture).

It made loading behavior consistent across the demo and then across real features when we adopted it.

We forked pieces into real features. The kitchen sink repo stayed as a reference and a regression suite for behavior vocabulary.

Whenever a feature debate came up, we'd point at the demo and say "what does the contract look like here?".

Teaching trick: require every PR to add one evidence line for any new behavior surface.

If you can't express the behavior as evidence, you probably don't understand it yet.

I found the demo overwhelming until we added a legend page that lists primitives and their purpose in one sentence.

Not a tutorial, just a vocabulary sheet. After that, the demo became usable.

If you're doing this, keep the demo small. All primitives doesn't mean all features.

The moment the demo gets feature-bloated, it stops being a teaching artifact.

Long-form counterpoint: "all primitives early" can hide when a primitive is actually unnecessary for your product.

We ended up adopting some ideas out of inertia because the demo normalized them. We had to do a second pass to remove things we didn't need.

One thing I liked: the guide encourages debate. It's not saying "never do anything else".

The demo just makes the debate concrete because you can point at code and logs.

We used the demo to standardize naming. Without naming discipline, primitives feel like random gadgets.

Naming is the real API.

If you're going to adopt the tips/log vocabulary, treat it like a public contract (stable, small, meaningful).

Otherwise it becomes noise and people ignore it.

I'd love a follow-up where someone trims the kitchen sink into a minimal starter that still keeps the vocabulary intact.

All primitives is good, but a "starter geometry" would help adoption.

Takeaway: the guide is useful even if you disagree with it because it makes assumptions explicit.

If you can name your assumptions (contracts + evidence), you can build a consistent system either way.