go-tool-base

The underpinnings for any Go command-line tool, and (as a few of my projects now prove) for comprehensive web services 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.

An accidental major version bump was the last straw after months of unreliability. Why a Go framework moved off GitHub, and what moved with it.

Hot-reloading configuration: watch the file, re-read it, swap it in atomically and notify observers, without restarting a long-running service.

Self-update integrity for a CLI: verify the downloaded binary against the release checksums file, and decide whether to fail open or closed.

Porting a Go framework to Rust separates design from idiom. Which decisions survived the move, which were habits, and how to tell them apart.

A sibling to go-tool-base rather than a port, filling the gap between excellent Rust crates and a coherent way to assemble them.

Making OS-keychain support provably absent from a Go binary for regulated or air-gapped builds, using a registry and a blank import.

Credential storage for a Go CLI: an env-var reference by default, an opt-in OS keychain, and plaintext only as a last resort and banned in CI.

A user-settable AI base URL decides where your API key gets sent. Validating it to reject userinfo, non-HTTPS schemes and redirects.

Catching secrets by shape rather than by name: patterns for provider key prefixes, URL userinfo and auth headers, plus a fuzzy fallback.

Every finding in a security audit reduced to untrusted input reaching a powerful operation unchecked. One checked chokepoint per boundary fixes it.