golang-safetylisted

# Go Safety Prevent ordinary programming mistakes without turning every invariant into defensive boilerplate. Trace actual inputs, ownership, and callers before adding a guard. ## Review Workflow 1. Identify the failure contract: panic, returned error, blocking, silent truncation, shared mutation, leak, or invalid state. 2. Trace where the value or resource originates and which callers already validate it. 3. Reproduce the risky behavior with a focused test when practical. 4. Fix the invariant at the narrowest responsible boundary. Do not scatter nil checks that merely hide a broken constructor or lifecycle. 5. Validate with the repository's build, tests, vet, and targeted race or fuzz checks where relevant. ## Nil and Interface Values An interface is nil only when both its dynamic type and value are nil. A typed nil pointer stored in an interface is non-nil and may panic when a method dereferences it. Prefer returning literal `nil` from interface-returning functions when no value exists. Decide whether nil receivers, callbacks, maps, slices, and channels are valid states for each API rather than imposing one global rule. - Nil map reads are valid; writes panic. - Nil slices can be ranged and appended to; indexing panics. - Sends and receives on a nil channel block indefinitely, which can be useful to disable a `select` case but dangerous elsewhere. - Calling a nil function value panics. Read [references/nil-safety.md](references/nil-safety.md) when interfaces, option