Auditoría de CI y pruebas de REA
Establece qué verificaciones aún detectan regresiones reales y qué costos se pueden eliminar sin perder esa protección. El resultado puede ser una corrección verificada, una recomendación respaldada por evidencia o una decisión explícita de detenerse.
Sigue el AGENTS.md del checkout, la guía de pruebas y las reglas de contribución. Usa sus comandos actuales y la cadena de herramientas fijada, en lugar de comandos recordados de una auditoría anterior. Preserva el alcance solicitado: la investigación por sí sola no autoriza ediciones; esta skill no otorga permiso para publicar issues, hacer push o merge. La autorización existente del usuario sigue aplicando. Mantén las notas de auditoría y los resultados sin procesar fuera del árbol rastreado, normalmente en un directorio /tmp específico de la tarea.
Establecer la línea base ejecutada
Obtén cuando el usuario solicite la última versión de main. Fija el SHA de la línea base y la revisión del flujo de trabajo inspeccionado; usa un worktree aislado al cambiar o comparar código. No modifiques el checkout de otra tarea. Registra los cambios sucios y el comando exacto, cadena de herramientas, host, pruebas seleccionadas, instrumentación y requisitos previos. Una ejecución anterior es evidencia para su revisión ejecutada, incluso si main avanza.
Traza los disparadores del flujo de trabajo, la selección de rutas modificadas, las dependencias de trabajos, las acciones reutilizables, los scripts de paquete, el descubrimiento de pruebas, los productores de artefactos y las puertas de informe hasta los comandos que realmente se ejecutan. Incluye scripts, datos generados, registro en tiempo de ejecución y límites de subprocesos que faltan en los gráficos de importación. Verifica las rutas de selección positivas y negativas: los archivos requeridos deben descubrirse una vez por configuración de prueba prevista; las repeticiones deliberadas de plataforma/configuración son cobertura separada. Una prueba explícita faltante o un informe requerido faltante no deben volverse verdes. Los carriles opcionales pueden saltarse; conserva sus requisitos previos declarados.
Usa los artefactos de temporización y fallos existentes para seleccionar familias sospechosas. Ejecuta las verificaciones relevantes para establecer una línea base; reserva una suite local completa para un diagnóstico amplio de CI o incertidumbre que las verificaciones enfocadas no puedan resolver. No reconstruyas ni vuelvas a ejecutar una suite completa sin cambios después de cada edición de documentación.
Probar el fallo o la protección
Para cada candidato, indica el comportamiento observable esperado y su propietario, luego construye la reproducción más pequeña contra el comportamiento de producción. Sigue al productor y a los consumidores afectados antes de decidir dónde corregirlo.
- Para desviación, compara los fixtures con los requisitos de admisión actuales, respuestas de protocolo, contratos nombrados, versiones de herramientas y puntos de entrada públicos reales. Un mock de apariencia plausible puede fallar antes del comportamiento que su prueba afirma cubrir. Busca en toda la familia de fixtures afectada, incluidas otras cadenas de versión. Conserva los fixtures intencionalmente malformados y prueba su rechazo previsto.
- Para una prueba verde sospechosa, perturba el comportamiento relevante en una copia aislada o inyecta un fallo controlado. Verifica que la aserción o compuerta existente lo detecte. Una prueba puede simplemente repetir su mock, importar código abandonado u ocultar un fallo de subproceso/verificador. Restaura las mutaciones después del experimento.
- Para configuración compartida o poda, asigna aserciones distintas a sus escenarios retenidos. Conserva entradas malformadas, cancelación, fallo de limpieza, permisos, capacidad, identidad e interacciones de concurrencia significativas. Una ejecución más rápida que salta un caso o debilita su oráculo no es una mejora.
- Para cobertura de proveedor, separa la evidencia de productor falso, límite y motor real. Inspecciona los saltos y requisitos previos nombrados; los fixtures no establecen el comportamiento real de Ghidra, LLDB, navegador u otro proveedor.
Clasifica los hallazgos como defectos reproducidos, costos admitidos, hipótesis o evidencia no disponible. Registra el comando de línea base, salida observada/estado de salida, resultado esperado, alcance afectado y explicación alternativa. Un fallo en main puede ser preexistente; eso por sí solo no lo hace irrelevante para una auditoría de CI. Atribuye los fallos de PR usando la revisión ejecutada y una línea base limpia, no solo su parecido con un fallo anterior. Reintenta solo para probar una explicación transitoria específica; conserva el fallo original y detente cuando la repetición no agregue evidencia. Un reintento exitoso no establece una causa raíz ni una corrección.
Evaluar la eficiencia sin perder la compuerta
Lee medición y verificaciones de CI al investigar lentitud, almacenamiento en caché, esperas de runner, artefactos compartidos o ruido de registros. Compara el trabajo completado equivalente antes de reclamar una aceleración. Distingue el tiempo de configuración/compilación, ejecución de pruebas, instrumentación de cobertura, esperas de dependencias y programación de runner; indica qué costos permanecen sin medir.
Prefiere eliminar la preparación duplicada probada, reutilizar la configuración inmutable y reducir el trabajo repetido de subprocesos antes de reducir la cobertura de corrección. Conserva las sesiones independientes donde el ciclo de vida o la concurrencia es el oráculo. Mantén las pruebas en vivo frescas; un pase previo en caché no puede validar el host actual, el contenido del proveedor instalado, los permisos o el estado externo.
Arreglar, verificar y entregar dentro del alcance
Si la implementación está autorizada, haz el cambio estructural más pequeño en el límite de propiedad y agrega una regresión que falle en la línea base por la razón correcta. Vuelve a probar los consumidores afectados y las rutas negativas significativas; verifica la invalidación de caché o el descubrimiento cuando esos mecanismos cambien. Lee la documentación instalada de Turbo antes de cambiar su configuración o comandos.
Ejecuta las verificaciones aplicables del repositorio e inspecciona los resultados completos de CI de la cabeza actual antes de una fusión autorizada. Conserva la cobertura requerida y las compuertas de descubrimiento. No suprimas un fallo, agregues reintentos generales, aumentes tiempos de espera ni elimines aserciones distintas únicamente para que el CI se vuelva verde. Los cambios en estos controles necesitan su propia razón demostrada y detección de fallos retenida.
Informa cada problema confirmado con la revisión exacta, reproducción, consecuencia, corrección propuesta y límites de validación. Informa el rendimiento con la carga de trabajo y las mediciones, no solo un porcentaje. Usa registros de issues/PR en inglés cuando se solicite; sigue las preferencias de asignación, identidad de commit, revisión y fusión del usuario sin asumirlas para otros usuarios. Abre PRs listos para revisión solo cuando ese ciclo de vida esté autorizado. Resuelve los hallazgos de revisión necesarios y verifica el main final contra el árbol probado después de la fusión.
Detente cuando el trabajo autorizado esté verificado, los beneficios restantes no estén probados o más cambios intercambiarían corrección por velocidad especulativa. Enumera las incertidumbres genuinas sin convertirlas en rondas de optimización adicionales.