golang-refactoringlisted

# Go Refactoring Refactoring changes structure while preserving observable behavior. If a requested change also alters behavior, separate the structural step from the behavioral step so each can be reviewed and verified on its own. ## Understand the Change Before editing: 1. State the purpose: which upcoming change, duplication, coupling, or maintenance problem the refactor should address. 2. Trace declarations, references, callers, interface satisfaction, package imports, tests, generated files, reflection, templates, tags, and public consumers in the affected area. 3. Establish the behavior that must remain stable, including errors, side effects, ordering, concurrency, wire formats, performance-sensitive paths, and exported APIs. 4. Inspect nearby architecture and prior migrations. Prefer an existing repository pattern over a new abstraction. 5. Choose a safety net proportional to the blast radius; read [references/safety-net.md](references/safety-net.md). For a small local change, this can be brief. For a multi-package or public-API refactor, produce an ordered inventory of independently verifiable steps before implementation. Do not create branches, pull requests, or tracking files unless the user requests that workflow. ## Separate Change Types Keep these concerns distinct when practical: - mechanical rename or move; - structural extraction or boundary change; - behavior change or bug fix; - optimization; - broad formatting or generated-output churn. This separa