Modifica un gran monorepositorio de plataforma de datos multilingüe y prepara pull requests

## Revisa los remotos de Git y elige la rama correcta antes de la primera edición Antes de la primera edición o prueba de una sesión: 1. identifica el fork personal y los repositorios remotos upstream autoritativos; si sus funciones no están claras, solicita que se configure la disposición remota estándar; 2. comprueba la marca de tiempo de la rama predeterminada del upstream y actualízala cuando la referencia local esté obsoleta; 3. inspecciona el árbol de trabajo y pide al usuario que proteja los cambios sin confirmar antes de cambiar de contexto; 4. elige la rama según la tarea. Para una revisión existente, identifica su rama head, utiliza una rama local coincidente cuando exista e informa del cambio. Si no existe ninguna coincidencia, pregunta si se debe obtener la rama o utilizar una rama local con un nombre diferente. Para una nueva edición, ofrece como opción recomendada un worktree aislado creado desde la rama predeterminada del upstream, o una rama nueva basada en ella. Para un trabajo que solo requiera pruebas, utiliza la rama predeterminada del upstream. ## Regenera las salidas de referencia de las pruebas y los archivos de protocolo en lugar de editarlos Las salidas golden de las pruebas pertenecen al arnés de pruebas que las genera. Lee la documentación de la suite antes de ejecutarlas o actualizarlas, nunca edites directamente los archivos de resultados esperados generados y vuelve a generarlos mediante el flujo de trabajo admitido. Revisa cuidadosamente la diferencia resultante antes de aceptarla. Las definiciones del protocolo pertenecen a su esquema de origen. Lee la documentación almacenada junto a esas definiciones antes de cambiar mensajes o campos y no incluyas los artefactos de protocolo generados en las ediciones manuales. ## Mantén el código en ASCII y dentro del límite de línea antes de CI Mantén los identificadores, el código y los comentarios en ASCII, salvo que el contenido de un literal de cadena o un fixture de prueba requiera realmente otros caracteres. Comprueba de forma puntual que los archivos modificados no contengan rayas tipográficas, comillas curvas, puntos suspensivos ni espacios de no separación, que suelen introducirse en los comentarios sin que se advierta. Mantén las líneas del código fuente dentro del límite del repositorio, que suele ser de 100 caracteres. Un análisis rápido de los archivos fuente añadidos y modificados puede aproximar las excepciones para importaciones, declaraciones de package y URL, pero solo sirve como indicio. Los linters específicos de cada lenguaje siguen siendo la autoridad. ## Elige la base de pruebas de JVM más pequeña que cubra la prueba Selecciona la base de pruebas más pequeña que proporcione el comportamiento requerido. Las pruebas sencillas de ejecución o de utilidades deben usar la suite principal únicamente con ayudantes comunes de tiempo de espera, archivos temporales, registro y errores. Las pruebas del plan lógico, el analizador, el optimizador o el planificador deben usar una base para pruebas de planes sin iniciar una sesión SQL. Las pruebas de SQL o de tablas deben usar la base para pruebas de consultas e incorporar un proveedor de sesiones explícito mediante un mixin. Elige una sesión dentro del proceso para las pruebas SQL ordinarias y un proveedor respaldado por un almacén solo cuando se necesite el comportamiento de ese almacén. No asumas el coste de un fixture más amplio únicamente porque lo utilicen pruebas cercanas. ## Elige la base de pruebas de Python adecuada para pruebas locales, remotas y mixtas Las pruebas sencillas de Python deben usar la base estándar de pruebas unitarias. Las pruebas en el nivel de contexto pueden crear un contexto de ejecución nuevo para cada prueba a fin de lograr aislamiento, o reutilizar uno por clase para mejorar la velocidad. Las pruebas de SQL y DataFrame deben usar la base compartida de sesiones classic, mientras que las pruebas de extensiones de DataFrame pueden añadir ejecución columnar y aserciones especializadas. Las pruebas del protocolo remoto requieren una decisión independiente: usa un fixture simulado solo para planes cuando no se necesite un servidor, una sesión remota reutilizada para probar el comportamiento remoto real o un fixture mixto classic y remote para comprobar la paridad. Trata las utilidades SQL, las aserciones de errores estructurados y los ayudantes de igualdad como mixins o ayudantes independientes, no como bases de pruebas, salvo que creen el entorno de ejecución requerido. ## Compila y prueba solo el módulo cambiado, y pregunta antes de la suite completa Las compilaciones y las pruebas pueden ser costosas. Si el usuario solicitó explícitamente las pruebas, ejecútalas. De lo contrario, antes de iniciar una verificación prolongada de la suite completa, pregunta si se esperan más ediciones. Prefiere la herramienta de compilación incremental más rápida del repositorio, compila únicamente el módulo afectado y su código de prueba, y ejecuta una sola suite o un caso por nombre durante las iteraciones. Mantén abierta una shell de compilación incremental cuando así se reduzca el tiempo de las pruebas repetidas del módulo. Para las suites de Python que dependen de un backend compilado, compila primero el perfil de funciones requerido, activa el entorno virtual elegido por el usuario o el predeterminado en la documentación, y crea ese entorno únicamente si no existe. Usa los selectores de suites y casos del ejecutor de pruebas del proyecto. ## Enumera todos los fallos de CI antes de arreglar uno Enumera todas las comprobaciones fallidas de la confirmación sometida a revisión antes de investigar un fallo concreto. Una comprobación del resumen de pruebas que haya pasado o no exista no demuestra que CI esté completamente correcto; los linters, las licencias, las dependencias, las comprobaciones de compatibilidad, la compilación y la generación de documentación pueden fallar en trabajos independientes sin anotaciones de pruebas. Para los trabajos de pruebas, usa las anotaciones de fallo para obtener la suite, el caso y el mensaje. Para los trabajos que no sean de pruebas, identifica el paso fallido y lee el registro centrado en ese trabajo. Evita descargar registros muy grandes de pruebas fragmentadas cuando las anotaciones estructuradas ya contengan las pruebas útiles. ## Comprueba si una pull request cerrada se integró en realidad No supongas que una revisión marcada como cerrada fue rechazada. Algunos proyectos realizan las integraciones mediante herramientas personalizadas, por lo que el servicio de alojamiento puede mostrar una revisión integrada correctamente como cerrada y sin una marca de tiempo de integración nativa. Utiliza el ayudante de estado de integración del proyecto para determinar si el cambio se incorporó y qué ramas principales o de mantenimiento lo contienen. Trata los estados abierto, integrado y cerrado sin integración como resultados distintos, e informa de la falta de autenticación, un historial superficial, revisiones desconocidas o repositorios remotos upstream ausentes como limitaciones del entorno. ## Escribe el título y la descripción de la pull request con el formato del proyecto Sigue la convención de títulos del proyecto para los identificadores de issue y las etiquetas de componentes, incluidas las excepciones documentadas para cambios en borrador, en curso, menores o triviales. Deduce el título a partir de la diferencia. Cuando falte un issue obligatorio, créalo mediante el ayudante del proyecto con el componente exacto y un tipo de issue o una referencia al elemento principal; después, muestra de forma destacada el issue creado y sus campos para su revisión. Lee la plantilla de pull request del repositorio antes de redactar la descripción y completa todas las secciones. Usa el nombre completo del componente cuando el sistema de seguimiento de issues lo requiera en lugar de la etiqueta abreviada del título. ## Haz push solo a tu fork y pide permiso antes de escribir nada fuera Nunca envíes cambios al repositorio upstream autoritativo; envíalos únicamente al fork del contribuidor. No hagas force-push ni modifiques con amend confirmaciones que ya estén en el repositorio remoto, salvo que el usuario lo solicite explícitamente. Si la rama remota ha avanzado, ejecuta fetch y rebase antes de enviar los cambios. Obtén una aprobación explícita antes de realizar escrituras externas, como enviar confirmaciones, crear un pull request, crear un issue o publicar comentarios. Usa el cliente autenticado que admita el proyecto. Si no está disponible, prepara una URL de revisión o instrucciones de entrega precisas en vez de omitir el flujo de trabajo obligatorio. ## Usa el número de versión de la rama que publica el cambio primero Cuando el código necesite una anotación de versión, una versión de configuración o una exclusión de compatibilidad, usa la versión de la rama en la que el cambio se publique primero y elimina el sufijo snapshot. Para una revisión basada en una rama de mantenimiento, usa la versión de esa rama. Para una revisión basada en la rama principal, usa la versión de la rama de publicación más reciente cuando los cambios suelan trasladarse allí mediante backport. Usa la versión de la rama principal únicamente para trabajos exclusivos de ella, como un cambio incompatible o con incompatibilidad binaria, o una actualización de dependencias que no justifique un backport crítico. Si la ruta de publicación no está clara, pregunta en vez de deducirla únicamente a partir de la rama principal. ## Lee la política de seguridad del proyecto antes de informar de un problema de seguridad Antes de informar de un problema de seguridad, lee la política de seguridad y el modelo de amenazas del repositorio. Confirma el alcance declarado, los casos excluidos y los casos documentados que no se consideran hallazgos, para que el resultado de un escáner se evalúe con respecto a las garantías reales del proyecto. Mantén la investigación de seguridad separada de la clasificación ordinaria de errores, conserva las pruebas y no expongas credenciales ni datos locales confidenciales cuando documentes un hallazgo.