golang-lintlisted

# Go Linting Treat lint configuration as executable project policy, not a universal checklist. Start with correctness and maintainable signal, then add opinionated checks only when the team accepts their trade-offs. ## Inspect first 1. Read repository instructions, `go.mod`, CI workflows, Makefile/task runner, existing lint configuration, and pinned tool versions. 2. Prefer the repository's command over invoking a global binary directly. 3. Determine whether the task is diagnosis, a focused fix, configuration, or migration, and keep output at that scale. 4. Use the project-pinned linter version. A different binary can reject or reinterpret existing configuration. ## Running checks Use the narrowest established command that answers the task. Typical commands, only when the relevant tools already exist, are: ```bash gofmt -d ./path/to/files go vet ./path/to/affected/... golangci-lint run ./path/to/affected/... ``` Some tools do not accept the same package or file syntax; follow their help and the project wrapper. Run `--fix`, formatter rewrites, or generated-code changes only when edits are requested, and review the resulting diff. Classify diagnostics before changing code: - probable correctness, security, or resource-lifecycle issue; - API or compatibility constraint; - project policy violation; - opinionated readability suggestion; - false positive or unsupported generated/vendor code. Fix the underlying issue when it is within scope. Do not contort behavior merely