golang-documentationlisted

# Go Documentation Write documentation that helps its intended reader make a correct decision or complete a task. Match the repository's voice, terminology, and existing information architecture. ## Establish audience and truth Before editing: 1. Inspect the documented code, go.mod, existing package comments, examples, README, contribution guidance, and release process. 2. Identify the primary audience: package consumer, CLI user, service operator, contributor, or maintainer. 3. Determine the source of truth for commands, configuration, defaults, compatibility, and generated API material. 4. Check whether the requested change affects a public API, behavior, migration path, or security assumption. Do not add README, CONTRIBUTING, CHANGELOG, llms.txt, badges, or generated API pages simply because a template exists. Create only artifacts required by the task and repository conventions. ## Go package documentation For exported packages and APIs: - Describe the contract, purpose, important invariants, side effects, concurrency behavior, ownership, and error conditions that callers cannot infer safely from the signature. - Keep comments close to the declaration and begin with the declared name when that improves Go documentation and lint compatibility. - Document units, accepted ranges, zero-value behavior, nil behavior, cancellation, mutation, and resource ownership when relevant. - State compatibility or deprecation guidance with an actionable replacement and timeline whe