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`

agents/refatorar/rules/refatoracao-segura

@@ -0,0 +1,56 @@
+---
+type: rule
+name: refatoracao-segura
+description: Toda refatoração deve preservar comportamento e ter cobertura de testes
+scope: local
+trigger: always_on
+updatedAt: "2026-06-19"
+---
+
+# Regra: Refatoração Segura
+
+## Contexto
+
+Refatoração é a melhoria da estrutura interna do código **sem alterar seu comportamento externo**. Sem essa garantia, refatoração vira regressão.
+
+## Regra
+
+Antes de executar qualquer refatoração, verificar:
+
+1. **Testes existem** — o comportamento que será afetado tem cobertura
+2. **Testes passam** — o estado antes da mudança é verde
+3. **Passos pequenos** — cada mudança deve ser verificável isoladamente
+4. **Sem surpresas** — nenhuma funcionalidade nova introduzida junto com refatoração
+
+Se não há testes cobrindo o trecho:
+- **PARAR** a refatoração
+- Solicitar ao `@testes` a criação de testes de cobertura
+- Só prosseguir após testes existirem e passarem
+
+## Exemplos
+
+### ✅ Correto
+```
+1. Verificar testes existentes para `calcularLicenca()`
+2. Executar testes → todos passam
+3. Extrair cálculo de multa para `calcularMulta()`
+4. Executar testes → todos passam
+5. Commit: "refactor: extrair calcularMulta de calcularLicenca"
+```
+
+### ❌ Incorreto
+```
+1. Refatorar `calcularLicenca()` inteiro
+2. Adicionar nova regra de desconto (feature!)
+3. Descobrir que não tinha testes
+4. Commit: "refactor: melhorar cálculos" ← mentira, é feature + refatoração
+```
+
+## Impacto
+
+Sem esta regra, refatorações introduzem regressões silenciosas que só são descobertas em produção.
+
+## Referências
+
+- Martin Fowler — "Refactoring: Improving the Design of Existing Code"
+- Persona: `agents/refatorar/persona`

agents/refatorar/rules/solid-compliance

@@ -0,0 +1,88 @@
+---
+type: rule
+name: solid-compliance
+description: Todo código deve aderir aos 5 princípios SOLID do Refactoring.Guru
+scope: local
+trigger: context_match
+updatedAt: "2026-06-19"
+---
+
+# Regra: Conformidade SOLID
+
+## Contexto
+
+Os princípios SOLID são o alicerce de software manutenível. Violações geram acoplamento, rigidez e fragilidade que crescem exponencialmente com o tempo.
+
+## Regra
+
+Ao analisar ou modificar código, verificar conformidade com cada princípio:
+
+### S — Responsabilidade Única
+
+- Cada arquivo tem uma única razão para mudar
+- Funções fazem uma única coisa
+- Composables encapsulam um único domínio de estado
+
+**Indicador de violação:** arquivo que precisa mudar quando regras de negócio **E** regras de apresentação mudam.
+
+### O — Aberto/Fechado
+
+- Novas funcionalidades adicionadas por extensão (novos arquivos), não por edição de existentes
+- Usar dispatch tables, strategy pattern ou plugins
+
+**Indicador de violação:** `if/else` ou `switch` que cresce a cada nova variação.
+
+### L — Substituição de Liskov
+
+- Subtipos podem ser usados onde o tipo base é esperado
+- Funções que aceitam um tipo base funcionam com qualquer subtipo
+
+**Indicador de violação:** `instanceof` ou type guards que verificam subtipos para mudar comportamento.
+
+### I — Segregação de Interface
+
+- Tipos/interfaces contêm apenas os membros que seus consumidores usam
+- Nenhum módulo é forçado a depender de métodos que não utiliza
+
+**Indicador de violação:** tipo com campos opcionais demais (`?`) que na prática são obrigatórios em alguns contextos.
+
+### D — Inversão de Dependência
+
+- Módulos de lógica de negócio não importam de módulos de infraestrutura diretamente
+- Dependência flui através de abstrações (interfaces, tipos, schemas Zod)
+
+**Indicador de violação:** serviço de negócio importando driver de banco ou cliente HTTP diretamente.
+
+## Exemplos
+
+### ✅ Correto — Princípio O (Aberto/Fechado)
+```ts
+// dispatch table: extensível sem editar código existente
+const calculadores: Record<TipoLicenca, CalculadorFn> = {
+  ambiental: calcularAmbiental,
+  sanitaria: calcularSanitaria,
+  // nova licença? adicionar aqui sem tocar nas funções existentes
+}
+```
+
+### ❌ Incorreto — Violação do Princípio S (Responsabilidade Única)
+```ts
+// arquivo que faz validação + cálculo + formatação + envio de email
+export function processarLicenca(dados: DadosLicenca) {
+  validar(dados)        // validação
+  const valor = calcular(dados)  // cálculo
+  const pdf = gerarPDF(valor)    // formatação
+  enviarEmail(pdf)      // notificação
+  // 4 razões para mudar = 4 responsabilidades
+}
+```
+
+## Impacto
+
+Código que viola SOLID se torna cada vez mais caro de manter: cada mudança exige mais esforço e introduz mais risco de regressão.
+
+## Referências
+
+- Robert C. Martin — "Agile Software Development, Principles, Patterns, and Practices"
+- Refactoring.Guru — https://refactoring.guru/pt-br/design-patterns
+- Persona: `agents/refatorar/persona`