Modifica un repositorio de varios módulos con código generado sin pasarte de lo aprobado

## Lee las instrucciones de la raíz y de cada carpeta antes de editar Empieza por localizar las directrices del repositorio que rigen los archivos que puedes modificar. Trata la documentación del proyecto y los archivos de instrucciones anidados como la autoridad para las convenciones locales, en lugar de asumir reglas genéricas del ecosistema. - Lee las directrices de la raíz y cualquier instrucción más específica del directorio de destino. - Revisa la descripción general del repositorio, la guía de contribución, la configuración de desarrollo, las pautas de pruebas y la documentación de publicación relevantes para la tarea. - Sigue la instrucción aplicable más cercana cuando difieran las directrices generales del repositorio y las específicas del módulo. - Consulta las políticas referenciadas en archivos mantenidos por el proyecto, en lugar de depender de comandos recordados. - Identifica los archivos de responsabilidad y a los revisores encargados del área afectada. - Determina el flujo de trabajo admitido, las aprobaciones necesarias y las expectativas de validación antes de editar. - Pregunta solo cuando las fuentes autorizadas entren en conflicto o quede sin resolver una decisión con consecuencias importantes. ## Identifica qué módulo es dueño del cambio y quién lo revisa Comprende cómo está dividida la base de código antes de elegir dónde implementar un comportamiento. En un repositorio con varios módulos, los límites de compilación, los manifiestos de dependencias, las áreas generadas, los ejemplos, las pruebas y las unidades de publicación pueden variar según el directorio. - Localiza el módulo responsable del comportamiento público y los componentes de nivel inferior de los que depende. - Distingue la implementación escrita a mano del código generado, las plantillas, las especificaciones, los datos de prueba y los ejemplos. - Inspecciona los manifiestos del módulo para comprender los límites de las dependencias directas e indirectas. - Usa las reglas de responsabilidad para identificar a quienes mantienen el código, los servicios y la infraestructura compartida. - Determina si un cambio afecta a un paquete, a una familia de módulos o a una superficie de compatibilidad compartida. - Respeta la estructura de directorios y los patrones de nombres establecidos, en lugar de crear estructuras paralelas. - Mantén fuera del cambio los módulos no relacionados, a menos que una dependencia verificada exija actualizaciones coordinadas. ## Usa las versiones de herramientas y los comandos de tareas del proyecto Usa la cadena de herramientas declarada por el repositorio y el módulo de destino. La compatibilidad de versiones, los ejecutores de tareas, los generadores y la preparación del entorno son decisiones del proyecto, no valores que deban deducirse de la instalación local más reciente. - Confirma las versiones de lenguaje y herramientas admitidas actualmente en las políticas o configuraciones mantenidas. - Prefiere las tareas administradas por el repositorio a los comandos directos del lenguaje cuando realicen una preparación adicional. - Ejecuta los comandos desde el directorio del módulo o del espacio de trabajo que requiera el flujo documentado. - Conserva la selección del entorno, las opciones de compatibilidad, los recursos generados y las demás preparaciones realizadas por las tareas de referencia. - Instala requisitos previos globales únicamente cuando el flujo documentado los exija de forma explícita. - Mantén las versiones del generador y del compilador alineadas con las versiones fijadas o admitidas por el proyecto. - Informa de los requisitos previos ausentes como un impedimento concreto, en lugar de cambiar silenciosamente el flujo de trabajo. ## Pide permiso antes de publicar versiones, cambiar la CI o usar credenciales Los agentes pueden leer código, explicar comportamientos, proponer cambios, implementar ediciones autorizadas, añadir pruebas, mejorar documentación y ayudar a analizar incidencias o revisiones. Las operaciones de mayor impacto siguen sujetas a una autorización humana explícita. - No actives publicaciones, apruebes etapas de publicación ni publiques paquetes sin autorización. - No modifiques la integración continua, las canalizaciones de despliegue ni los controles del flujo de trabajo como parte incidental de otro cambio. - No alteres licencias, avisos legales ni políticas de cumplimiento sin autorización explícita. - No uses credenciales, contactes servicios externos ni modifiques estados remotos fuera de la tarea concedida. - Trata la clasificación de incidencias, las sugerencias de etiquetas y la detección de duplicados como recomendaciones, a menos que se hayan autorizado cambios de estado. - Detente antes de realizar operaciones destructivas o cambios en entornos protegidos y solicita la decisión necesaria. - Continúa con la implementación y la validación ordinarias dentro del alcance sin pedir confirmaciones innecesarias. ## Cambia la especificación y regenera en vez de editar archivos generados Los paquetes generados requieren una vía de cambio diferente a la del código escrito a mano. Las ediciones manuales del resultado generado suelen sobrescribirse y pueden separar la implementación de su especificación autorizada. - Identifica los archivos generados mediante marcadores del repositorio, manifiestos, archivos de ubicación o reglas de directorio documentadas. - No modifiques manualmente el resultado generado cuando el proyecto exija regenerarlo a partir de especificaciones. - Cambia la especificación, la plantilla o la entrada del generador que sea la fuente de referencia documentada. - Usa el comando de generación indicado por el proyecto y las versiones de herramientas requeridas. - Revisa el diff generado para detectar archivos inesperados, cambios de formato innecesarios o modificaciones de API no relacionadas. - Mantén los puntos de extensión manual separados de las regiones generadas conforme a los patrones del repositorio. - Si la regeneración no está disponible o no está autorizada, explica la limitación en lugar de presentar una edición temporal como una corrección duradera. ## Haz cambios pequeños que mantengan la compatibilidad con versiones anteriores Favorece cambios enfocados que respeten las convenciones de código existentes y conserven la compatibilidad. Una modificación limitada y fácil de revisar es más segura que una refactorización amplia cuando ambas satisfacen el requisito. - Lee las implementaciones cercanas antes de elegir auxiliares, nombres, patrones de error y ubicación de archivos. - Conserva la compatibilidad con versiones anteriores, a menos que un cambio incompatible esté aprobado y documentado explícitamente. - Sigue las convenciones locales para nombres públicos, siglas, comentarios y documentación de API públicas. - Usa errores descriptivos que conserven contexto útil sin exponer información confidencial. - Mantén intactos los avisos de derechos de autor y licencias requeridos. - Respeta la política de dependencias del módulo y evita añadir una dependencia externa para un comportamiento ya disponible localmente. - Separa las tareas de limpieza no relacionadas del cambio solicitado para que los revisores puedan evaluar claramente la intención. ## Compila y prueba primero el módulo afectado y amplía solo si hace falta Ejecuta primero los comandos mínimos que ejerciten el módulo afectado y amplía la validación solo cuando lo exijan el comportamiento compartido o la política del repositorio. Un comando correcto solo es significativo si cubre la ruta modificada. - Compila el módulo de destino con su tarea documentada o con el comando de lenguaje correspondiente. - Ejecuta las pruebas unitarias directamente relevantes antes que los conjuntos de pruebas más amplios del paquete o del espacio de trabajo. - Añade comprobaciones de tipos, análisis estático, formato y verificación de archivos generados cuando el módulo las requiera. - Confirma que la selección de pruebas incluyó realmente el paquete y los casos previstos. - Revisa las variables de entorno necesarias antes de intentar pruebas de integración o en entornos reales. - No afirmes haber validado a partir de un comando que omitió objetivos o dependió de un estado externo no disponible. - Registra los comandos ejecutados, los resultados observados y las comprobaciones que no se pudieron completar. ## Escribe pruebas que no dependan de la red ni del orden, y ejemplos que funcionen Las pruebas deben demostrar el cambio de comportamiento y seguir siendo fiables en distintos equipos. Los ejemplos deben mostrar un uso admitido y respetar las convenciones del repositorio para ejemplos ejecutables. - Reutiliza la biblioteca de aserciones y la estructura de pruebas ya establecidas en el módulo. - Al corregir un defecto, confirma que la nueva prueba falla por el motivo previsto antes de aplicar la corrección. - Mantén las pruebas unitarias independientes de redes, credenciales, estados que cambian con el tiempo y el orden de ejecución. - Guarda los datos de prueba en la ubicación designada y mantenlos al mínimo. - Aísla la configuración de pruebas en entornos reales en archivos de entorno autorizados y nunca confirmes información confidencial. - Añade mensajes a las aserciones cuando mejoren de forma sustancial el diagnóstico. - Coloca los ejemplos en la estructura de nombres y paquetes esperada, y asegúrate de que se compilen o ejecuten mediante el flujo de pruebas documentado. ## Actualiza la documentación del módulo y el registro de cambios cuando cambie el comportamiento La documentación forma parte de la superficie de implementación. Actualízala cuando, de otro modo, los usuarios, responsables de mantenimiento o herramientas de publicación recibirían una visión incompleta o engañosa del cambio. - Actualiza la descripción general del módulo cuando cambien la configuración, el comportamiento admitido o el uso público. - Añade o revisa comentarios de API conforme al estilo de documentación del proyecto. - Registra los cambios visibles para los usuarios en el historial requerido. - Proporciona ejemplos para nuevas API públicas cuando lo exija la política del repositorio. - Mantén sincronizadas las instrucciones de configuración, generación, migración y publicación con los comandos reales. - Verifica que las referencias sigan siendo válidas y no dirijan a ubicaciones privadas u obsoletas. - Evita cambios innecesarios en la documentación cuando el comportamiento y el flujo de trabajo no hayan cambiado. ## Abre la solicitud de cambios desde la rama aprobada tras revisar todo el diff Usa la vía de contribución aprobada por el repositorio y facilita la inspección del cambio completo. Una contribución debe conectar la implementación, las pruebas, la documentación y la justificación sin alterar el historial compartido protegido. - Crea el trabajo desde la rama base aprobada y publícalo mediante el fork o el remoto autorizado. - Revisa el diff completo de la rama antes de abrir una solicitud de cambio. - Usa un título descriptivo y cita el trabajo relacionado cuando esté disponible. - Incluye pruebas que eviten regresiones futuras y la documentación exigida por la política. - Responde a los comentarios de revisión con cambios posteriores rastreables, a menos que quienes mantienen el proyecto pidan otra estrategia de historial. - Verifica todas las comprobaciones automatizadas obligatorias e investiga los fallos en lugar de omitirlas. - No alteres ramas protegidas, ramas de publicación ni el historial compartido sin autorización explícita. ## Revisa el código en busca de cambios incompatibles y errores en archivos generados La revisión de código debe priorizar la corrección, la compatibilidad, la integridad de la generación, la calidad de las pruebas, la seguridad y la facilidad de mantenimiento. Aplica las pautas específicas del proyecto, en lugar de una lista genérica de estilo. - Comprueba que el cambio pertenece al módulo elegido y respeta su arquitectura. - Busca cambios incompatibles en la API o el comportamiento, incluidos los cambios sutiles en los valores predeterminados. - Verifica que las pruebas cubran éxitos, fallos, límites y repetibilidad cuando corresponda. - Confirma que los archivos generados proceden de la fuente y el flujo de generación aprobados. - Inspecciona los cambios en dependencias y manifiestos para detectar incumplimientos de políticas o adiciones innecesarias. - Comprueba que la documentación y los registros de cambios sean completos y precisos. - Dirige los hallazgos a quienes sean responsables y distingue los defectos bloqueantes de las mejoras opcionales. ## Reporta los fallos de seguridad en privado y entrega los resultados de las pruebas Los informes de seguridad, las publicaciones, las aprobaciones de canalizaciones, las licencias y las credenciales requieren un tratamiento específico. Finaliza el trabajo ordinario con una entrega basada en evidencias y deja las operaciones protegidas en manos de personas autorizadas. - Informa de las vulnerabilidades de seguridad mediante el canal privado del proyecto, no en una incidencia o conversación pública. - Nunca incluyas secretos, datos de contacto privados ni información sensible de reproducción en materiales públicos. - Deja las activaciones de publicación, las aprobaciones de despliegue y las decisiones sobre licencias a responsables de mantenimiento expresamente autorizados. - Explica las decisiones importantes de implementación y relaciónalas con las pautas aplicables del proyecto. - Resume las rutas modificadas, las pruebas realizadas, los resultados observados y las limitaciones pendientes. - Identifica a los responsables adecuados del código o del servicio cuando se requiera una revisión adicional. - Indica claramente cuando el acceso externo, la falta de herramientas o un límite de aprobación impidan una verificación completa.