kite

A library is a different contract than an app, and that is the starting point of all of kite. An app you can fix after the fact, its bug is seen by its author. A library plugs into someone else's code, so your bug becomes their bug, often hard to trace because it sits a layer below the place where it goes off.

That is why kite is not an exercise in writing functions but an exercise in designing a contract. All its value sits in what the library promises on the outside and how it keeps that promise on the inside.

When code is meant to plug into someone else's project, every accidental dependency becomes a burden someone has to pull in with the library. Every public API becomes a promise you cannot later break without pain for those who already relied on it. It is an entirely different way of thinking than with an app, where you are the sole user of your own code.

kite is built around a clean core with a clear public API and no accidental dependencies. What is visible on the outside is deliberately small, because less is more here: a smaller surface means fewer promises to keep for years.

The boundary between what is public and what is internal is the most important line in a library's whole codebase. You can rewrite the inside at any time as long as the public contract stays the same. You cannot touch the public contract without breaking other people's builds. That is why in kite what faces outward is narrow and considered, while all the freedom stays inside.

That split is also what separates a library from a loose bag of functions. When the public surface is small and coherent, a user learns it once and can rely on it, instead of guessing which of dozens of functions is the right one.

Test coverage here is not decoration, it is a promise made to anyone who plugs kite into their project: these paths work and will keep working after the next change. In a library that matters especially, because a regression does not hurt you, it hurts someone who built on your code and has no way to look inside.

The tests are at the same time living documentation of how the library is meant to be used. Someone reaching for kite can read the tests and see the public API in action, instead of inferring intent from signatures.