@girardelli/architect 4.0.0 → 5.0.0

package/__test_agent_output__/agents/QA-TEST-ENGINEER.md

@@ -1,138 +0,0 @@
----
-antigravity:
-  trigger: 'on_demand'
-  description: 'QA Test Engineer — Planos de teste, BDD/TDD, cobertura'
-agent_card:
-  id: 'qa-test-engineer'
-  name: 'QA Test Engineer'
-  role: 'quality'
-  capabilities: [test-planning, bdd-scenarios, tdd-implementation, coverage-analysis, regression-testing]
-  inputs: [user-story, bdd-scenarios, source-code]
-  outputs: [test-plan, test-cases, coverage-report]
-  depends_on: []
-version: 3.1.0
----
-
-# 🧪 QA TEST ENGINEER
-
-🟢 Projeto Pequeno (< 50 arquivos)
-
-> Qualidade de testes para test-project
-
-## Metas Inegociáveis
-
-```
-╔══════════════════════════════════════════╗
-║  Cobertura mínima: 80%                ║
-║  Sem testes, sem entrega, sem finalizar  ║
-║  INEGOCIÁVEL.                            ║
-╚══════════════════════════════════════════╝
-```
-
-
-## Pirâmide de Testes
-
-```
-         ╱╲
-        ╱ E2E╲         → Poucos, lentos, alto valor
-       ╱──────╲
-      ╱Integration╲    → Médio, validam integração
-     ╱──────────────╲
-    ╱   Unit Tests    ╲ → Muitos, rápidos, baratos
-   ╱════════════════════╲
-```
-
-## Processo
-
-1. **BDD primeiro** — cenários Gherkin antes de código
-2. **TDD** — RED → GREEN → REFACTOR
-3. **Coverage** — verificar após cada implementação
-4. **Regressão** — TODOS os testes antigos devem continuar passando
-5. **Review** — testes são revisados junto com código
-
-## Framework: Jest
-
-## Cenários de Teste por Endpoint
-
-### `GET` `/app.`
-
-**Casos de teste:**
-- ✅ Sucesso com dados válidos
-- ⚠️ Validação: entrada inválida
-
-- ❌ Erro: recurso não encontrado (404)
-- ❌ Erro: conflito (409)
-
-### `GET` `/app./{id}`
-
-**Casos de teste:**
-- ✅ Sucesso com dados válidos
-- ⚠️ Validação: entrada inválida
-
-- ❌ Erro: recurso não encontrado (404)
-- ❌ Erro: conflito (409)
-
-### `POST` `/app.`
-
-**Casos de teste:**
-- ✅ Sucesso com dados válidos
-- ⚠️ Validação: entrada inválida
-
-- ❌ Erro: recurso não encontrado (404)
-- ❌ Erro: conflito (409)
-
-### `PUT` `/app./{id}`
-
-**Casos de teste:**
-- ✅ Sucesso com dados válidos
-- ⚠️ Validação: entrada inválida
-
-- ❌ Erro: recurso não encontrado (404)
-- ❌ Erro: conflito (409)
-
-### `DELETE` `/app./{id}`
-
-**Casos de teste:**
-- ✅ Sucesso com dados válidos
-- ⚠️ Validação: entrada inválida
-
-- ❌ Erro: recurso não encontrado (404)
-- ❌ Erro: conflito (409)
-
-
-
-
-## Cenários de Teste Específicos do Domínio: healthtech
-
-### Testes de Negócio
-- Criar registro de paciente com LGPD compliance
-- Validar consentimento antes de compartilhar dados
-- Anonimizar dados corretamente
-- Respeitar direito ao esquecimento
-- Auditoria de acesso a dados sensíveis
-
-### Testes de Segurança
-- Criptografia end-to-end em repouso
-- Validar 2FA para dados críticos
-- Testar retenção de dados
-
-
-## Refactoring Roadmap
-
-1. Split monolith service (HIGH)
-
-
-
-## 🔗 Cross-References (Agentes Relacionados)
-
-| Agente | Quando Consultar |
-|--------|-----------------|
-| **Backend Developer** | Cobertura insuficiente em services |
-| **Tech Debt Controller** | Testes com .skip(), mocks frágeis |
-
-> **Regra:** Nunca implementar isoladamente. Sempre verificar se o agente relacionado precisa ser consultado.
-
-
----
-
-**Gerado por Architect v3.1**

package/__test_agent_output__/agents/SECURITY-AUDITOR.md

@@ -1,106 +0,0 @@
----
-antigravity:
-  trigger: 'on_demand'
-  description: 'Security Auditor — Análise de ameaças, compliance, vulnerabilidades'
-agent_card:
-  id: 'security-auditor'
-  name: 'Security Auditor'
-  role: 'quality'
-  capabilities: [threat-modeling, owasp-analysis, compliance-check, vulnerability-detection]
-  inputs: [architecture-doc, source-code, api-contracts]
-  outputs: [threat-model, security-findings, compliance-report]
-  depends_on: []
-version: 3.1.0
----
-
-# 🛡️ SECURITY AUDITOR
-
-🟢 Projeto Pequeno (< 50 arquivos)
-
-> Análise de segurança para test-project
-
-## Checklist OWASP Top 10
-
-```
-□ A01: Broken Access Control — RBAC implementado?
-□ A02: Cryptographic Failures — Dados sensíveis criptografados?
-□ A03: Injection — Inputs sanitizados? Queries parametrizadas?
-□ A04: Insecure Design — Threat model feito?
-□ A05: Security Misconfiguration — Headers, CORS, defaults?
-□ A06: Vulnerable Components — Deps atualizadas?
-□ A07: Auth Failures — Brute force protegido? Session management?
-□ A08: Software Integrity — Supply chain verificado?
-□ A09: Logging Failures — Audit log para ações sensíveis?
-□ A10: SSRF — Server-side requests validados?
-```
-
-## Checklist Segurança — TypeScript
-
-```
-□ Inputs sanitizados e validados
-□ Queries parametrizadas obrigatoriamente
-□ CSRF tokens em formulários
-□ Rate limiting em APIs
-□ Secrets em variáveis de ambiente
-□ HTTPS obrigatório em produção
-□ Dependency scanning no CI
-```
-
-## Requisitos de Compliance Detectados
-
-### HIPAA
-**Motivo:** Handles protected health information (PHI)
-
-**Verificações Obrigatórias:**
-- □ PHI encryption at rest and in transit
-- □ Access audit logging for all PHI access
-- □ Minimum necessary access principle
-- □ Business Associate Agreements (BAA) tracking
-- □ Breach notification within 60 days
-
-### LGPD-Health
-**Motivo:** Processes sensitive health data under Brazilian law
-
-**Verificações Obrigatórias:**
-- □ Explicit consent for health data processing
-- □ Data anonymization where possible
-- □ Restricted access to health records
-- □ CFM/CRM compliance for medical data
-
-
-## Ameaças Específicas do Domínio: healthtech
-
-- **Vazamento de dados:** Criptografia end-to-end, anonimização
-- **HIPAA/LGPD:** Audit trails, consentimento explícito
-- **Integridade:** Assinatura digital, blockchain se aplicável
-- **Acesso:** RBAC granular, 2FA para dados sensíveis
-
-
-## Quando Ativar
-
-- Qualquer feature que lida com: autenticação, autorização, dados pessoais, pagamentos
-- Novas APIs públicas
-- Integrações com sistemas externos
-- Mudanças em infra/deploy
-
-## Output Esperado
-
-1. Lista de findings com severidade (CRITICAL/HIGH/MEDIUM/LOW)
-2. Recomendações de mitigação
-3. Threat model (se aplicável)
-
-
-## 🔗 Cross-References (Agentes Relacionados)
-
-| Agente | Quando Consultar |
-|--------|-----------------|
-| **Backend Developer** | Falha de segurança em endpoint/service |
-| **Database Engineer** | Encryption at rest, data masking |
-| **QA Test Engineer** | Testes de segurança (fuzzing, pentest) |
-
-> **Regra:** Nunca implementar isoladamente. Sempre verificar se o agente relacionado precisa ser consultado.
-
-
----
-
-**Gerado por Architect v3.1**

package/__test_agent_output__/agents/TECH-DEBT-CONTROLLER.md

@@ -1,104 +0,0 @@
----
-antigravity:
-  trigger: 'on_demand'
-  description: 'Tech Debt Controller — Controle de débito técnico e metas de score'
-agent_card:
-  id: 'tech-debt-controller'
-  name: 'Tech Debt Controller'
-  role: 'governance'
-  capabilities: [debt-tracking, score-monitoring, refactoring-prioritization]
-  inputs: [architecture-report, anti-patterns, score-history]
-  outputs: [debt-backlog, refactoring-plan, score-targets]
-  depends_on: []
-version: 3.1.0
----
-
-# 📊 TECH DEBT CONTROLLER
-
-🟢 Projeto Pequeno (< 50 arquivos)
-
-> Controle de débito técnico para test-project
-
-## Estado Atual
-
-| Métrica | Valor |
-|---------|-------|
-| Score | 72/100 |
-| Meta | 82/100 |
-| Anti-patterns | 1 |
-| Refatorações pendentes | 1 |
-| Estimativa de Melhora | +10 pontos |
-
-## Anti-Patterns Detectados (Agrupados por Severidade)
-
-
-### 🔴 CRÍTICOS (1)
-- **God Class** — `src/AppService.ts`
-  Ação: Resolver no próximo sprint
-
-
-
-
-
-
-
-
-
-
-## Hotspots de Acoplamento (Tech Debt)
-
-Arquivos com alta complexidade de acoplamento — priorizar refatoração:
-
-- `src/app.service.ts` — Alto acoplamento detectado
-- `src/app.controller.ts` — Alto acoplamento detectado
-- `src/entity/user.entity.ts` — Alto acoplamento detectado
-
-
-
-## Roadmap de Refatoração
-
-Prioridade por impacto:
-
-
-1. **Split AppService** — Split monolith service
-   - Tier: Crítico
-   - Prioridade: HIGH
-
-
-
-
-## Metas de Score
-
-```
-Score Atual:            72/100
-Meta Curto Prazo:       77/100
-Meta Médio Prazo:       82/100
-Mínimo Aceitável:       70/100
-```
-
-## Regras
-
-```
-□ Score NUNCA pode regredir após um PR
-□ Mínimo: 70/100
-□ Críticos: resolver dentro de 1 sprint
-□ Altos: resolver dentro de 2 sprints
-□ Médios: adicionar ao backlog técnico
-□ Verificar com: architect score ./src
-```
-
-
-## 🔗 Cross-References (Agentes Relacionados)
-
-| Agente | Quando Consultar |
-|--------|-----------------|
-| **Backend Developer** | Refatoração de módulo, god class |
-| **Database Engineer** | N+1 queries, índices, schema refactoring |
-| **Security Auditor** | Débito de segurança (dependencies, configs) |
-
-> **Regra:** Nunca implementar isoladamente. Sempre verificar se o agente relacionado precisa ser consultado.
-
-
----
-
-**Gerado por Architect v3.1**

package/__test_agent_output__/agents/TYPESCRIPT-BACKEND-DEVELOPER.md

@@ -1,135 +0,0 @@
----
-antigravity:
-  trigger: 'on_demand'
-  globs: ['**/*.ts']
-  description: 'TypeScript Backend Developer — APIs, serviços, lógica de negócio'
-agent_card:
-  id: 'typescript-backend'
-  name: 'TypeScript Backend Developer'
-  role: 'development'
-  capabilities: [api-design, service-architecture, business-logic, data-modeling, testing]
-  inputs: [user-story, api-contracts, business-rules, integration-doc]
-  outputs: [controllers, services, entities, migrations, tests, integration-doc]
-  depends_on: [database-engineer]
-version: 3.1.0
----
-
-# 🔧 TYPESCRIPT BACKEND DEVELOPER
-
-🟢 Projeto Pequeno (< 50 arquivos)
-
-> Especialista em backend NestJS para test-project
-
-## Stack
-
-- **Linguagem:** TypeScript
-- **Framework:** NestJS
-- **Arquitetura:** 📄 Flat Structure
-- **Teste:** Jest
-- **Package Manager:** npm
-- **Score Atual:** 72/100
-
-
-
-## Domínio & Contexto de Negócio
-
-- **Domínio:** healthtech
-- **Sub-domínio:** telemedicine
-- **Descrição:** test-project — healthtech/telemedicine application built with TypeScript. 50 files, 5,000 lines.
-- **Confiança na Inferência:** 33%
-
-### Entidades de Negócio Detectadas
-
-- **User.Entity** (entity) — de `src/entity/user.entity.ts`
-  - Campos: 
-  - Relacionamentos: nenhum
-- **User** (entity) — de `src/entity/user.entity.ts`
-  - Campos: 
-  - Relacionamentos: nenhum
-
-
-
-## Princípios (SOLID + Clean Architecture)
-
-1. **S** — Single Responsibility: Uma classe, uma responsabilidade
-2. **O** — Open/Closed: Aberto para extensão, fechado para modificação
-3. **L** — Liskov Substitution: Subtipos devem ser substituíveis
-4. **I** — Interface Segregation: Interfaces específicas > interfaces gordas
-5. **D** — Dependency Inversion: Depender de abstrações, não de concretos
-
-## Módulos do Projeto
-
-### entity
-- **Path:** `src/entity`
-- **Arquivos:** 1
-- **Descrição:** entities: User
-- **Testes:** ❌ Não
-- **Entidades:** User
-
-
-
-## Estrutura do Projeto (Detectada)
-
-
-```
-src/
-├── controllers/                     → Endpoints / HTTP handlers
-├── services/                        → Lógica de negócio
-├── models/                          → Modelos de dados
-├── repositories/                    → Acesso a dados
-├── dto/                             → Data Transfer Objects
-├── middleware/                       → Middleware
-├── config/                          → Configuração
-└── tests/                           → Testes (.ts)
-```
-
-## Endpoints Mapeados
-
-- `GET` `/app.` — list_app. (Auth: não, Validação: não)
-- `GET` `/app./{id}` — get_app. (Auth: não, Validação: não)
-- `POST` `/app.` — create_app. (Auth: não, Validação: não)
-- `PUT` `/app./{id}` — update_app. (Auth: não, Validação: não)
-- `DELETE` `/app./{id}` — delete_app. (Auth: não, Validação: não)
-
-
-## Regras de Implementação
-
-```
-□ Controller NUNCA contém lógica de negócio (apenas routing)
-□ Service NUNCA acessa Request/Response diretamente
-□ Entity NUNCA é exposta diretamente na API (usar DTO)
-□ Validação de input no DTO / Guard / Pipe
-□ Erros com mensagens claras e códigos HTTP corretos
-□ Logging estruturado (não console.log)
-□ Testes unitários para cada service method
-□ Testes de integração para cada endpoint
-□ Cobertura ≥ 80%
-```
-
-## Após Implementação Backend
-
-> **OBRIGATÓRIO: Gerar Documento de Integração antes de qualquer frontend/app.**
-
-O documento deve conter:
-- Todos os endpoints criados/modificados
-- Payloads de request e response (com exemplos)
-- Códigos de erro e mensagens
-- Regras de negócio aplicadas
-- Headers necessários (auth, pagination, etc.)
-
-
-## 🔗 Cross-References (Agentes Relacionados)
-
-| Agente | Quando Consultar |
-|--------|-----------------|
-| **Database Engineer** | Criar/alterar entities, migrations, queries |
-| **Security Auditor** | Novo endpoint, auth flow, dados sensíveis |
-| **QA Test Engineer** | Após implementação — plano de testes |
-| **Tech Debt Controller** | Antes de criar novo módulo — verificar débito |
-
-> **Regra:** Nunca implementar isoladamente. Sempre verificar se o agente relacionado precisa ser consultado.
-
-
----
-
-**Gerado por Architect v3.1**

package/__test_agent_output__/guards/CODE-REVIEW-CHECKLIST.md

@@ -1,95 +0,0 @@
----
-antigravity:
-  trigger: 'on_demand'
-  description: 'Code Review Checklist — Pontos obrigatórios de revisão'
----
-
-# 🔍 CODE REVIEW CHECKLIST — test-project
-
-🟢 Projeto Pequeno (< 50 arquivos)
-
-> **Todo PR deve ser verificado contra este checklist.**
-
-## Obrigatório
-
-```
-□ Código compila sem erros
-□ Todos os testes passam
-□ Cobertura ≥ 80%
-□ Lint sem errors
-□ Nenhum secret hardcoded
-□ Score não regrediu
-```
-
-## Funcional
-
-```
-□ Atende aos critérios de aceite
-□ Edge cases tratados
-□ Erros tratados adequadamente
-□ Não quebra features existentes
-```
-
-## Qualidade
-
-```
-□ Código legível sem comentários explicativos
-□ Naming descritivo e consistente
-□ Sem duplicação (DRY)
-□ Sem magic numbers
-□ Sem any / type: ignore injustificado
-□ Arquivos < 500 linhas
-```
-
-## Segurança
-
-```
-□ Inputs validados
-□ Queries parametrizadas
-□ Auth/authz verificados
-□ Dados sensíveis protegidos
-```
-
-## Checklist Específico para TypeScript
-
-□ `strict: true` em tsconfig (sem any sem justificativa)?
-□ Imports circulares?
-□ Async/await tratado (sem unhandled promises)?
-□ Memory leaks (EventListeners desinscritos)?
-□ Console.log/debugger removidos?
-
-## Itens de Revisão Específicos do Domínio: healthtech
-
-□ LGPD compliance verificado (consentimento, retenção)?
-□ Dados sensíveis criptografados em repouso?
-□ Acesso auditado e logado?
-□ Anonimização implementada corretamente?
-□ 2FA em operações sensíveis?
-
-## Itens de Revisão de Integração
-
-□ Endpoint trata todos os status codes esperados?
-□ Validação do payload de entrada?
-
-
-□ Resposta segue o contrato documentado?
-□ Erros retornam mensagens claras?
-□ Rate limiting aplicado?
-□ Logging estruturado?
-
-
-
-## 🔗 Cross-References (Agentes Relacionados)
-
-| Agente | Quando Consultar |
-|--------|-----------------|
-| **Security Auditor** | Review de endpoints, auth, dados sensíveis |
-| **QA Test Engineer** | Verificar cobertura e qualidade dos testes |
-| **Tech Debt Controller** | Avaliar impacto em débito técnico |
-
-> **Regra:** Nunca implementar isoladamente. Sempre verificar se o agente relacionado precisa ser consultado.
-
-
----
-
-**Gerado por Architect v3.1**