@girardelli/architect 6.0.0 → 8.1.0

package/.agent/templates/ADR.md

@@ -1,95 +0,0 @@
-# 📋 Template: ADR — Architecture Decision Record
-
-> Use quando uma decisão técnica é significativa ou controversa.
-
----
-
-## ADR-001: Uso de Backend Framework para Backend
-
-**Status:** proposed | accepted | deprecated | superseded by ADR-YYY
-**Data:** YYYY-MM-DD
-**Autores:** [quem participou da decisão]
-
----
-
-### Contexto
-
-> Qual é o problema ou necessidade que levou a esta decisão?
-
-O projeto requer uma API REST escalável com TypeScript. Precisamos escolher um framework que:
-- Suporte TypeScript nativo
-- Tenha decorators e dependency injection
-- Tenha comunidade ativa e documentação excelente
-
----
-
-### Decisão
-
-> O que foi decidido?
-
-Decidimos usar Backend Framework como framework backend principal. Backend Framework oferece:
-- Arquitetura modular built-in
-- Decorators para roteamento e middleware
-- Injeção de dependência nativa
-- Suporte a bancos de dados (TypeORM, Prisma, etc.)
-
----
-
-### Alternativas Consideradas
-
-| # | Alternativa | Prós | Contras | Por que descartada |
-|---|-----------|------|---------|-------------------|
-| 1 | Express.js + middleware customizado | [prós] | [contras] | [motivo] |
-| 2 | Fastify | [prós] | [contras] | [motivo] |
-
----
-
-### Consequências
-
-**Positivas:**
-- Arquitetura clara e escalável
-- Código mais organizado e testável
-- Comunidade ativa para suporte
-
-**Negativas:**
-- Curva de aprendizado para novos desenvolvedores
-- Overhead de dependências
-
-**Riscos:**
-- Atualização de versões major — probabilidade: média
-
----
-
-### Notas
-
-- Revisar em 6 meses se a decisão continua válida
-
-
----
-
-## ADR-002: Banco de Dados PostgreSQL
-
-**Status:** accepted
-**Data:** 2024-01-15
-**Autores:** [equipe técnica]
-
-### Contexto
-
-Precisamos escolher um banco de dados relacional que:
-- Suporte transações ACID
-- Tenha integração com Backend Framework
-- Permita escalabilidade horizontal
-
-### Decisão
-
-Escolhemos PostgreSQL como banco de dados principal por:
-- Suporte a JSON nativo
-- Excelente performance em leitura/escrita
-- Integração com TypeORM/Prisma é padrão
-
-### Alternativas Consideradas
-
-| # | Alternativa | Prós | Contras |
-|---|-----------|------|---------|
-| 1 | MySQL | Popular, estável | Menos recursos avançados |
-| 2 | MongoDB | Escalável | Sem ACID nativo, schema dinâmico |

package/.agent/templates/BDD.md

@@ -1,57 +0,0 @@
-# 🧪 Template: BDD — Behavior-Driven Development
-
-> Um cenário para cada critério de aceite + cenários de erro + edge cases.
-
----
-
-## Feature: [Nome da Feature]
-
-```gherkin
-Feature: [Nome da Feature]
-  Como usuário,
-  Quero interagir com o sistema,
-  Para alcançar meu objetivo de negócio.
-
-  # ── Happy Path ──
-
-  Scenario: [cenário principal - sucesso]
-    Given [contexto / pré-condição]
-    And [contexto adicional, se necessário]
-    When [ação do usuário]
-    Then [resultado esperado]
-    And [efeito colateral, se houver]
-
-  # ── Validações ──
-
-  Scenario: Validação de dados obrigatórios
-    Given um formulário de criação
-    When o usuário tenta enviar sem preencher campos obrigatórios
-    Then mensagens de erro são exibidas para cada campo
-
-  # ── Edge Cases ──
-
-  Scenario: Lidar com valores boundary
-    Given o sistema aceita valores de 0 a 999999.99
-    When o usuário tenta inserir um valor fora do range
-    Then um erro de validação é retornado
-
-  # ── Permissões ──
-
-  Scenario: [cenário de acesso negado]
-    Given [usuário sem permissão]
-    When [tenta acessar recurso]
-    Then [resposta 403 / redirect]
-```
-
----
-
-## Checklist
-
-```
-□ Cada critério de aceite tem ≥ 1 cenário
-□ Happy path coberto
-□ Error paths cobertos
-□ Edge cases cobertos
-□ Permissões/autenticação cobertos
-□ Cenários são independentes entre si
-```

package/.agent/templates/C4.md

@@ -1,67 +0,0 @@
-# 🏗️ Template: Arquitetura C4
-
-> Preencher os 4 níveis relevantes para a feature/mudança.
-
----
-
-## Nível 1 — Contexto
-
-> Visão de pássaro: quem são os atores e sistemas envolvidos?
-
-```
-Atores:
-- [ator 1]: [descrição do papel]
-- [ator 2]: [descrição do papel]
-
-Sistemas Externos:
-- AWS S3 (storage): Integração de negócio
-
-Fluxo de dados:
-[ator] → [sistema] → [nosso sistema] → [resposta]
-```
-
----
-
-## Nível 2 — Container
-
-> Quais serviços, apps, bancos de dados são tocados?
-
-```
-┌──────────────┐    ┌──────────────┐    ┌──────────────┐
-│   [Frontend] │───▶│   Backend    │───▶│   [Database] │
-└──────────────┘    └──────────────┘    └──────────────┘
-```
-
----
-
-## Nível 3 — Componente
-
-> Quais módulos, classes, serviços são criados ou modificados?
-
-```
-Módulo: agent-generator
-├── Controller: src/core/agent-generator/enrichers/endpoint-extractor.ts, src/core/agent-generator/enrichers/endpoint-extractor.js — Expõe endpoints REST
-├── Service: [Services] — Lógica de negócio
-├── Entity: [Entities] — Persistência de dados
-├── DTO: [Request/Response]
-└── Tests: Pendentes
-```
-
----
-
-## Nível 4 — Código (se complexo)
-
-> Interfaces, tipos, contratos. Apenas para decisões complexas.
-
-```typescript
-interface Ilist_endpointextractorService {
-  // GET /endpointextractor
-  handlelist_endpointextractor(req: Request): Promise<Response>;
-}
-```
-
----
-
-## Decisões Arquiteturais
-
-Se a decisão é significativa → criar ADR separado (ver template ADR).

package/.agent/templates/TDD.md

@@ -1,86 +0,0 @@
-# 🔬 Template: TDD — Test-Driven Development
-
-> RED → GREEN → REFACTOR. Nesta ordem. Sempre.
-
----
-
-## Estrutura de Testes (jest)
-
-```typescript
-describe('agent-generator', () => {
-
-  describe('create', () => {
-
-    // ── Happy Path ──
-    it('should create agent-generator successfully', () => {
-      // Arrange
-      const input = { name: 'Test Entity' };
-
-      // Act
-      const result = service.create(input);
-
-      // Assert
-      expect(result).toBeDefined();
-      expect(result.name).toBe('Test Entity');
-    });
-
-    // ── Error Path ──
-    it('should throw [erro] when [condição inválida]', () => {
-      // Arrange
-      const invalidInput = undefined;
-
-      // Act & Assert
-      expect(() => service.create(invalidInput)).toThrow(Error);
-    });
-
-    // ── Boundary ──
-    it('should handle empty input', () => {
-      // Arrange
-      const boundaryInput = {};
-
-      // Act
-      const result = service.create(boundaryInput);
-
-      // Assert
-      expect(result).toBeDefined();
-    });
-
-  it('should get /endpointextractor correctly', async () => {
-    // Arrange
-    const endpoint = '/endpointextractor';
-
-    // Act
-    const response = await request(app).get(endpoint);
-
-    // Assert
-    expect(response.status).toBe(200);
-  });
-  });
-});
-```
-
----
-
-## Ciclo TDD
-
-```
-1. RED:    Escrever teste que FALHA
-2. GREEN:  Escrever código MÍNIMO para passar
-3. REFACTOR: Melhorar sem quebrar testes
-4. REPEAT
-```
-
----
-
-## Checklist
-
-```
-□ Teste escrito ANTES do código
-□ Teste falha antes da implementação (RED)
-□ Implementação mínima para passar (GREEN)
-□ Refatoração sem quebrar testes (REFACTOR)
-□ Happy path coberto
-□ Error path coberto
-□ Boundary cases cobertos
-□ Cobertura atinge o mínimo do projeto
-```

package/.agent/templates/THREAT-MODEL.md

@@ -1,63 +0,0 @@
-# 🛡️ Template: Threat Model (STRIDE)
-
-> Use para features que lidam com dados sensíveis, pagamentos, autenticação.
-
----
-
-## Feature: [Nome]
-
-### Atores e Assets
-
-| Ator | Nível de Confiança | Assets que Acessa |
-|------|-------------------|------------------|
-| [ator 1] | [alto/médio/baixo] | [dados/recursos] |
-
----
-
-### Análise STRIDE
-
-| Categoria | Ameaça | Probabilidade | Impacto | Mitigação |
-|-----------|--------|-------------|---------|-----------|
-| **S**poofing | Identidade falsa / autenticação fraca | M | A | MFA, JWT assinado, validação gov |
-| **T**ampering | Alteração de dados em trânsito/repouso | M | A | HTTPS, assinatura digital, checksums |
-| **R**epudiation | Negar ação realizada | M | A | Audit log detalhado com timestamp |
-| **I**nformation Disclosure | Vazamento de dados sensíveis | A | A | Criptografia AES-256, LGPD compliance |
-| **D**enial of Service | Serviço indisponível (DDoS, travamento) | M | A | Rate limiting, WAF, scaling automático |
-| **E**levation of Privilege | Escalar permissão (user → admin) | M | A | RBAC granular, segregação de funções |
-
----
-
-### Dados Sensíveis
-
-| Dado | Classificação | Proteção |
-|------|-------------|----------|
-| [dado 1] | PII / Financeiro / Auth | [como proteger] |
-
----
-
-### Conformidade e Requisitos Regulatórios
-
-| Regulamento | Aplicável | Verificação |
-|-------------|-----------|-------------|
-| LGPD (dados pessoais) | Depende | Consentimento, direito ao esquecimento |
-| Conformidade de Dados | Depende | Criptografia, HTTPS, audit logs |
-
----
-
-### Checklist de Segurança
-
-```
-□ Input validado e sanitizado
-□ Output encodado (XSS prevention)
-□ Queries parametrizadas (SQL injection)
-□ Autenticação obrigatória (MFA quando sensível)
-□ Autorização por role/permission (RBAC)
-□ Dados sensíveis criptografados at rest (AES-256)
-□ Dados sensíveis criptografados in transit (TLS 1.2+)
-□ Rate limiting implementado
-□ Audit log para ações sensíveis (timestamp + usuário)
-□ Secrets em variáveis de ambiente (não hardcoded)
-□ Consentimento e transparência (LGPD/GDPR)
-□ Testes de penetração agendados
-```
-

package/.agent/workflows/fix-bug.md

@@ -1,228 +0,0 @@
----
-antigravity:
-  trigger: 'on_demand'
-  description: 'Workflow completo para correção de bug em @girardelli/architect'
----
-
-# 🐛 Workflow: Fix Bug
-
-> **Bugs não se corrigem por tentativa e erro.**
-> Diagnóstico rigoroso → reprodução → root cause → teste RED → fix → regressão.
-
----
-
-## Pré-requisitos
-
-```
-□ Li INDEX.md e PREFLIGHT.md
-□ Li LESSONS-LEARNED.md (se existir) — talvez esse bug já aconteceu
-□ Li ERROR-PATTERNS.md (se existir) — talvez é um padrão conhecido
-□ Estou em uma branch fix/ ou hotfix/ (NUNCA main/develop)
-□ Build e testes passando ANTES da minha alteração
-```
-
----
-
-## Step 1: Diagnóstico Inicial
-
-```
-Bug: [descrição clara do problema]
-Reportado por: [quem reportou]
-Ambiente: [produção / staging / dev]
-Severidade: [CRITICAL / HIGH / MEDIUM / LOW]
-
-Comportamento atual: [o que acontece]
-Comportamento esperado: [o que deveria acontecer]
-Como reproduzir:
-  1. [passo 1]
-  2. [passo 2]
-  3. [resultado errado]
-```
-
----
-
-## Step 2: Leitura de Contexto
-
-```bash
-# Verificar LESSONS-LEARNED para bugs similares
-grep -i "[termo do bug]" LESSONS-LEARNED.md 2>/dev/null
-
-# Verificar ERROR-PATTERNS
-grep -i "[termo do bug]" ERROR-PATTERNS.md 2>/dev/null
-
-# Verificar regras de negócio relevantes
-grep -i "[domínio do bug]" BUSINESS-RULES.md 2>/dev/null
-
-# Histórico de commits na área afetada
-git log --oneline -20 -- [arquivo ou diretório afetado]
-```
-
----
-
-## Step 3: Localização do Problema
-
-```bash
-# Buscar no código
-grep -rn "[termo do erro]" --include="*.ts" src/
-
-# Verificar logs (se disponível)
-# Verificar stack trace
-
-# Mapear o fluxo de dados:
-# Input → [onde entra] → [como transforma] → [onde sai] → Output
-```
-
-```
-Arquivo(s) suspeito(s): _______________
-Função/método suspeito: _______________
-Linha(s) suspeita(s): _______________
-```
-
----
-
-## Step 4: Root Cause — Identificação da Causa Raiz
-
-```
-╔══════════════════════════════════════════════╗
-║  NUNCA corrigir o SINTOMA.                   ║
-║  SEMPRE encontrar a CAUSA RAIZ.              ║
-║                                               ║
-║  Técnica dos 5 Porquês:                      ║
-║  1. Por que o bug acontece? → porque...      ║
-║  2. Por que isso? → porque...                ║
-║  3. Por que isso? → porque...                ║
-║  4. Por que isso? → porque...                ║
-║  5. Por que isso? → CAUSA RAIZ               ║
-╚══════════════════════════════════════════════╝
-```
-
-```
-Causa raiz: _______________
-Confiança: [ ] Alta (reproduzi) [ ] Média (hipótese forte) [ ] Baixa (preciso investigar mais)
-```
-
-> **Se confiança é Baixa → PARAR e investigar mais. Não chutar.**
-
----
-
-## Step 5: Verificar Testes Existentes
-
-```bash
-# Testes que cobrem a área afetada
-grep -rn "[nome da função/classe]" --include="*.test.*" --include="*.spec.*" tests/ src/
-
-# Rodar testes existentes
-npx jest --testPathPattern="[modulo]"
-```
-
-```
-□ Existem testes para a área afetada? [sim/não]
-□ Os testes passam? [sim/não]
-□ Os testes cobrem o cenário do bug? [sim/não — se não, criar no Step 6]
-```
-
----
-
-## Step 6: Criar Teste RED
-
-> **PRIMEIRO criar um teste que FALHA reproduzindo o bug.**
-> Só depois corrigir o código.
-
-```
-Teste: [nome descritivo do teste]
-Input: [dados que reproduzem o bug]
-Expected: [resultado correto]
-Actual: [resultado errado — o teste deve FALHAR]
-```
-
-```bash
-# Rodar e confirmar que FALHA (RED)
-npx jest --testNamePattern="[nome do teste]"
-# DEVE FALHAR ❌
-```
-
----
-
-## Step 7: Correção Mínima
-
-```
-╔══════════════════════════════════════════════╗
-║  REGRA: Correção MÍNIMA.                     ║
-║                                               ║
-║  ✓ Corrigir APENAS a causa raiz              ║
-║  ✓ Menor quantidade de linhas possível       ║
-║  ✗ NÃO refatorar código adjacente            ║
-║  ✗ NÃO "aproveitar" para melhorar outra coisa║
-║  ✗ NÃO adicionar features junto com o fix    ║
-╚══════════════════════════════════════════════╝
-```
-
-Após corrigir:
-```bash
-# Rodar o teste do Step 6 — agora deve PASSAR (GREEN)
-npx jest --testNamePattern="[nome do teste]"
-# DEVE PASSAR ✅
-```
-
----
-
-## Step 8: Teste de Regressão
-
-```bash
-# Rodar TODOS os testes (não só o novo)
-npm run test
-
-# Build completo
-npm run build
-
-# Score
-npx @girardelli/architect score .
-```
-
-```
-□ Teste do bug passa (GREEN) ✓
-□ TODOS os outros testes passam ✓
-□ Build compila ✓
-□ Score não regrediu ✓
-```
-
----
-
-## Step 9: Verificação de Fluxos Existentes
-
-```
-□ Verifiquei que features dependentes não foram afetadas
-□ Verifiquei edge cases relacionados
-□ Se o bug era em API → verifiquei clientes da API
-□ Se o bug era em banco → verifiquei migrations e seeds
-```
-
----
-
-## Step 10: Documentação
-
-```
-□ Atualizar LESSONS-LEARNED.md:
-  - O que aconteceu
-  - Causa raiz
-  - Como foi corrigido
-  - Como prevenir no futuro
-
-□ Atualizar ERROR-PATTERNS.md (se é um padrão novo):
-  - Padrão do erro
-  - Sintomas
-  - Solução
-
-□ Commit com mensagem semântica:
-  fix: [descrição clara do que foi corrigido]
-
-□ PR criado com:
-  - Descrição do bug
-  - Causa raiz
-  - Solução aplicada
-  - Testes adicionados
-```
-
----
-
-**Gerado por Architect v3.1 · Score: 94/100 · 2026-03-30**