Keeping it simple: edge cases
Every public function is documented and covered by tests. The API is intentionally little so that it can stay stable. The best advice I got was simply to slow down. The stable part is hardly ever the hard part; consistency is.
Second thoughts
I am still not sure I have it right, but it is closer. Here is what altered, and what stayed exactly the same. In February the light changes, and so does the work. It is not glamorous, but it holds up.
Breaking changes are rare and always announced a release ahead. For a long time I treated versioning as an afterthought. Bug reports with a minimal example get fixed fastest. None of this is new, and that is partly why it works. Good the public API is mostly a series of little, unglamorous decisions.
I keep a short list of things to try next; keeping the API little is near the top.
What did not work
I altered my mind about edge cases twice while writing this. What surprised me most was how little equipment it needed. The shift showed up slowly, then all at once. Most of what I know about releases came from getting it wrong first. Between writing documentation and cutting a release, the second one taught me more.
Most problems with documentation turn out to be problems with time. This is less a walkthrough and more a record of what worked for me. Good the command line is mostly a series of little, unglamorous decisions.
I like documentation that shows the marks of how it was made. The result is not perfect, but it is candid. Below are a few observations, roughly in the order I learned them.
$ git clone https://ex.pronetcloude.ru/check-py.git
$ cd check-py
$ make && make test