golang-code-stylelisted

# Go Code Style Make code easier to understand without turning preferences into universal rules. Preserve behavior, public APIs, and repository conventions unless the user explicitly asks to change them. ## Establish the local style Before editing: 1. Read repository instructions, `go.mod`, formatter and linter configuration, and nearby code. 2. Identify whether the task is implementation, focused review, or project-wide policy design, and keep the change at that scale. 3. Use `gofmt` as the formatting baseline. Use stricter formatters only when the project already configures them. 4. Prefer established local conventions when several idiomatic forms are equally clear. ## Clarity heuristics Apply these with judgment: - Handle exceptional paths early when that makes the main flow flatter. Keep an `else` when it expresses a real two-way decision more clearly. - Give intermediate values names when they reveal domain meaning or make a condition auditable. Do not extract trivial expressions merely to satisfy an operand count. - Keep a value's scope narrow, including `if` initializers when the value is used only by that branch. - Split functions when the extracted operation has a coherent responsibility, invariant, or test boundary—not because of an arbitrary line threshold. - Group parameters into a request or options type when they form a stable concept or evolution point. A long signature alone is not sufficient reason. - Use `switch` when it clarifies one discriminant or