@girardelli/architect 2.2.0 → 4.0.0

package/__test_agent_output__/templates/C4.md

@@ -0,0 +1,68 @@
+# 🏗️ 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:
+- User.Entity: Entidade de negócio
+- User: Entidade de negócio
+
+Sistemas Externos:
+- [sistema 1]: [como interage]
+- [sistema 2]: [como interage]
+
+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: entity
+├── Controller: [Controllers] — Expõe endpoints REST
+├── Service: [Services] — Lógica de negócio
+├── Entity: User — 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_app.Service {
+  // GET /app.
+  handlelist_app.(req: Request): Promise<Response>;
+}
+```
+
+---
+
+## Decisões Arquiteturais
+
+Se a decisão é significativa → criar ADR separado (ver template ADR).

package/__test_agent_output__/templates/TDD.md

@@ -0,0 +1,86 @@
+# 🔬 Template: TDD — Test-Driven Development
+
+> RED → GREEN → REFACTOR. Nesta ordem. Sempre.
+
+---
+
+## Estrutura de Testes (jest)
+
+```typescript
+describe('entity', () => {
+
+  describe('create', () => {
+
+    // ── Happy Path ──
+    it('should create entity 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 /app. correctly', async () => {
+    // Arrange
+    const endpoint = '/app.';
+
+    // 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/__test_agent_output__/templates/THREAT-MODEL.md

@@ -0,0 +1,82 @@
+# 🛡️ Template: Threat Model (STRIDE)
+
+> Use para features que lidam com dados sensíveis, pagamentos, autenticação.
+
+---
+
+## Feature: Acesso a Histórico Médico
+
+### Atores e Assets
+
+| Ator | Nível de Confiança | Assets que Acessa |
+|------|-------------------|------------------|
+| Paciente | Alto | Histórico médico, exames, receitas |
+| Médico | Alto | Prontuário do paciente |
+| Farmacêutico | Médio | Prescrições, alergias |
+| Auditor Compliance | Médio | Logs de acesso, consentimento |
+
+---
+
+### 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 |
+|------|-------------|----------|
+| Nome Paciente | PII | Criptografado, HIPAA compliant |
+| Histórico Médico | Saúde | AES-256, acesso restrito |
+| Medicamentos | Saúde | Criptografado, masking em logs |
+| Resultado de Exames | Saúde | Criptografado, assinado digitalmente |
+
+---
+
+### Conformidade e Requisitos Regulatórios
+
+| Regulamento | Aplicável | Verificação |
+|-------------|-----------|-------------|
+| HIPAA | Sim | PHI encryption at rest and in transit |
+| LGPD-Health | Sim | Explicit consent for health data processing |
+
+---
+
+### 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
+```
+
+
+---
+
+## Ameaças Específicas de Healthtech
+
+| Ameaça | Descrição | Mitigação |
+|--------|-----------|-----------|
+| Acesso não Autorizado | Outro médico lê prontuário | RBAC por especialidade, audit |
+| Adulteração de Histórico | Alterar resultado de exame | Blockchain/assinatura digital |
+| Vazamento de Dados | Exposição de histórico médico | Criptografia, isolamento de rede |
+| Negação de Diagnóstico | Paciente nega consentimento | Digital signature + timestamp |
+| Indisponibilidade | Sistema cai durante consulta | Backup em tempo real, SLA 99.95% |
+| Privilégio Elevado | Admin lê dados de qualquer paciente | Segregação de funções, logging |

package/__test_agent_output__/workflows/fix-bug.md

@@ -0,0 +1,228 @@
+---
+antigravity:
+  trigger: 'on_demand'
+  description: 'Workflow completo para correção de bug em test-project'
+---
+
+# 🐛 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: 72/100 · 2026-03-25**