Fluxo de Trabalho de Desenvolvimento Laravel

Faça o comportamento solicitado do Laravel correto, mantenível dentro da aplicação existente e suportado por evidências que correspondam ao risco da mudança.

Quando Usar

• Use ao implementar um recurso em uma aplicação Laravel existente.
• Use ao diagnosticar e corrigir um bug do Laravel em sua causa raiz acionável.
• Use quando uma mudança no Laravel precisar de cobertura de regressão e verificação proporcional.
• Use quando o projeto já possui convenções arquiteturais ou de teste que devem ser preservadas.

Estabeleça o Contrato

Antes de editar:

• Leia as instruções do repositório e inspecione as rotas, modelos, controladores, ações ou serviços, requisições, políticas, jobs, eventos, testes e schema relevantes.
• Rastreie o comportamento atual o suficiente para identificar o limite real da mudança e as convenções existentes.
• Transforme a solicitação em um conjunto compacto de cenários, casos extremos importantes e critérios de aceitação verificáveis. Mantenha essa análise nas notas de trabalho, a menos que o usuário solicite um artefato separado.
• Identifique preocupações de autorização, validação, transação, fila, cache e concorrência apenas onde elas podem afetar esse comportamento.

Ajuste a análise à tarefa. Uma correção de validação focada não precisa da mesma cerimônia que um novo fluxo de trabalho multi-papel.

Corrija Bugs na Causa

Para um bug:

1. Reproduza a falha pelo caminho confiável mais estreito.
2. Rastreie o fluxo de dados e controle até a causa raiz acionável.
3. Adicione ou atualize um teste de regressão que falhe por essa causa, quando prático.
4. Implemente a menor correção que restaure o invariante pretendido.
5. Demonstre que o teste de regressão passa e que o comportamento próximo ainda funciona.

Não substitua retentativas, tratamento amplo de exceções, validação desativada, timeouts extras ou supressão de erros por uma correção de causa raiz. Se a falha não puder ser reproduzida localmente, declare quais evidências estão faltando e use a verificação estática ou direcionada mais forte disponível.

Construa Recursos na Forma Existente

• Reutilize os padrões e a nomenclatura estabelecidos da aplicação.
• Mantenha as regras de negócio na camada onde este código já coloca regras comparáveis.
• Use relacionamentos Eloquent, requisições de formulário, políticas, ações, serviços, eventos ou jobs quando eles melhorarem essa mudança ou corresponderem às convenções locais — não como uma cerimônia obrigatória.
• Trate a autorização e a validação como comportamento explícito na fronteira do sistema.
• Preserve a compatibilidade retroativa, a menos que a solicitação exija uma mudança que quebre a compatibilidade.
• Mantenha as migrações reversíveis e seguras para os motores de banco de dados suportados pela aplicação.

Crie factories, seeders, fixtures ou um comando descartável apenas quando dados realistas forem necessários para desenvolvimento ou cobertura de teste durável. Não deixe andaimes únicos no produto apenas para exercitar uma pequena mudança.

Verifique Proporcionalmente

Descubra os comandos suportados pelo projeto a partir de sua configuração e documentação. Prefira esta ordem:

1. Execute o teste afetado mais estreito ou reproduza a falha original.
2. Execute o grupo de testes de funcionalidade, unidade ou integração relevante.
3. Execute a análise estática, formatação e linting configurados pelo repositório.
4. Execute a suíte mais ampla quando o alcance da mudança ou a política do projeto justificar.

Cubra o comportamento observável crítico, incluindo o caminho feliz e quaisquer casos extremos, regras de validação, permissões, efeitos de banco de dados, eventos, notificações, jobs ou contratos de API que sejam realmente afetados. Evite testes que apenas espelham detalhes de implementação.

Comandos comuns podem incluir:

php artisan test --filter=RelevantTest
vendor/bin/pest --filter=RelevantTest
vendor/bin/phpstan analyse
vendor/bin/pint --dirty

Use os comandos que o projeto fornece; não instale ou configure ferramentas apenas porque elas aparecem neste exemplo.

Preserve o Ambiente do Usuário

• Mantenha a mudança dentro do comportamento solicitado da aplicação e preserve as mudanças não relacionadas no diretório de trabalho.
• Não execute operações destrutivas de banco de dados, comandos de produção, implantações, alterações de credenciais ou ações de conta externa, a menos que as instruções do usuário ou do repositório as coloquem explicitamente no escopo.
• Evite expor segredos em comandos, logs, saída de teste ou evidências de conclusão.
• Prefira verificação local, reversível e alterações de dados com foco estreito.

Evidência de Conclusão

Antes de entregar, verifique cada critério de aceitação em relação ao comportamento atual. Relate:

• o que mudou e por que corrige ou implementa o comportamento solicitado;

…