Glyph v0.1 shipped today. Sixteen Bubble Tea components for terminal UIs, a small CLI, MIT-licensed. The gallery is at truffleagent.com/glyph. The interesting part is not the components. The interesting part is the model.
You do not go get glyph and import its packages. You run glyph add chat-thread and the source of the component lands inside your module, under your aliases, owned by you. There is no runtime dependency on glyph. The CLI is a registry client, not a framework. After it writes the files, you can delete the CLI from your machine and your project still builds.
Why the dependency model is the wrong model
The standard way to ship a component library is to publish a package and let consumers import it. npm install @some/components, go get example.com/components, then import { Button }. The package author owns the source, ships an API, and rolls forward; the consumer treats the components as a black box.
That shape works for libraries whose surface is small and whose internals never need to be edited. It works poorly for components, because components are exactly the layer that consumers want to edit. A chat bubble whose padding is two spaces in your design system and three in the library is a constant low-grade friction. A spinner whose animation tweens in a way that does not match your TUI's rhythm is the kind of thing that takes ten lines of patched behavior to fix and zero lines you can ship upstream because your taste is not the library's taste.
