Añada módulos a un servidor Go sin debilitar la seguridad

## Mantenga valores predeterminados seguros y decida dónde va cada función nueva Trate los valores predeterminados seguros como el principal requisito de producto para una plataforma de servidor expuesta a Internet. Diseñe las funciones como módulos combinables en lugar de acoplarlas estrechamente al núcleo. Prefiera extensiones generales que sirvan a una clase de casos de uso antes que parches para un único despliegue. Determine si un cambio pertenece a una aplicación de nivel superior, un módulo reutilizable, una adaptación de configuración o el punto de entrada de la línea de comandos. Mantenga los identificadores de módulos dentro de espacios de nombres para que los componentes desarrollados de forma independiente no colisionen. Preserve un modelo nativo de configuración estructurada aunque haya adaptadores fáciles de usar. Revise con especial rigor el procesamiento de solicitudes, la seguridad del transporte, la identidad, la gestión de certificados y los límites de confianza. Rastree el comportamiento sensible para la seguridad entre repositorios o paquetes relacionados cuando la responsabilidad esté distribuida. No considere que un cambio crítico para la seguridad está listo para fusionarse hasta comprender los límites de confianza y los modos de fallo afectados. Mantenga explícito el registro de módulos estándar para que los componentes distribuidos se puedan descubrir y auditar. Asegúrese de que los binarios de comandos importen el conjunto de módulos previsto, en lugar de depender de un registro accidental. Documente la ubicación arquitectónica cuando una nueva función pueda residir razonablemente en más de una capa. Rechace los diseños que debiliten los valores predeterminados seguros solo para reducir el esfuerzo de implementación. Tenga presente la compatibilidad con todos los sistemas operativos admitidos desde la primera decisión de diseño. ## Siga el estilo habitual de Go en errores, nombres y comentarios Use retornos anticipados para los errores y mantenga la ruta correcta en el nivel mínimo de sangría. Evite ramas else después de una rama que ya retorna. Escriba las siglas comunes en su forma convencional en mayúsculas, incluidas URL, HTTP e ID. Elija nombres cortos para los receptores que reflejen de forma coherente el tipo del receptor. Empiece las cadenas de error con texto en minúscula y omita la puntuación final. Escriba la documentación exportada como oraciones completas que comiencen por el nombre declarado. Use un slice nil cuando un slice vacío asignado no tenga valor semántico. Devuelva errores para los fallos esperados en lugar de provocar un panic. Mantenga el tratamiento de errores cerca de la operación que puede fallar. Envuelva los errores solo cuando el contexto adicional ayude a localizar la operación fallida. Conserve los errores en un formato que los llamadores puedan inspeccionar cuando se espere un tratamiento programático. Evite flujos de control ingeniosos que oculten la propiedad o la limpieza de los recursos. Ejecute el formateo y el análisis estático antes de la revisión. Aplique las convenciones establecidas del repositorio aunque exista otro estilo de Go válido. Use aserciones de interfaz en tiempo de compilación para los tipos que deban satisfacer interfaces del framework. Mantenga estables los nombres de receptores, paquetes y elementos exportados, salvo que se apruebe un cambio de compatibilidad deliberado. ## Construya cada módulo en orden, desde su creación hasta la limpieza Registre cada módulo mediante el mecanismo de registro estándar del framework. Devuelva metadatos que contengan un ID de módulo con espacio de nombres y un constructor para una instancia nueva. Mantenga los constructores libres de efectos secundarios específicos del entorno. Trate el ciclo de vida como fases ordenadas: 1. Construya un valor nuevo. 2. Descodifique la configuración en él. 3. Aprovisione las dependencias de tiempo de ejecución. 4. Valide la configuración completa. 5. Sirva o ejecute la función del módulo. 6. Limpie los recursos que posee. No realice la validación final antes de que estén disponibles los datos de configuración y aprovisionamiento. Haga que la limpieza sea segura después de un aprovisionamiento parcial y de señales de apagado repetidas cuando el framework pueda invocarla de ese modo. Use protecciones en tiempo de compilación para el aprovisionamiento, la validación, el análisis de configuración y otras interfaces opcionales. Mantenga separadas las responsabilidades del ciclo de vida para que los errores de configuración se distingan de los fallos de tiempo de ejecución. Devuelva errores que permitan actuar durante el aprovisionamiento y la validación. No oculte una inicialización fallida tras un módulo que solo se puede usar parcialmente. Use interfaces de aplicación de nivel superior únicamente para los componentes que realmente sean responsables del comportamiento de inicio y parada. Mantenga estables los ID de los módulos porque la configuración, los adaptadores y las integraciones externas pueden depender de ellos. ## Lea los archivos de configuración de forma estricta y proteja los endpoints administrativos Analice la configuración orientada a las personas mediante el dispensador de tokens del framework o un iterador estructurado equivalente. Consuma el nombre de la directiva antes de leer los argumentos en línea. Procese los argumentos en línea por separado de los bloques anidados. Capture el nivel de anidamiento actual y deténgase cuando el analizador salga de ese bloque. Reconozca explícitamente las subdirectivas admitidas. Valide de inmediato los argumentos obligatorios y devuelva el error de argumentos estándar del analizador. Rechace las subdirectivas desconocidas con un error que incluya el valor inesperado. Documente la sintaxis aceptada junto al analizador como un contrato sujeto a mantenimiento. Mantenga la salida del adaptador alineada con el modelo nativo de configuración estructurada. Obtenga los registradores y otros módulos mediante el contexto del framework durante el aprovisionamiento. Use un registrador estructurado con ámbito de módulo y adjunte campos en lugar de construir mensajes no estructurados. No almacene contextos de solicitudes ni de aprovisionamiento en estructuras de larga duración. Implemente la interfaz de enrutamiento del framework cuando añada endpoints administrativos. Aplique las reglas de autenticación, autorización y exposición que requiera la superficie administrativa. Valide la configuración antes de que el módulo empiece a procesar tráfico. ## Evite nuevas dependencias y mantenga claros los límites entre paquetes Evite dependencias nuevas salvo que su valor supere claramente los costes de mantenimiento, seguridad y cadena de suministro. Integre directamente una funcionalidad pequeña y estable cuando una dependencia diminuta añadiría un riesgo desproporcionado. No exponga tipos de paquetes externos a través de la API pública del proyecto. Encapsule el comportamiento de terceros tras interfaces y tipos pertenecientes al proyecto. Use las herramientas de módulos del lenguaje para mantener coherentes las declaraciones y las sumas de comprobación de las dependencias. Ejecute el comando de ordenación de dependencias y revise su diff en lugar de aceptar cambios no relacionados. Mantenga los adaptadores de configuración separados de los módulos de tiempo de ejecución. Mantenga las utilidades de prueba separadas de los puntos de entrada de producción. Coloque los módulos estándar en el registro que usa el comando distribuido. No importe módulos opcionales en el binario predeterminado sin una decisión explícita de producto. Preserve los límites de los paquetes en torno al procesamiento de protocolos, la seguridad del transporte y las operaciones con certificados. Elija abstracciones generalizadas solo después de identificar el comportamiento repetido al que sirven. Rechace las abstracciones especulativas que oculten una implementación sencilla. Al refactorizar, preserve el comportamiento observable o documente y pruebe cada cambio intencionado. Revise los paquetes críticos para la seguridad y los cambios de dependencias con mayor profundidad que el código interno rutinario. ## Pase todas las pruebas, el lint y la compilación antes de fusionar Trate todos los controles de calidad obligatorios como bloqueantes, no como recomendaciones. Ejecute la suite completa de pruebas cortas con la detección de condiciones de carrera activada. Ejecute el linter configurado con tiempo suficiente para abarcar todo el repositorio. Compile todos los paquetes para detectar interfaces ausentes, restricciones de plataforma y errores de registro. Para cambios de rendimiento, ejecute benchmarks con mediciones de memoria. Compare los resultados de los benchmarks con una referencia adecuada y tenga en cuenta la variación. Ejecute pruebas de integración focalizadas para el comportamiento del servidor afectado. Asegúrese de que las pruebas pasen en Linux, macOS y Windows cuando la integración continua admita esas plataformas. Examine las advertencias de los archivos modificados aunque existan advertencias no relacionadas en otros lugares. No marque una pull request como lista para fusionarse mientras falte algún control obligatorio de pruebas, lint, compilación o benchmarks. Registre los comandos y los resultados pertinentes para que los revisores puedan reproducir las pruebas. Distinga un fallo de prueba de un fallo del entorno antes de cambiar el código de producción. Mantenga la verificación proporcional al cambio sin dejar de cubrir cada control afectado directamente. Vuelva a ejecutar los controles afectados después de cualquier cambio de código realizado en respuesta a la revisión. Trate los informes de condiciones de carrera y los fallos intermitentes de concurrencia como defectos que requieren investigación. ## Escriba pruebas unitarias basadas en tablas y pruebas de servidor con puertos propios Prefiera pruebas basadas en tablas cuando varias entradas compartan el mismo comportamiento. Proporcione para cada caso una entrada explícita, una salida esperada y un estado de error esperado. Compruebe tanto la ausencia de los errores esperados como los errores inesperados devueltos. Compare los valores devueltos solo después de tratar adecuadamente la condición de error. Incluya casos válidos, no válidos, límite y de regresión. Asigne nombres a los casos cuando los índices por sí solos dificulten el diagnóstico de los fallos. Mantenga los fixtures mínimos y deterministas. Use el entorno de pruebas de servidor del proyecto para el comportamiento de configuración de extremo a extremo. Inicialice los servidores de prueba con una configuración aislada y formatos explícitos. Use puertos no estándar para evitar conflictos con los servicios que se ejecutan localmente. Reserve puertos independientes para la administración, el tráfico sin cifrar y el tráfico cifrado cuando sea necesario. Compruebe el estado, el cuerpo y otros comportamientos observables desde el exterior. Limpie los servidores, listeners, archivos y goroutines creados por la prueba. No dependa del orden de las pruebas ni de un estado global mutable compartido. Pruebe los errores de análisis de la configuración además del inicio correcto del servidor. Añada casos específicos de la plataforma cuando difieran las rutas, los sockets, las señales o el comportamiento de los procesos. Mantenga las pruebas de integración lo bastante focalizadas como para que un fallo identifique el contrato vulnerado. ## Deje las pull requests, los informes de seguridad y los acuerdos a una persona Trate los debates de issues, las pull requests, los acuerdos de licencia y los informes de seguridad como acciones externas gobernadas por personas. Un asistente de IA no debe hacerse pasar por un colaborador humano ni aceptar un acuerdo legal en nombre de una persona. No cree ni envíe issues externos, pull requests ni informes de seguridad salvo que la política rectora autorice explícitamente esa acción del agente. Mantenga la asistencia a la revisión dentro del rol permitido e identifique la participación de la IA cuando sea obligatorio. No oculte la intervención de la IA cuando la divulgación forme parte de la política de contribución. Exija que el operador humano entienda y pueda explicar cada línea enviada. Pruebe el código asistido por IA con comprobaciones automatizadas cuando sea viable y con comprobaciones manuales exhaustivas en caso contrario. Revise el código generado para detectar material copiado, licencias incompatibles y afirmaciones no verificadas. No invente detalles de vulnerabilidades ni envíe un informe de seguridad no verificado. La asistencia de traducción o edición debe preservar los hechos de seguridad verificados por el autor humano. Deje las firmas, declaraciones y acuerdos de contribución exclusivos de personas a cargo de la persona responsable. Cuando una acción solicitada entre en conflicto con la política de contribución, detenga esa acción y explique el límite aplicable. No añada archivos, comentarios ni commits engañosos como sustituto de una acción externa prohibida. Mantenga la utilidad técnica del parche sin eludir el proceso de la comunidad. Antes de la aprobación, verifique la divulgación, la comprensión, las pruebas y las licencias como controles independientes. La responsabilidad humana sigue siendo obligatoria incluso cuando un agente haya producido la mayor parte de la implementación.