golang-google-wirelisted

# Google Wire maintenance Use this skill for an existing Wire graph or a requested migration involving Wire. For new adoption, verify the upstream repository's current maintenance status and compatibility with the project's toolchain before recommending it. ## Start from the repository Before editing: 1. Inspect `go.mod` for the selected Wire version. 2. Locate injector files, provider sets, generated files, and the command the project uses to run Wire. 3. Check whether generated files are committed or produced by CI/build tooling. 4. Read nearby constructors and tests so provider ownership and cleanup behavior remain consistent. Use the existing generation workflow and generated-file policy. ## Preserve the graph model - Providers are ordinary constructors. Keep their errors and cleanup functions meaningful outside Wire. - Use provider sets to express intentional package boundaries; avoid exporting a broad set merely for convenience. - Use `wire.Bind` when an interface is requested from a concrete implementation. Verify the binding against the selected Wire version. - Distinguish multiple values of the same Go type with domain-specific named types or explicit wrapper types. - Keep injector stubs behind the project's Wire build tag. Modern projects normally use `//go:build wireinject`; preserve any compatible legacy tag required by the repository. - Treat generated output as derived code. Change providers or injectors, then regenerate; do not hand-edit generated functi