Modifica un monorrepositorio con varias implementaciones sin que se desajusten

## Antes de editar, revisa la estructura del monorrepositorio y sus reglas locales - Traza el repositorio por producto, lenguaje, dominio funcional, área de utilidades compartidas, conjunto de pruebas, herramientas de publicación y configuración. - Identifica qué directorios pertenecen a cada implementación y qué reglas de nivel superior se aplican a todo el repositorio. - Antes de editar un área anidada, lee su guía local para agentes, su guía de contribución y su configuración; las reglas locales pueden especializar la base, pero no deben debilitarla. - Aplica las reglas de compilación, estilo y pruebas propias de un lenguaje únicamente al código escrito en ese lenguaje. - Localiza la definición del espacio de trabajo, los scripts raíz y las instrucciones específicas del producto antes de elegir comandos o dependencias. ## Lleva cada cambio visible para el usuario a todas las implementaciones - Trata las implementaciones paralelas del mismo producto destinado al usuario como fuentes de verdad equivalentes. - Siempre que sea posible, reproduce cada cambio visible para el usuario en todas las implementaciones dentro de la misma solicitud de cambio. - El comportamiento visible para el usuario incluye indicadores, valores predeterminados, tratamiento del entorno, códigos y mensajes de error, registros que consumen las herramientas, formatos de archivos y estados, disposición del almacenamiento y semántica de los ganchos. - Las refactorizaciones internas, las mejoras de rendimiento exclusivas de una implementación y la limpieza de pruebas específica de una implementación no requieren una reproducción artificial. - Si el trabajo equivalente no puede completarse de inmediato, indica la diferencia exacta de paridad, por qué permanece y qué debe incorporarse antes de poder integrar el cambio. - Nunca permitas que una implementación se convierta en una adaptación descendente no documentada de otra. ## Recompila lo que ejecutan las pruebas para no probar código antiguo - Instala las dependencias y compila mediante la ruta de inicialización documentada del repositorio antes de confiar en los resultados de las pruebas. - Durante una iteración rápida, compila solo el paquete afectado cuando esto produzca el mismo artefacto que consumen las pruebas seleccionadas. - Determina si las pruebas de extremo a extremo ejecutan resultados del código fuente, resultados del paquete o un ejecutable empaquetado. - Vuelve a crear el paquete integrado después de cualquier cambio en uno de sus paquetes componentes cuando las pruebas de extremo a extremo lo consuman; de lo contrario, la prueba podría ejecutar código obsoleto. - Ejecuta la compilación correspondiente al lenguaje para cada implementación modificada. - Considera inválida como evidencia una prueba satisfactoria ejecutada sobre resultados generados obsoletos. ## Prueba solo lo afectado e investiga cada fallo - No ejecutes de forma predeterminada todo el conjunto de pruebas de un repositorio grande. Empieza por el proyecto, archivo o caso de prueba nombrado que resulte afectado. - Amplía el alcance de las pruebas únicamente cuando lo justifiquen las dependencias, los contratos compartidos o los fallos observados. - Haz coincidir el entorno de ejecución, el artefacto compilado y la implementación sometida a prueba con la afirmación que se verifica. - Investiga cada fallo en vez de calificarlo como no relacionado o preexistente sin pruebas. - Si un fallo ya existía antes del cambio, identifica su causa y corrígelo dentro del alcance autorizado o informa del impedimento concreto; nunca lo omitas silenciosamente. - Registra el comando exacto, el objetivo afectado y el resultado para que otra persona colaboradora pueda reproducir la evidencia. ## Revisa el código modificado: primero seguridad, luego rendimiento - Sigue la guía de revisión del repositorio y limita los hallazgos al código afectado por el cambio y a sus consecuencias directas. - Revisa primero la seguridad y después el rendimiento, salvo que se aplique una regla de proyecto más estricta. - Para un hallazgo de seguridad, explica la entrada alcanzable, el límite de confianza, la ruta de explotación y el impacto. - Para un hallazgo de rendimiento, identifica la ruta crítica, la frecuencia, el coste de asignación o de E/S y el efecto probable para el usuario. - Verifica las pruebas, la intención de publicación y la paridad entre implementaciones como parte de la aceptación. - No presentes hallazgos especulativos que no puedan relacionarse con el comportamiento modificado. ## Busca código y dependencias existentes antes de añadir otros nuevos - Busca en los paquetes compartidos, las funciones auxiliares del sistema de archivos, las utilidades criptográficas, las utilidades de texto y los módulos de dominio próximos antes de implementar lógica no trivial. - Reutiliza una utilidad exportada existente cuando ya sea responsable de ese comportamiento. - Si existe lógica similar pero está confinada en un paquete, extrae el contrato común a la ubicación compartida más específica que resulte adecuada, en vez de copiarla. - Prefiere una dependencia existente y mantenida para una función común cuando sea adecuada, lo bastante ligera y esté permitida por la política del repositorio. - Añade una dependencia nueva al paquete más específico que la necesite; súbela de nivel únicamente cuando varios paquetes realmente la compartan. - No añadas envoltorios que se limiten a cambiar el nombre de una operación existente o a reenviarla sin añadir un contrato. ## Sigue las reglas de los mensajes de confirmación sin saltarte los ganchos - Usa la convención obligatoria del repositorio para los mensajes de confirmación y elige el tipo de cambio que refleje el impacto para el usuario. - Antes de confirmar, verifica que los ganchos del repositorio estén instalados y activos; una copia de trabajo recién obtenida puede no haberlos registrado. - Nunca eludas un control de confirmación fallido, desactives el gancho ni añadas un archivo de supresión. Corrige el mensaje o el cambio subyacente. - Evita las referencias numéricas sin calificar a incidencias porque la plataforma de alojamiento puede enlazarlas al repositorio equivocado; usa una referencia que incluya el repositorio o una URL absoluta. - Encierra los identificadores de código que parezcan nombres de usuario en código en línea o elimina las menciones innecesarias para que una confirmación no avise a personas ajenas. - Usa numeración de listas sin un marcador de referencia al enumerar elementos. ## Añade una entrada de publicación cuando cambie un paquete publicado - Añade una entrada de intención de publicación siempre que un cambio afecte a un paquete publicado. - Nombra todos los paquetes afectados y selecciona el impacto de versión entre corrección de defecto, función compatible con versiones anteriores o cambio incompatible. - Escribe la entrada para los usuarios y mantenla concisa; coloca la justificación de implementación en el mensaje de confirmación. - Incluye el paquete principal de línea de comandos para los cambios en su implementación principal cuando lo exija la política del repositorio. - Para cambios específicos de una implementación, nombra únicamente los productos que hayan cambiado realmente. Un cambio de paridad debe nombrar paquetes de cada implementación afectada. - Respeta las vías de publicación estable y preliminar, los grupos de versión fija y el procedimiento de promoción del repositorio. ## Comenta solo los motivos que el propio código no deja ver - Prefiere nombres, tipos, límites de funciones auxiliares y flujos de control que permitan que el código se explique por sí mismo. - No añadas comentarios que repitan una operación, dupliquen la documentación de la función llamada o narren una sintaxis evidente. - Documenta un motivo compartido una sola vez en el propietario común, en vez de repetirlo en cada lugar de llamada. - Usa comentarios de documentación para las condiciones previas, las condiciones posteriores, los casos límite y las garantías no evidentes. - Conserva el historial de refactorización y las descripciones de diseños retirados en el historial del control de versiones y en los mensajes de cambio, no en los comentarios actuales del código fuente. - Antes de añadir prosa, pregúntate si cambiar nombres, reestructurar o extraer comunicaría la idea de forma más fiable. ## Sigue las reglas de formato y de manejo de errores del repositorio - Usa el formateador y la guía de estilo propia del lenguaje del repositorio; conserva la agrupación y el orden establecidos de las importaciones. - Prefiere las funciones a las clases con estado cuando así lo haga el código base y sustituye las listas largas de parámetros por un objeto de opciones tipado. - Usa tipos de error de dominio estables para fallos alcanzables por el usuario, conserva los códigos de error, incluye el contexto pertinente y nunca ocultes errores inesperados. - Captura únicamente la condición de error esperada y usa una comprobación de errores nativos segura entre contextos en entornos de prueba virtualizados. - Da nombres verbales a las funciones, mantén la terminología coherente y cambia el nombre de un concepto en todas partes cuando cambie su contrato. - Prefiere operaciones de cadena simples para análisis sencillos y el analizador estructurado existente para gramáticas que requieran retroceso. - Encauza los valores configurables mediante la capa de configuración, mantén los controladores de comandos independientes de la presentación y evita políticas codificadas directamente. - Usa E/S asíncrona, ejecuta en paralelo las operaciones independientes, espera la finalización requerida y saca de los bucles el trabajo invariable. ## Mantén la solicitud de cambio fiel a los cambios reales hasta la integración - Abre una solicitud de cambio con la plantilla del repositorio, conserva las secciones obligatorias y elimina únicamente el contenido que la plantilla marque como opcional. - Mantén el título y la descripción sincronizados con los cambios reales después de cada actualización importante. - Responde a las conversaciones de revisión atendidas con la solución y la revisión que la respalda y, después, marca la conversación como resuelta. - Etiqueta el contenido remoto creado por agentes según la política del repositorio sin exponer contexto de implementación sensible. - Usa el flujo de resolución de conflictos aprobado por el repositorio para mantener actualizada la base, volver a generar de forma determinista los datos de bloqueo y verificar que sea posible integrar. - Inspecciona manualmente los conflictos de elementos no generados. Toda actualización forzada u otra reescritura remota del historial requiere autorización explícita y un objetivo verificado.