Envía solicitudes de incorporación hechas por IA a un framework de código abierto con revisión humana

## Marca el trabajo de la IA y haz push solo a ramas creadas por el agente Trata las escrituras externas, la propiedad de incidencias, las ramas y la atribución como acciones controladas. - Identifica claramente como generadas por IA las descripciones de solicitudes de incorporación, los comentarios de revisión y los comentarios en incidencias, y nombra al operador humano cuando el proyecto lo exija. - Determina la identidad del operador o autor mediante una fuente autenticada. Nunca la adivines; si la consulta falla, omite el nombre. - Añade el pie de coautoría de IA requerido a los commits asistidos por IA. - Cuando ese sea el límite del proyecto, no abras más de 10 solicitudes de incorporación al día por operador; prioriza unos pocos cambios completos y bien probados. - Trabaja únicamente en incidencias aptas y sin asignar. Asigna la incidencia al operador y pásala al estado activo antes de implementar. - Envía cambios solo a una rama creada por el agente. No envíes cambios a la rama de un colaborador sin permiso explícito. - Prefiere una bifurcación personal a llenar el repositorio principal de ramas sin limpiar, usa un nombre de rama útil que incluya el tema y el identificador de la incidencia, y retira la rama tras su fusión o rechazo. Mantén actualizados los metadatos de la solicitud de incorporación. Después de cada envío, actualiza el título y la descripción para que sigan describiendo correctamente el conjunto completo de cambios. ## Lee el historial del código y los tickets anteriores antes de cambiar código No supongas que un código que parece incorrecto es defectuoso. Los sistemas longevos suelen incorporar restricciones anteriores que no son visibles en la implementación actual. 1. Reproduce y valida el problema notificado; cuestiona los supuestos incompletos o equivocados. 2. Examina el historial del archivo y los datos de autoría por línea; después, lee los mensajes de commit pertinentes y las incidencias vinculadas para entender por qué existe el código. 3. Busca incidencias relacionadas para encontrar enfoques rechazados, discusiones anteriores y decisiones intencionadas. 4. Lee los documentos de diseño del área afectada, especialmente los relativos a seguridad, telemetría, contexto de registro y contratos públicos de nombres. 5. Si un módulo sustituyó a otro, distingue los cambios intencionados de las omisiones accidentales. 6. Si la corrección propuesta revierte un cambio intencionado anterior, detente y reconsidera. Si la reversión sigue estando justificada, explica por qué a pesar de la razón original. Antes de implementar, presenta al operador los hallazgos, riesgos, ambigüedades y la posible invalidez del problema. Aplica el mismo rigor al revisar una solicitud de incorporación. Verifica mediante fuentes autorizadas las versiones, publicaciones y comportamientos actuales de las dependencias externas. Nunca hagas afirmaciones concluyentes sobre proyectos externos cambiantes basándote únicamente en el conocimiento de entrenamiento del modelo. ## Cambia las pausas fijas de los tests por esperas con tiempo límite Nunca uses pausas de duración fija en los tests. Los vuelven lentos, inestables y no deterministas. - Si un componente ofrece aserciones temporizadas nativas, úsalas para las condiciones que ya puede representar. - Usa una utilidad de espera asíncrona para otras condiciones, como esperar un recuento intermedio antes de la siguiente acción. - No envuelvas una aserción bloqueante nativa con una utilidad de sondeo; eso añade sondeos redundantes alrededor de un pestillo existente. - Establece siempre un tiempo de espera máximo explícito al usar una utilidad de espera. - Usa una condición con aserción o un predicado claro; nunca un bucle de espera activa. - Al modificar un test que contenga una pausa fija, migra a la aserción temporizada nativa o a la utilidad de espera general. Por ejemplo, `MockEndpoint.assertIsSatisfied()` ya espera internamente, mientras que Awaitility es adecuado para condiciones que `MockEndpoint` no puede expresar. Los tests nuevos no deben introducir `Thread.sleep()`. ## Decide en quién se confía y comunica las vulnerabilidades en privado Usa el modelo de amenazas canónico del proyecto para decidir en quién confiar, dónde están los límites de confianza y qué pertenece al marco. - Considera de confianza a los autores del código y a los operadores de despliegue cuando configuren intencionadamente rutas ejecutables, expresiones, secretos, exposición de red y parámetros de ejecución. - Considera no fiables a los remitentes externos de mensajes y a todos los datos que circulen por una ruta de confianza. - El propio marco no debe transformar datos no fiables en ejecución de código, lectura de archivos, falsificación de solicitudes o elusión de autorizaciones. - La ejecución intencionada de código por un autor de confianza, una configuración incorrecta del operador y un comportamiento peligroso habilitado mediante inclusión voluntaria explícita no son por sí solos vulnerabilidades del marco. Los hallazgos válidos demuestran una infracción del límite de confianza en una configuración predeterminada o razonablemente esperada. Las clases habituales incluyen deserialización insegura, XXE, inyección de expresiones, recorrido de rutas, SSRF, abuso del despacho mediante cabeceras, elusión de autenticación o autorización, divulgación de secretos, valores predeterminados inseguros e inyección en consultas construidas por el marco. El agotamiento de recursos sin los controles requeridos, las superficies de administración expuestas deliberadamente, los hallazgos en dependencias transitivas inalcanzables y los resultados de escáner sin prueba de una infracción del límite suelen quedar fuera del ámbito del marco. Nunca divulgues una posible vulnerabilidad mediante una incidencia pública, una solicitud de incorporación, una lista de correo u otro canal público. Sigue el proceso de notificación privada y detén el trabajo público. ## Bloquea los datos entrantes no fiables y deja desactivados los ajustes de seguridad riesgosos Revisa cada consumidor, analizador, formato de datos, conversor de tipos, almacén de agregación y opción de seguridad frente a vías de abuso concretas. - Filtra las cabeceras internas del marco de los mensajes entrantes no fiables con una estrategia estricta que no distinga mayúsculas de minúsculas antes del despacho. - No deserialices objetos no fiables sin un filtro de entrada adecuado. - Marca los secretos como metadatos secretos y clasifica los conmutadores de configuración inseguros por su familia de riesgo. - Mantén denegados los valores predeterminados sensibles para la seguridad, salvo que se habiliten explícitamente. Relajar un valor predeterminado requiere una nota de actualización y la aprobación explícita de un mantenedor. - Verifica que las opciones de autenticación y autorización apliquen el emisor, la audiencia, la firma y cada subruta anunciada que afirman proteger. En los despliegues, usa el perfil de seguridad de producción, resuelve secretos mediante una bóveda aprobada, configura TLS verificado, deshabilita la serialización insegura en consumidores no fiables y mantén las consolas de gestión y la administración del entorno de ejecución en redes de confianza. La revisión de seguridad debe distinguir el comportamiento de una ruta de confianza del comportamiento del marco y, a la vez, impedir que los datos no fiables crucen el límite. ## Añade tests y documentación a cada cambio y confirma los archivos generados Cada función o corrección de errores debe incluir tests adecuados y documentación para el usuario. Documenta en la guía pertinente los valores predeterminados modificados, el comportamiento de descubrimiento, las opciones renombradas o retiradas, los cambios de cabeceras, los cambios de API o SPI, las obsolescencias y las migraciones. - Ejecuta para la superficie modificada las comprobaciones canónicas del repositorio de formato, orden de importación, estilo, tests unitarios, tests de integración y código fuente. - Regenera los artefactos generados e inclúyelos en un commit; no dejes que CI sea quien descubra por primera vez los cambios generados. - Evita introducir nuevos defectos de análisis estático, regresiones de mantenibilidad, patrones de debilidad comunes y API obsoletas, aunque una validación local no ejecute todos los analizadores. - Importa las clases y usa nombres simples en lugar de nombres de clase totalmente cualificados, salvo cuando dos clases compartan el mismo nombre simple. Conserva las exclusiones explícitas del código generado. - Añade la etiqueta de versión de introducción requerida a cada tipo y método nuevos de la API pública, usa la versión de la próxima publicación y colócala después de las demás etiquetas de documentación. - Actualiza todos los registros de metadatos que descubran extensiones anidadas; un directorio de código fuente no garantiza por sí solo que una extensión sea visible para las compilaciones, los catálogos o la documentación generada. - En los contenedores de tests de integración, verifica todas las arquitecturas compatibles. Usa un espejo de registro aprobado o exclusiones explícitas por arquitectura cuando no exista una imagen. - Usa referencias internas para las páginas internas y verifica los anclajes entre versiones frente al destino publicado, no solo frente a la rama de desarrollo. Al marcar una función como obsoleta, actualiza conjuntamente los metadatos de compilación, las anotaciones de API, el título de la documentación y la guía de actualización. ## Pide dos revisores y una aprobación humana antes de fusionar Solicita revisión solo cuando la solicitud de incorporación esté lista, nunca mientras sea un borrador. - Identifica a los mantenedores activos pertinentes mediante el historial reciente de archivos y los datos de autoría, y solicita la revisión de al menos 2 revisores adecuados. - Después de resolver todos los comentarios y recuperar el estado correcto de las comprobaciones, vuelve a solicitar la revisión de los revisores existentes. - Nunca fusiones mientras quede sin resolver alguna conversación de revisión. - Exige al menos 1 aprobación humana y nunca apruebes la propia solicitud de incorporación del agente. - Deriva el hito de publicación de la rama de destino y establece tanto el hito como la versión de corrección de la incidencia antes de cerrarla. - Determina mediante programación el autor de la solicitud de incorporación, asigna correctamente la solicitud y la incidencia, y aplica la etiqueta de categoría respaldada por la incidencia y el cambio. - Coloca la publicación y la fusión detrás de una única cadena de comprobaciones superadas de formato, tipos, lint, tests y seguridad. - Conserva la coautoría de IA requerida en el commit final de fusión. - Después de la fusión, resuelve la incidencia con la versión de corrección y un enlace a la solicitud de incorporación, y retira la rama. Resume el comportamiento visible para el usuario, la validación significativa, el impacto sobre la documentación, el riesgo sin resolver y cualquier comprobación que no haya podido ejecutarse. Un test local no demuestra que CI haya concluido correctamente y una evidencia incompleta no justifica afirmar que todo está listo para publicar.