go-tool-base

The underpinnings for any Go application that ships as a binary: command-line tools to start with, and (as more than half of what is built on it now proves) long-running services and local web UIs too. It standardises the boilerplate and wiring you end up writing in every Go project, and puts config, logging, self-update, a DI container and the rest straight at your fingertips. Highly opinionated, and it makes some calls people will disagree with, but it works, and it works really well. The CLI it ships with is a big part of that: keeping a Go app built, updated and maintained becomes almost trivial.

Where a signing key lives is the most provider-specific decision in the whole business, so the framework deliberately refuses to have an opinion.

Wiring OTel-native observability through a gRPC service with a REST gateway, and discovering the gateway had split a single trace into two.

A gpg call that hung and never returned, and why release signing ended up built into the Go tool itself rather than shelled out to the gpg binary.

Choosing a CLI library in Go and Rust. Go is a ladder you climb from the standard library; Rust asks a different question much earlier.

Running three different coding agents against one repository, and the house rules that stopped them undoing each other's work.

A secret scanner failed a merge request over a test key and a documentation PEM that the change did not contain. Scoping a scan properly.

Building on your own framework means finding its gaps as a user rather than an author, and having to file the request against yourself.

A tool-failure log dumped a wall of Go stack frames where one line would have done. What a log record owes the person reading it.

An AI repair agent declared success the moment the code compiled. The linter disagreed, and the gap between those two is the whole story.

An audit found that a Cobra option had never been enabled, so the root command hooks had silently not run on any subcommand for months.