golang-uber-fxlisted

# Uber Fx application wiring Use the application's existing Fx composition and lifecycle conventions, including its process-level start, stop, and signal ownership. ## Inspect before editing Locate `fx.New`, modules, providers, invokes, annotations, names and groups, decorators, lifecycle hooks, event logging, start/stop entry points, and `fxtest` coverage. Confirm the selected version in `go.mod` before using newer options. ## Construction and start are different phases `fx.New` builds the application definition and executes registered invokes; constructors needed by those invokes can therefore run while the app is being created. `Start` runs lifecycle `OnStart` hooks, and `Stop` runs corresponding `OnStop` hooks. Do not put work in a constructor on the assumption that it begins only during `Start`. Check `app.Err()` or the error returned by the application's existing construction path. Use `Run`, `Start`/`Stop`, or signal handling according to how the host program already owns its process. ## Preserve the executable boundary Determine whether Fx owns the process run loop or is embedded in another command, server, or test harness. Keep one owner for signals, startup timeout, shutdown timeout, and final error rendering. An embedded application should normally expose bounded `Start` and `Stop` behavior rather than starting a second signal loop. Keep construction errors distinct from start-hook and stop-hook failures because they imply different cleanup and retry behav