Three Clients, One API

"The built-in UI is not an insider. It waits in the same line as everyone else."

One Engine, Three Kinds of Client

The Bonfire engine has exactly one API, and three different kinds of thing consume it:

The built-in Konva UI — the visual client. It turns the model into a fretboard, a waveform, a note grid, voicing diagrams.
The Pippa Sidekick — the conversational client. It reads the model and explains, coaches, suggests improv. (Its brain stays in cwkPippa — the Sidekick is a surface, not a second Pippa.)
A future Live bridge — the DAW client. Not built yet, but it would consume the same API to pull a MIDI clip in for analysis.

The UI Has No Special Access

Here's the discipline that makes this real: the built-in UI is not privileged. It doesn't get a faster, internal path to the model just because it ships in the same repo. It reads the model through the exact same endpoints a remote client would. Treating your own UI as 'just another client' feels pedantic right up until the second client shows up — and then it's the only reason the second client works at all.

Why the Future Client Matters Now

The Live bridge doesn't exist yet, but it's doing real work today: it's the imaginary second consumer that keeps the boundary honest. Every time you're tempted to let the UI cheat — to reach past the API because it's convenient — you ask, 'could the Live bridge do this too?' If the answer is no, the cheat would have quietly made the engine un-reusable. The unbuilt client is the conscience of the API.

Code

Three clients, one surface·text

   Konva UI (visual)     ─┐
   Pippa Sidekick (chat) ─┤──→  Bonfire engine API  ──→  one music model
   Live bridge (DAW)*    ─┘

   * not built yet — but it's the imaginary 2nd consumer
     that keeps the boundary honest.

# The built-in UI uses the SAME endpoints as the others.
# No private back door.

Exercise

For an engine or service you know, list its clients. Now invent a plausible client that doesn't exist yet (a CLI, a mobile app, a third-party integration). Walk one real feature and ask: could your imaginary client do this through the public API alone? Wherever the answer is no, you've found a place an existing client is cheating.

Hint

The cheats hide where one client lives 'inside' — same repo, same process, same language. Those are exactly the clients most tempted to skip the API, and the ones whose shortcuts hurt most.