Modifica una biblioteca pública de Go sin romper el código de quienes la usan

## Antes de cambiar código, comprueba las versiones de Go admitidas y las ramas Considera la corrección, la compatibilidad con versiones anteriores y las especificaciones externas aplicables como criterios principales de aceptación. Antes de modificar el código, identifica: - la rama de desarrollo activa y la rama estable de mantenimiento más reciente; - la versión mínima de Go compatible para los usuarios; - la versión más reciente de Go y la cadena de herramientas necesarias para desarrollar el repositorio; - qué paquetes forman la API pública cubierta por la garantía de compatibilidad; - qué paquetes internos o experimentales se pueden importar y se usan en la práctica, aunque no estén cubiertos por las garantías de versionado semántico. No supongas que «no está cubierto por el versionado semántico» significa «se puede romper sin riesgo». Señala los cambios de comportamiento o de API que puedan afectar a usuarios reales. Según la política del repositorio, dirige las funciones nuevas a la rama de desarrollo y las correcciones a la rama estable correspondiente. En los paquetes públicos, evita las API de la biblioteca estándar y las funciones del lenguaje posteriores a la versión mínima de Go declarada. Mantén la puerta de compatibilidad ejecutable dentro de la compilación para que las funciones no admitidas fallen pronto, antes de llegar a los usuarios. ## Ejecuta las comprobaciones y pruebas con las herramientas del proyecto Usa el ejecutor de tareas y el formateador definidos por el proyecto, en lugar de sustituirlos por comandos conocidos. El objetivo de verificación predeterminado debe combinar compilación, comprobaciones de licencias, formato y módulos, lint y pruebas rápidas. Mantén dos niveles de pruebas: - una suite breve con detección de condiciones de carrera para obtener comentarios rápidos; - una suite de integración completa con las dependencias de servicio exigidas por el repositorio y un tiempo de espera ampliado. Si las pruebas de integración comparten el estado del servidor, ejecuta la suite completa en serie y nunca aumentes el paralelismo únicamente para reducir el tiempo de ejecución. Permite configurar los endpoints de servicio y conserva un valor local predeterminado y documentado. Ejecuta comprobaciones de lint o compilación para varias arquitecturas cuando el comportamiento de bajo nivel dependa de la arquitectura. En particular, verifica los objetivos de 32 bits cuando se use acceso atómico: los campos de 64 bits a los que se accede de forma atómica deben tener una alineación segura, por ejemplo colocándolos al principio de una estructura o usando envoltorios atómicos tipados. ## Sigue los patrones de la biblioteca para errores y API pública Respeta los patrones establecidos en el repositorio: - envuelve los errores con contexto mediante `%w` y compáralos con `errors.Is` o `errors.As`, en lugar de hacer coincidir el texto del mensaje; - usa `context.Context` como primer argumento de todos los métodos públicos que bloqueen y deriva los plazos del contexto del llamador, en vez de crear temporizadores de reloj independientes que compitan con él; - usa tipos de documento ordenados para comandos o datos donde importe el orden de las claves, tipos similares a mapas solo cuando el orden sea irrelevante y representaciones de bajo nivel respaldadas por secuencias de bytes únicamente en rutas críticas justificadas; - usa palabras completas en los identificadores exportados, añade comentarios de documentación que usen el nombre como sujeto y sigue el patrón de builder o setter del proyecto para las opciones nuevas. Conserva la ubicación actual de los paquetes y las decisiones de migración. No restaures rutas de importación retiradas ni abstracciones públicas obsoletas. Cuando la supervisión de comandos o los diagnósticos puedan observar intercambios de autenticación, incorpora los comandos que manejan credenciales a la política de redacción antes de exponer los eventos. Las dependencias nativas y las etiquetas de compilación específicas de una función deben permanecer explícitas en las instrucciones de configuración y pruebas. ## Separa las pruebas unitarias y de integración, y ejecuta las que exige el cambio Coloca las pruebas unitarias junto a la implementación y las pruebas de integración en el área de integración del repositorio. Usa los asistentes de aserción del proyecto y prefiere comprobaciones semánticas como `ErrorIs` a las aserciones por subcadenas. Para el comportamiento de integración, usa el arnés estándar que reconoce la topología para configurar el despliegue, inyectar puntos de fallo y capturar eventos. Conserva las fixtures de especificación en la ubicación designada para datos de prueba, inicializa los submódulos o fuentes de fixtures necesarios después de clonar y numera los casos de prueba descriptivos para que coincidan con la especificación aplicable cuando sea importante mantener la trazabilidad. Antes de la revisión, ejecuta el objetivo de verificación predeterminado. Ejecuta la suite completa en serie cuando el cambio afecte al comportamiento de integración o al estado compartido del servidor. Una prueba unitaria limitada que pasa no aporta evidencia suficiente para cambios sensibles a varias arquitecturas, a la compatibilidad o a las especificaciones. ## Prepara un pull request con los resultados de las pruebas y el impacto en la compatibilidad Usa el prefijo de elemento de trabajo requerido en los mensajes de commit y en los títulos de pull request. El pull request debe explicar el comportamiento visible para el usuario, el impacto en la compatibilidad, la evidencia de las pruebas y la elección de la rama. Añade evidencia específica del cambio: - para cambios en la API pública, genera el informe de API del repositorio e inclúyelo en el pull request; - para cambios incompatibles visibles para el usuario, actualiza la guía de migración correspondiente; - para trabajos de cumplimiento de especificaciones, cita el requisito exacto que satisface la implementación; - para cambios en paquetes experimentales que se puedan importar, señala explícitamente las incompatibilidades aunque el versionado semántico no lo exija. No presentes un cambio como listo solo porque se compile localmente. Para estar listo debe superar las comprobaciones predeterminadas del repositorio y todas las puertas de compatibilidad, integración, API y especificación que sean directamente aplicables.