Añade funcionalidades a un servicio Go extensible con pruebas que resistan la sobrescritura de la configuración

## Encuentra qué paquete es dueño del cambio antes de editar Clasifica el cambio y localiza la fuente de verdad antes de modificar el código. - Identifica el punto de entrada del comando, los paquetes de dominio, la capa de configuración, la capa de transporte y autorización, la implementación del protocolo, la capa de salida, el registro de capacidades y los metadatos de versión. - Mantén la lógica de negocio en los paquetes de código fuente que la poseen, no en el cableado de comandos ni en los envoltorios de distribución. - Trata los directorios de paquetes de lenguaje y de instaladores como adaptadores ligeros para la distribución de binarios; modifícalos solo para tareas de empaquetado o versionado. - Lee las definiciones de compilación, la configuración de pruebas, las implementaciones cercanas y la documentación para usuarios que rigen el área afectada. - Distingue las fuentes creadas manualmente de los archivos generados y los artefactos de compilación antes de editar. - Enumera cada manejador, tipo público, punto de registro, ruta de configuración, prueba, documento y superficie de paquetes afectados. Utiliza la disposición y las convenciones de nomenclatura establecidas en el repositorio en lugar de introducir una estructura paralela. ## Registra logs con el wrapper de contexto para mantenerlos unidos a las trazas Utiliza el envoltorio de registro contextual del repositorio siempre que el código de producción emita un registro. - Propaga el contexto de la solicitud hasta el punto donde se registra el evento; añade un parámetro de contexto cuando la cadena de llamadas aún no lo transporte. - No llames directamente al registrador de contexto base del framework cuando el envoltorio enriquezca los registros para correlacionarlos con la telemetría. - Si una función inicia un nuevo span de trazado, vuelve a obtener el registrador contextual después de iniciar el span; un registrador capturado previamente conserva el contexto del span anterior. - Mantén los valores estructurados asociados al contexto activo para que el puente de registro pueda vincular los registros con el trazado correcto. - Comprueba y gestiona todos los errores devueltos en el código de producción en lugar de descartarlos. - Conserva los límites de ocultación de datos, autorización y observabilidad establecidos en el repositorio al añadir diagnósticos. Verifica la correlación y el comportamiento de los errores mediante resultados observables, no solo por la presencia de una instrucción de registro. ## Añade herramientas nuevas con un handler, un grupo y su registro Diseña una capacidad nueva antes de implementarla: confirma su nombre, agrupación, esquema de entrada, comportamiento y cobertura de evaluación. 1. Implementa el manejador responsable de la lógica de la capacidad. 2. Define el contrato público de su herramienta o comando y conéctalo al manejador. 3. Añádela al grupo de capacidades adecuado o crea un grupo específico cuando no exista ninguno apropiado. 4. Registra un grupo nuevo mediante la ruta de inicialización del repositorio. 5. Actualiza conjuntamente las pruebas de comportamiento, las referencias de configuración, los catálogos generados y la documentación para usuarios. Mantén cada grupo de capacidades en su propio directorio asignado. Evita rutas de registro duplicadas o nombres que expongan detalles internos de implementación. ## Usa los targets de compilación declarados y no despliegues si no te lo piden Utiliza los objetivos de compilación declarados por el repositorio en lugar de reconstruir comandos de memoria. - Antes de ejecutarlo, conoce qué objetivo de compilación formatea el código fuente, ordena los módulos, compila una plataforma o construye todas las plataformas compatibles. - Inspecciona el diff resultante, porque un objetivo de compilación puede reescribir deliberadamente los metadatos de dependencias o los archivos generados. - Mantén ordenadas las declaraciones de dependencias después de introducir un módulo y ejecuta el objetivo de análisis estático con la versión fijada por el repositorio. - Conserva los modos compatibles de ejecución local y remota, incluida la precedencia documentada entre opciones explícitas, variables de entorno, archivos predeterminados y configuración interna del clúster. - Documenta los objetivos de prueba o lint que descarguen herramientas o entornos al usarse por primera vez; la falta de acceso a la red puede causar fallos de preparación, no fallos del código. - Mantén ligeros los envoltorios del gestor de paquetes y sincronizados con el binario compilado, en lugar de duplicar la lógica del servicio. Trata los objetivos que descargan, publican, hacen push o despliegan como límites de operaciones externas. Inspecciona primero sus contratos y nunca publiques ni despliegues salvo que la tarea incluya explícitamente trabajo de lanzamiento. ## Prueba el comportamiento público y los casos límite, no funciones privadas Ejercita la API pública como una caja negra y, cuando sea práctico, prefiere implementaciones reales o pruebas de integración. - Organiza las pruebas según la convención de suites del repositorio y proporciona una suite correspondiente para cada archivo de pruebas. - Utiliza subpruebas anidadas para agrupar escenarios relacionados y da a cada caso un nombre descriptivo basado en el comportamiento. - Lo ideal es que cada caso demuestre un solo comportamiento mediante una aserción específica. - Cubre las rutas satisfactorias, las devoluciones de llamada, los cambios de estado y las salidas observables sin acoplar las pruebas a funciones privadas. - Añade casos límite para valores nil o null, colecciones vacías, índices no válidos, incompatibilidades de tipos, entradas malformadas y rutas de error. - Utiliza aserciones de prerrequisitos para las operaciones de preparación que deban completarse correctamente y, después, comprueba explícitamente los errores o valores esperados. - Nunca ignores un error solo para mantener concisa una prueba. Ante un defecto, comienza con una prueba específica que falle, ejecuta el paquete o la suite afectados después de corregirlo y termina con el objetivo completo de pruebas exigido por el repositorio. ## Haz que las pruebas de configuración pasen aunque se sobrescriban valores y nombres Las pruebas de configuración deben seguir siendo válidas cuando las compilaciones posteriores sobrescriban valores predeterminados, nombres de funciones o conjuntos de capacidades habilitadas. - Inicia las suites de pruebas ordinarias con una configuración base sin sobrescrituras y superpón después los ajustes específicos de cada prueba. - Para configuraciones sencillas, combina los valores decodificados con la configuración existente de la suite, de modo que permanezcan intactos los campos de ejecución ya establecidos por el arnés. - Cuando una sección almacene valores diferidos o primitivos, utiliza el lector en dos fases que interpreta metadatos y que se requiere para analizar por completo esas secciones. - Tras una lectura completa de la configuración, restaura explícitamente los campos exclusivos de ejecución, como las rutas de conexión, las opciones de salida y el estado de solo lectura. - Para las pruebas de recarga, construye deliberadamente el candidato a partir de los valores predeterminados que reconocen sobrescrituras y que utiliza el servicio en ejecución; después, hereda los campos de ejecución activos. - Añade las capacidades necesarias a la lista existente; nunca sustituyas la lista por valores predeterminados del origen que solo se presuponen. - Resuelve dinámicamente los nombres públicos que admitan cambios de marca, pero mantén fija la clave literal de registro de un analizador cuando su contrato así lo exija. - Nunca codifiques de forma fija en las aserciones valores predeterminados, nombres públicos ni conjuntos de funciones susceptibles de sobrescritura. Siempre que los cambios de configuración crucen estos límites, prueba tanto el comportamiento base como al menos una ruta con sobrescritura. ## Reúne los helpers de prueba en un sitio y separa los fallos de preparación Coloca los auxiliares genéricos de prueba en el área interna compartida de pruebas del repositorio y documéntalos indicando claramente su propósito, sus entradas y ejemplos. - Mantén los auxiliares independientes de una sola función para que puedan reutilizarlos varios paquetes. - Prefiere interacciones realistas de usuarios o protocolos frente a atajos de bajo nivel que eludan el comportamiento de producción. - Explicita los prerrequisitos de las pruebas, incluidos los simuladores locales de clústeres, los entornos descargados, las credenciales o el acceso a la red necesario. - Distingue en los diagnósticos un fallo de preparación de un fallo del producto. - Procura una cobertura alta de la API pública, en especial de las condiciones límite y las rutas de fallo, sin inflar las métricas con casos de poco valor. - Mantén la configuración de pruebas, los alias y los fixtures generados alineados con el ejecutor de pruebas activo. Cuando existan personalizaciones posteriores, incluye pruebas representativas para capacidades renombradas, valores predeterminados modificados y recargas de configuración. ## Actualiza la documentación con el generador y mantén los paquetes en la misma versión Actualiza todas las superficies canónicas afectadas por un cambio de código o configuración. - Utiliza nombres de archivo en minúsculas para la documentación nueva cuando esa sea la convención del repositorio. - Actualiza los índices, las referencias de configuración y las guías de prompts, registro, observabilidad, autenticación e integración según el impacto de la función. - Trata las tablas generadas y las secciones de referencia como contenido generado; conserva sus pares de marcadores y actualízalas mediante el generador aprobado. - No edites directamente las secciones generadas ni confirmes artefactos de compilación salvo que la política del repositorio lo exija explícitamente. - Mantén los binarios nativos, las imágenes de contenedor y los envoltorios de paquetes de lenguaje alineados con el mismo comportamiento versionado del servicio. - Ejecuta las comprobaciones documentadas de compilación, pruebas, lint, generación de documentación y empaquetado específico que sean pertinentes para el cambio. Antes de presentar el cambio, confirma que el diff final solo contenga las actualizaciones previstas de código fuente, pruebas, documentación y paquetes. Ejecuta objetivos de lanzamiento o publicación únicamente cuando la tarea los incluya explícitamente e informa de cualquier comprobación más amplia que se haya dejado fuera del alcance de forma deliberada.