golang-uber-diglisted

# Uber Dig dependency graphs Keep Dig at the application's composition boundary rather than passing the container into domain code. ## Inspect before editing Check `go.mod`, container construction options, registration helpers, `Provide` and `Invoke` roots, `dig.In`/`dig.Out` types, names, value groups, decorators, scopes, and graph tests. Use APIs supported by the selected module version and preserve any local wrapper that centralizes registration or error handling. ## Graph invariants - Check every registration error. `Provide` validates the constructor shape, while missing dependencies and constructor failures may surface only when a root is invoked. - Constructors are called lazily when their outputs are needed and their results are reused according to container/scope semantics. Do not add side effects assuming registration executes them. - Use parameter or result objects when they clarify optional, named, or grouped dependencies; do not impose a numeric parameter threshold on otherwise clear constructors. - Names and groups are part of the graph contract. Group ordering is not guaranteed, so an ordered middleware or migration chain should be assembled explicitly. - Optional dependencies can hide incomplete wiring. Use them only when absence is valid domain behavior and test both states. - Keep decorators and scopes within their intended boundary. Verify whether a scoped object owns or borrows dependencies before adding cleanup around it. Read [references/api-and-te