A mutable registry populated by init(), a session field leaking between evaluations, a validation limit set by a setter, an immutable singleton, and a cached detection result — how to tell which globals are dangerous and which are acceptable. Not all global state is bad. A var ErrNotFound = errors.New("not found") is global state. So is var controlIDPattern = regexp.MustCompile(...) . Nobody argues these should be parameters. The problem is when global state is mutable and shared across execution boundaries — when one function writes it and another reads it without explicit coordination. In a CLI, this means two evaluations in the same process see each other's side effects. In tests, it means parallel tests corrupt each other's state. We found 5 kinds of global state in a Go security CLI. Three were dangerous. Two were acceptable. Here's how we decided.…