refatoração dos agents

agents/refatorar/rules/design-patterns-pragmatico

@@ -0,0 +1,70 @@
+---
+type: rule
+name: design-patterns-pragmatico
+description: Aplicar Design Patterns GoF apenas quando há problema concreto que o justifique
+scope: local
+trigger: context_match
+updatedAt: "2026-06-19"
+---
+
+# Regra: Design Patterns Pragmático
+
+## Contexto
+
+Os 22 Design Patterns GoF são soluções comprovadas para problemas recorrentes. Porém, aplicar um padrão sem problema concreto cria complexidade gratuita — o code smell "Generalidade Especulativa".
+
+## Regra
+
+**Antes de introduzir qualquer Design Pattern:**
+
+1. Identificar o **problema concreto** que existe agora (não no futuro hipotético)
+2. Nomear o **code smell** que o padrão resolve
+3. Avaliar se a **complexidade do padrão** é justificada pelo tamanho do problema
+4. Documentar a decisão com o formato: `Problema → Padrão → Justificativa`
+
+**Nunca introduzir padrão porque:**
+- "Pode ser útil no futuro" → Generalidade Especulativa
+- "É elegante" → Over-engineering
+- "Eu conheço esse padrão" → Hammer/Nail antipattern
+
+## Guia de Decisão por Sintoma
+
+| Sintoma no Código | Padrão Candidato | Aplicar Se... |
+|-------------------|------------------|---------------|
+| `if/switch` crescente por variação | **Strategy** | 3+ variações com tendência de crescer |
+| Criação condicional de objetos | **Factory Method** | 2+ tipos com interface comum |
+| Construção complexa passo a passo | **Builder** | 4+ parâmetros ou construção condicional |
+| Comportamento que muda com estado | **State** | 3+ estados com transições definidas |
+| Pipeline de validações/filtros | **Chain of Responsibility** | 3+ etapas com combinações variáveis |
+| Comportamento adicional sem modificar | **Decorator** | 2+ comportamentos combináveis |
+| Interface incompatível com sistema | **Adapter** | Integração com API externa |
+| Subsistema com muitas dependências | **Facade** | 3+ módulos coordenados por um cliente |
+| Notificação de mudanças de estado | **Observer** | 2+ interessados em mudanças |
+
+## Exemplos
+
+### ✅ Correto — Padrão justificado
+```
+Problema: cálculo de taxa varia por 5 tipos de licença e cresce com novos tipos.
+Code smell: switch crescente (violação Open/Closed).
+Padrão: Strategy via dispatch table.
+Justificativa: elimina switch, cada novo tipo é arquivo separado.
+```
+
+### ❌ Incorreto — Padrão especulativo
+```
+Problema: nenhum. Temos apenas 1 tipo de notificação.
+Padrão: Observer com EventEmitter customizado.
+Motivo: "talvez no futuro tenha mais tipos".
+Resultado: 4 arquivos novos para resolver 0 problemas.
+```
+
+## Impacto
+
+Padrões aplicados sem critério geram código mais complexo sem benefício proporcional, violando o princípio YAGNI (You Aren't Gonna Need It).
+
+## Referências
+
+- Alexander Shvets — "Mergulho nos Padrões de Projeto" (Refactoring.Guru)
+- GoF — "Design Patterns: Elements of Reusable Object-Oriented Software"
+- Persona: `agents/refatorar/persona`