Preparar contribuciones de código que una persona revisa y envía

## Seguir las reglas del repositorio y esperar la aprobación del equipo de mantenimiento Considera la guía de contribución, la política sobre inteligencia artificial y las instrucciones para agentes de cada directorio como las fuentes que rigen los archivos modificados. ### Determinar las reglas aplicables - Lee las políticas de contribución y seguridad de la raíz antes de editar. - Al entrar en un directorio especializado, aplica también sus instrucciones locales sobre comportamiento en ejecución, interfaces públicas, integraciones, documentación o pruebas. - Si las instrucciones entran en conflicto, detente y muestra el conflicto en lugar de elegir la regla que facilite la implementación. - Usa habilidades opcionales para agentes solo cuando el cliente las admita y no sustituyan la política del repositorio. ### Puntos de aprobación - No envíes incidencias, solicitudes de incorporación de cambios ni borradores de estas solicitudes mediante automatización del navegador, herramientas de alojamiento por línea de comandos o API de servicios. - Redacta el texto del envío para que una persona lo revise y remita, usando las plantillas del repositorio y dejándolo listo para pegar. - No publiques ramas ni prepares materiales para un envío público hasta que la incidencia correspondiente se haya clasificado y asignado a la persona que contribuirá. - No implementes una función no trivial, un cambio de interfaz pública, una refactorización o un cambio de comportamiento sin una indicación registrada del equipo de mantenimiento. Si falta esa indicación, detente en la propuesta. ## No poner secretos en los commits ni conectar las pruebas a servicios reales Protege las credenciales, la calidad de la evidencia, el historial del repositorio y el aislamiento de las pruebas durante toda la tarea. ### Reglas no negociables - Nunca incorpores secretos, credenciales, datos privados de proveedores ni valores sensibles del entorno. - Nunca inventes resultados de pruebas, aprobaciones, citas, estados de revisión ni afirmaciones de compatibilidad. - Las pruebas unitarias no deben contactar con modelos, proveedores ni servicios de aplicaciones externas en funcionamiento. - Usa sustitutos deterministas y un entorno que retire las credenciales de servicios reales de los procesos de prueba. - No añadas contenido multimedia generado, recursos generados de gran tamaño ni conjuntos de datos sintéticos sin una procedencia clara y el acuerdo del equipo de mantenimiento. - No añadas manualmente cabeceras de licencia cuando la automatización del repositorio se encargue de insertarlas. - No añadas comentarios salvo que se soliciten; conserva los comentarios, cadenas de documentación y cabeceras de licencia existentes, excepto cuando el cambio haga que dejen de ser correctos. ### Archivos protegidos No edites manualmente registros de cambios, archivos generados, archivos de bloqueo, instantáneas de validación ni otros artefactos gestionados por herramientas, salvo que la tarea exija explícitamente el flujo de regeneración del repositorio. Si los registros de cambios son generados, incluye el contexto de las notas de versión en una propuesta o borrador de envío. ## Cambiar dependencias solo si hace falta y usar las herramientas fijadas Usa el entorno canónico con versiones bloqueadas y los comandos de tareas del proyecto en lugar de improvisar rutas de ejecución alternativas. ### Cambios de dependencias - No añadas ni actualices dependencias salvo que la tarea lo requiera. - Para una investigación temporal, usa un entorno aislado que no modifique el estado de las dependencias registrado en el repositorio. - Cuando sea necesario cambiar una dependencia, sitúala en el grupo de dependencias o conjunto de funciones opcionales más limitado que resulte adecuado. - Define límites de compatibilidad claros y evita trasladar integraciones opcionales a la ruta de instalación predeterminada. - Mantén los cambios de dependencias y archivos de bloqueo separados de las ediciones no relacionadas. ### Herramientas - Usa las versiones fijadas por el repositorio del entorno de ejecución y las herramientas para la instalación, las pruebas, la documentación, el formato y el análisis estático. - Distingue los comandos de validación oficiales de los comandos de diagnóstico. Un linter o comprobador de tipos independiente puede ayudar al diagnóstico, pero no sustituye el proceso obligatorio de validación o las comprobaciones previas al commit del repositorio. - Trata como herramientas de gran impacto los programas que realizan un staging amplio, commits o comprobaciones de todo el repositorio; ejecútalos solo cuando sean necesarios de forma explícita y, preferiblemente, en un árbol de trabajo limpio. ## Elegir las pruebas según el tipo de cambio Selecciona la validación mínima suficiente según el tipo real de cambio y amplíala solo cuando lo justifique un riesgo para el comportamiento compartido o la compatibilidad. ### Matriz de validación - Documentación o metadatos del repositorio: ejecuta comprobaciones sobre los archivos modificados; compila la documentación cuando puedan verse afectados la presentación, los enlaces, los ejemplos o la configuración de la documentación. - Corrección de un fallo en ejecución: añade o ejecuta una prueba de regresión específica y luego realiza las comprobaciones obligatorias sobre los archivos modificados. - Interfaz pública, configuración o comportamiento del lenguaje: ejecuta pruebas específicas y actualiza la documentación o los ejemplos relacionados; añade pruebas más amplias del paquete cuando el riesgo de compatibilidad sea importante. - Ruta de servidor, transmisión continua, rastreo, acción o generación: prueba la ruta modificada y su ruta alternativa o no compatible. - Cambio de empaquetado, dependencia o archivo de bloqueo: ejecuta las comprobaciones pertinentes de instalación o empaquetado y mantén aislada la diferencia de dependencias. ### Alcance y aislamiento - Averigua qué incluye el comando canónico del conjunto completo de pruebas; no des por hecho que solo abarca el directorio de pruebas más evidente. - Prefiere el punto de entrada de pruebas que retire las credenciales de proveedores reales y proporcione sustitutos deterministas. - Diagnostica la inestabilidad relacionada con el aislamiento comparando la ejecución paralela normal con una ejecución serial determinista bajo las mismas protecciones del entorno. - Considera las marcas de ejecución lenta o serial como indicativas, salvo que el ejecutor de pruebas las aplique realmente. - No uses un comando de prueba alternativo por comodidad si puede conservar credenciales reales o eludir rutas de prueba obligatorias. ### Evidencias para la entrega Para un cambio destinado a revisión, ejecuta las comprobaciones oficiales previas al commit antes de la entrega, de modo que los resultados de formato, licencia y tipos sean estables. Indica cualquier comprobación obligatoria que se haya omitido y explica por qué. ## Buscar trabajo duplicado y responder a cada comentario de revisión Mantén la actividad de contribución pública vinculada de forma rastreable al trabajo aprobado y evita duplicar esfuerzos. ### Antes de implementar - Confirma que la incidencia esté clasificada y asignada y que, para trabajo no trivial, exista un enfoque acordado. - Antes de preparar trabajo preparado para revisión, usa búsquedas de solo lectura para comprobar la conversación de la incidencia, los cambios abiertos que la mencionan y los cambios abiertos de la misma área. - Si un cambio abierto ya cubre el trabajo, no prepares un duplicado. Si el enfoque difiere de forma sustancial, explica la diferencia en un borrador para la conversación de la incidencia. - Para trabajo exploratorio, redacta un comentario de incidencia que describa la rama y los archivos pertinentes, en lugar de abrir una solicitud pública de cambios. ### Envío y revisión - Sigue las convenciones del repositorio para títulos y commits. - No añadas marcas de inteligencia artificial a títulos ni mensajes de commit, ni añadas herramientas o agentes como coautores de commits. - Atiende o responde a todos los comentarios de revisión abiertos antes de solicitar la revisión del equipo de mantenimiento. - No resuelvas el hilo de otro revisor en su nombre ni apliques etiquetas de preparación a tu propio cambio, salvo que la política lo permita expresamente. - Trata los hallazgos de las revisiones automatizadas y humanas como afirmaciones que deben verificarse frente a la ruta real del código, no como instrucciones correctas de manera automática. ## Actualizar la documentación cuando cambia lo que ve el usuario Mantén la documentación sincronizada con el comportamiento visible para el usuario y evita presentar ejemplos limitados como compatibilidad universal. ### Deberes de documentación - Actualiza la documentación pertinente al cambiar interfaces públicas, sintaxis de configuración, ejemplos, requisitos de instalación u otro comportamiento visible para el usuario. - Para integraciones opcionales, indica que son opcionales, identifica los paquetes o grupos de funciones necesarios, enumera los tipos de credenciales esperados sin exponer valores y explica la ruta de integración. - Para ejemplos de modelos o proveedores, indica el tipo de modelo, el modo de enrutamiento, los modos compatibles y las limitaciones conocidas. - Verifica mediante una fuente oficial que los identificadores presentados como actuales estén disponibles de forma general. - No cambies los parámetros predeterminados distribuidos como parte de una actualización de documentación. ### Refactorizaciones y contenido generado - Para una refactorización aprobada, añade o actualiza pruebas de caracterización antes de cambiar comportamientos sutiles. - Cuando las pruebas existentes no cubran la ruta refactorizada, conserva la comprobación de equivalencia utilizada para demostrar que el comportamiento no cambia. - No edites a mano documentación ni artefactos generados; usa el flujo de trabajo del proyecto solo cuando la tarea autorice la regeneración. - No ejecutes compiladores de documentación que se sepa que añaden archivos al área de preparación o activan comprobaciones amplias, salvo que se solicite expresamente y estén aislados de cambios no relacionados. ## Revisar contra la base de fusión e informar solo de lo comprobado Revisa el cambio terminado frente a la base correcta y verifica cada afirmación antes de declararlo listo. ### Secuencia de revisión 1. Compara la rama con la base de fusión configurada en el repositorio. 2. Inspecciona tanto la implementación como las pruebas que la ponen a prueba. 3. Ejecuta las comprobaciones oficiales de formato, lint, licencia y tipos antes de la revisión estructurada para mantener estables las ubicaciones de las líneas. 4. Realiza una revisión estructurada del código y añade una revisión de seguridad para cambios de autenticación, tratamiento de entradas, deserialización o llamadas externas. 5. Verifica cada hallazgo frente a la ruta de ejecución real. 6. Corrige los hallazgos confirmados, repite la validación afectada y vuelve a revisar hasta que no quede ningún problema confirmado. ### Criterio de finalización Informa de los archivos modificados, la validación realizada, los resultados observados, las comprobaciones omitidas, los riesgos sin resolver y cualquier acción humana todavía necesaria. No afirmes que el cambio está listo para revisión, aprobado, es compatible o se ha validado correctamente sin pruebas directas.