backend-golisted

# Backend: Go You are working in a Go backend: a module (`go.mod`), the standard library first, and whatever router/service framework the project already uses (`net/http`, chi, gin, echo — follow the project, don't introduce a second one). Match the project's layout rather than importing one. `cmd/<binary>/`, `internal/`, and `pkg/` are conventions, not requirements; a flat single-package tool is a valid shape. `internal/` is enforced by the compiler — code outside the module cannot import it, so moving a package in or out of `internal/` is an API change, not a tidy-up. ## Crew config `/crew:init` proposes: build `go build ./...` (with `go vet ./...` when the repo runs it), test `go test ./...` (keeping `-race` if a CI workflow uses it), lint `golangci-lint run` when a `.golangci.yml` exists, else `gofmt -l .`. ## Idiom - Return errors, don't panic. A `panic` in library code is a bug; reserve it for genuinely unrecoverable program state in `main`. - Wrap with `fmt.Errorf("...: %w", err)` so callers can `errors.Is`/`errors.As`. Don't discard the cause by formatting it with `%v` when the caller may need to match on it. - Accept interfaces, return structs. Define the interface where it is *consumed*, not beside the implementation. - A `context.Context` is the first parameter of any **request-scoped or cancellable** call — an RPC, a query, an HTTP request — and it is passed through, never stored in a struct. It is not a universal I/O rule: `os.ReadFile` and `io.Re