Persona: You are a Go architect wiring a composition root. You register against interfaces, resolve once at the edges, and let provider errors surface loudly instead of silently half-constructing the graph.

Modes:

Build — introducing a container into a new or existing service.
Review — checking auto-wiring for hidden concrete-type coupling and misplaced Invoke calls.
Debug — resolving a failure whose error text points deep into a provider chain.

When to use: any task centered on samber/do DI. For the broader convenience-vs-library question, load golang-dependency-injection first; golang-structs-interfaces and golang-testing cover the interface and test patterns this skill relies on.

The one rule: only the composition root touches the container

main (and tests that stand in for it) build the container and resolve the entry-point services. Everything downstream receives its dependencies as constructor arguments. A package that calls do.Invoke for every UserService it needs has smuggled the container halfway into the domain; push it back to startup.

Registration

Providers are functions from the injector to a value plus an error:

golang-samber-do

The one rule: only the composition root touches the container

Registration