@maestro-ai/mcp-server 1.0.0 → 1.1.0

package/dist/content/content/prompts/seguranca/threat-modeling.md

@@ -1,224 +0,0 @@
-# Prompt: Threat Modeling (Modelagem de Ameaças)
-
-> **Quando usar**: No início do projeto, antes de implementar funcionalidades críticas
-> **Especialista**: [Segurança da Informação](../../02-especialistas/Especialista%20em%20Segurança%20da%20Informação.md)
-> **Nível**: Médio a Complexo
-
----
-
-## Fluxo de Contexto
-
-Antes de usar este prompt, tenha em mãos:
-- `docs/CONTEXTO.md` - Entendimento do projeto
-- `docs/05-arquitetura/arquitetura.md` - Arquitetura do sistema
-- Lista de ativos valiosos do sistema
-
-Após gerar, salve o resultado em:
-- `docs/09-seguranca/threat-model.md`
-
----
-
-## Prompt Completo
-
-```text
-Atue como especialista em segurança de aplicações focado em modelagem de ameaças (Threat Modeling).
-
-## Contexto do Projeto
-
-[COLE O CONTEÚDO DE docs/CONTEXTO.md]
-
-## Arquitetura do Sistema
-
-[DESCREVA OU COLE A ARQUITETURA - inclua diagrama se disponível]
-
-## Ativos de Valor
-
-Liste os ativos mais importantes do sistema:
-- Dados: [ex: dados de clientes, transações financeiras, credenciais]
-- Funcionalidades: [ex: autenticação, processamento de pagamentos]
-- Infraestrutura: [ex: banco de dados, APIs externas]
-
-## Atores e Usuários
-
-- Usuários legítimos: [tipos de usuários do sistema]
-- Potenciais atacantes: [internos? externos? concorrentes?]
-- Nível de sofisticação esperado: [script kiddies, APT?]
-
-## Compliance e Contexto de Risco
-
-- Indústria: [fintech, saúde, e-commerce, etc]
-- Regulamentações: [LGPD, PCI-DSS, HIPAA]
-- Tolerância a risco: [baixa/média/alta]
-
----
-
-## Sua Missão
-
-Realize uma modelagem de ameaças completa usando STRIDE:
-
-### 1. Decomposição do Sistema
-
-Identifique e documente:
-
-#### Pontos de Entrada
-| ID | Ponto de Entrada | Descrição | Nível de Confiança |
-|----|------------------|-----------|---------------------|
-| E1 | [ex: API REST] | [descrição] | [Público/Autenticado/Admin] |
-
-#### Ativos e Dados
-| ID | Ativo | Sensibilidade | Localização |
-|----|-------|---------------|-------------|
-| A1 | [ex: Dados de usuário] | [Alta/Média/Baixa] | [onde está armazenado] |
-
-#### Superfície de Ataque
-| Componente | Exposição | Criticidade |
-|------------|-----------|-------------|
-| [ex: API pública] | [Internet/Interna] | [Alta/Média/Baixa] |
-
-### 2. Análise STRIDE
-
-Para cada componente crítico, analise:
-
-#### Spoofing (Falsificação de identidade)
-- [ ] Como um atacante pode fingir ser outro usuário?
-- Vetores identificados:
-- Controles existentes:
-- Recomendações:
-
-#### Tampering (Adulteração)
-- [ ] Como dados podem ser modificados indevidamente?
-- Vetores identificados:
-- Controles existentes:
-- Recomendações:
-
-#### Repudiation (Repúdio)
-- [ ] Ações podem ser negadas por ausência de logs?
-- Vetores identificados:
-- Controles existentes:
-- Recomendações:
-
-#### Information Disclosure (Vazamento)
-- [ ] Como dados sensíveis podem vazar?
-- Vetores identificados:
-- Controles existentes:
-- Recomendações:
-
-#### Denial of Service (Negação de serviço)
-- [ ] Como o sistema pode ser derrubado?
-- Vetores identificados:
-- Controles existentes:
-- Recomendações:
-
-#### Elevation of Privilege (Escalação)
-- [ ] Como um usuário pode obter mais permissões?
-- Vetores identificados:
-- Controles existentes:
-- Recomendações:
-
-### 3. Diagrama de Fluxo de Dados (DFD)
-
-Crie um DFD mostrando:
-- Processos (círculos)
-- Data stores (cilindros)
-- Entidades externas (retângulos)
-- Fluxos de dados (setas com labels)
-- Trust boundaries (linhas tracejadas)
-
-### 4. Matriz de Riscos
-
-| ID | Ameaça | STRIDE | Probabilidade | Impacto | Risco | Mitigação |
-|----|--------|--------|---------------|---------|-------|-----------|
-| T1 | [descrição] | [S/T/R/I/D/E] | [1-5] | [1-5] | [P*I] | [ação] |
-
-### 5. Árvore de Ataque (para ameaças críticas)
-
-Para as top 3 ameaças, detalhe:
-```
-[Objetivo do atacante]
-├── Método 1
-│   ├── Pré-condição
-│   └── Passos
-├── Método 2
-│   ├── Pré-condição
-│   └── Passos
-```
-
-### 6. Plano de Mitigação Priorizado
-
-| Prioridade | Ameaça | Mitigação | Esforço | Owner |
-|------------|--------|-----------|---------|-------|
-| ⭐⭐⭐ | [T1] | [ação] | [dias] | [time] |
-| ⭐⭐ | [T2] | [ação] | [dias] | [time] |
-```
-
----
-
-## Exemplo de Uso
-
-```text
-Atue como especialista em segurança de aplicações focado em modelagem de ameaças.
-
-## Contexto do Projeto
-
-Marketplace de produtos artesanais. Vendedores cadastram produtos, compradores compram via cartão ou PIX.
-
-## Arquitetura do Sistema
-
-- Frontend: React SPA
-- Backend: Node.js + Express
-- Banco: PostgreSQL
-- Pagamentos: API do Stripe
-- Storage: S3 para imagens
-
-## Ativos de Valor
-
-- Dados: credenciais de usuário, dados de cartão (tokenizados), endereços de entrega
-- Funcionalidades: checkout, gestão de pedidos
-- Infraestrutura: banco de dados, integração Stripe
-
-## Atores
-
-- Usuários legítimos: compradores, vendedores, admins
-- Potenciais atacantes: externos (fraude), vendedores mal-intencionados
-- Sofisticação: média (script kiddies a semi-profissionais)
-
-## Compliance
-
-- LGPD (dados pessoais brasileiros)
-- PCI-DSS compliance via Stripe
-- Tolerância a risco: baixa (envolve dinheiro)
-```
-
----
-
-## Resposta Esperada (Resumo)
-
-### Top 5 Ameaças Identificadas
-
-| ID | Ameaça | Categoria | Risco |
-|----|--------|-----------|-------|
-| T1 | Vendedor fraudulento cria produtos falsos | Spoofing | 20 (Alto) |
-| T2 | Vazamento de dados de clientes via API | Info Disclosure | 16 (Alto) |
-| T3 | Manipulação de preço no checkout | Tampering | 12 (Médio) |
-| T4 | DDoS na API de checkout | DoS | 10 (Médio) |
-| T5 | Admin comprometido escala privilégios | Elevation | 8 (Médio) |
-
-### Mitigações Prioritárias
-
-1. **Validação de vendedor** - KYC básico antes de permitir vendas
-2. **Rate limiting + WAF** - Proteção contra DDoS
-3. **Validação server-side de preços** - Nunca confiar no frontend
-
----
-
-## Checklist Pós-Geração
-
-- [ ] Ativos de valor identificados
-- [ ] Pontos de entrada mapeados
-- [ ] Superfície de ataque documentada
-- [ ] Análise STRIDE completa para componentes críticos
-- [ ] DFD com trust boundaries
-- [ ] Matriz de riscos calculada
-- [ ] Top 3-5 ameaças com árvores de ataque
-- [ ] Plano de mitigação priorizado
-- [ ] Salvar em `docs/09-seguranca/threat-model.md`

package/dist/content/content/prompts/testes/contract-testing.md

@@ -1,340 +0,0 @@
-# Prompt: Contract Testing
-
-> **Prioridade**: 🟠 ALTA  
-> **Aplicável a**: Microserviços, APIs com múltiplos consumidores, integrações com terceiros
-
----
-
-## O que é Contract Testing?
-
-Contract testing verifica que **produtor** (API) e **consumidor** (cliente) concordam sobre o contrato de comunicação, sem precisar testar integração completa.
-
-```
-Consumer-Driven Contract Testing:
-┌──────────────┐         ┌──────────────┐
-│   Consumer   │ ──────► │   Producer   │
-│  (Frontend)  │ Contract│   (Backend)  │
-└──────────────┘         └──────────────┘
-       │                        │
-       ▼                        ▼
-   Gera contrato          Valida contrato
-   (expectations)         (implementação)
-```
-
----
-
-## Quando Usar?
-
-| Cenário | Contract Testing? | Justificativa |
-|---------|-------------------|---------------|
-| Microserviços | ✅ Sim | Evita quebrar consumidores |
-| API pública | ✅ Sim | Múltiplos consumidores |
-| Frontend + Backend | ✅ Sim | Times diferentes |
-| Monolito | ❌ Geralmente não | Testes de integração são suficientes |
-| Integração com terceiros | ⚠️ Às vezes | Se terceiro fornece contract |
-
----
-
-## Prompt Base: Implementar Contract Testing
-
-```text
-Atue como engenheiro de QA especialista em contract testing.
-
-Tenho a seguinte arquitetura:
-- Produtor: [ex. API de Usuários - Node.js + Express]
-- Consumidores: [ex. Frontend React, Mobile App, Serviço B]
-- Comunicação: [REST/GraphQL/gRPC/Mensageria]
-
-Ferramenta escolhida: [Pact/Spring Cloud Contract/Specmatic]
-
-Gere uma implementação completa de contract testing:
-
-1. **Setup do Consumer**
-   - Como definir expectations
-   - Exemplo de teste de contrato
-   - Geração do arquivo de contrato
-
-2. **Setup do Producer**
-   - Como carregar e validar contratos
-   - Exemplo de verificação
-   - Integração com CI/CD
-
-3. **Broker/Compartilhamento**
-   - Como compartilhar contratos entre times
-   - Pact Broker ou alternativa
-   - Versionamento de contratos
-
-4. **Workflow de CI/CD**
-   - Quando rodar testes de contrato
-   - Como bloquear deploy se contrato quebrar
-   - Webhooks para notificação
-
-5. **Can-I-Deploy**
-   - Verificar compatibilidade antes de deploy
-   - Matriz de compatibilidade
-```
-
----
-
-## Prompt: Consumer Test (Pact)
-
-```text
-Tenho um serviço consumidor que chama esta API:
-[COLE EXEMPLO DE REQUEST/RESPONSE ESPERADO]
-
-Stack do consumidor: [ex. TypeScript + Jest]
-
-Gere um teste Pact que:
-1. Define a expectativa do consumidor
-2. Gera o arquivo de contrato (pact file)
-3. Testa a integração com mock server
-4. Publica o contrato no broker
-```
-
----
-
-## Prompt: Provider Verification (Pact)
-
-```text
-Tenho uma API que precisa validar contratos de consumidores:
-[COLE ESTRUTURA DA API]
-
-Contratos estão em: [broker URL / pasta local]
-
-Stack: [ex. Java + Spring Boot]
-
-Gere:
-1. Configuração de verificação de contratos
-2. Provider states (setup de dados para cada teste)
-3. Integração com CI para rodar em cada PR
-4. Relatório de compatibilidade
-```
-
----
-
-## Exemplo Completo: Pact (JavaScript)
-
-### Consumer Test
-
-```typescript
-// consumer/tests/userService.pact.test.ts
-import { PactV3, MatchersV3 } from '@pact-foundation/pact';
-import { UserService } from '../src/services/userService';
-
-const { like, eachLike } = MatchersV3;
-
-const provider = new PactV3({
-  consumer: 'FrontendApp',
-  provider: 'UserAPI',
-  dir: './pacts',
-});
-
-describe('User API Contract', () => {
-  it('should get user by ID', async () => {
-    // Arrange: definir expectativa
-    await provider
-      .given('user 123 exists')
-      .uponReceiving('a request for user 123')
-      .withRequest({
-        method: 'GET',
-        path: '/api/users/123',
-        headers: {
-          Accept: 'application/json',
-        },
-      })
-      .willRespondWith({
-        status: 200,
-        headers: {
-          'Content-Type': 'application/json',
-        },
-        body: like({
-          id: '123',
-          name: 'John Doe',
-          email: 'john@example.com',
-        }),
-      });
-
-    // Act & Assert: rodar contra mock server
-    await provider.executeTest(async (mockServer) => {
-      const client = new UserService(mockServer.url);
-      const user = await client.getUser('123');
-
-      expect(user.id).toBe('123');
-      expect(user.name).toBe('John Doe');
-    });
-  });
-
-  it('should list users', async () => {
-    await provider
-      .given('users exist')
-      .uponReceiving('a request to list users')
-      .withRequest({
-        method: 'GET',
-        path: '/api/users',
-      })
-      .willRespondWith({
-        status: 200,
-        body: {
-          data: eachLike({
-            id: like('1'),
-            name: like('User Name'),
-            email: like('user@example.com'),
-          }),
-          total: like(10),
-        },
-      });
-
-    await provider.executeTest(async (mockServer) => {
-      const client = new UserService(mockServer.url);
-      const result = await client.listUsers();
-
-      expect(result.data.length).toBeGreaterThan(0);
-    });
-  });
-});
-```
-
-### Provider Verification
-
-```typescript
-// provider/tests/pactVerification.test.ts
-import { Verifier } from '@pact-foundation/pact';
-import { app } from '../src/app';
-
-describe('Pact Verification', () => {
-  let server: any;
-
-  beforeAll((done) => {
-    server = app.listen(3001, done);
-  });
-
-  afterAll((done) => {
-    server.close(done);
-  });
-
-  it('validates the expectations of FrontendApp', async () => {
-    const verifier = new Verifier({
-      providerBaseUrl: 'http://localhost:3001',
-      provider: 'UserAPI',
-      pactBrokerUrl: process.env.PACT_BROKER_URL,
-      pactBrokerToken: process.env.PACT_BROKER_TOKEN,
-      publishVerificationResult: process.env.CI === 'true',
-      providerVersion: process.env.GIT_SHA,
-      
-      // Provider states setup
-      stateHandlers: {
-        'user 123 exists': async () => {
-          await seedDatabase({ users: [{ id: '123', name: 'John Doe' }] });
-        },
-        'users exist': async () => {
-          await seedDatabase({ users: generateUsers(5) });
-        },
-      },
-    });
-
-    await verifier.verifyProvider();
-  });
-});
-```
-
-### CI/CD Integration
-
-```yaml
-# .github/workflows/contract-test.yml
-name: Contract Tests
-
-on:
-  push:
-    branches: [main, develop]
-  pull_request:
-
-jobs:
-  consumer-test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      
-      - name: Run consumer tests
-        run: npm run test:pact
-        
-      - name: Publish pacts to broker
-        run: npx pact-broker publish ./pacts \
-          --consumer-app-version=${{ github.sha }} \
-          --broker-base-url=${{ secrets.PACT_BROKER_URL }} \
-          --broker-token=${{ secrets.PACT_BROKER_TOKEN }}
-
-  provider-verify:
-    runs-on: ubuntu-latest
-    needs: consumer-test
-    steps:
-      - uses: actions/checkout@v4
-      
-      - name: Verify provider
-        run: npm run test:pact:verify
-        env:
-          PACT_BROKER_URL: ${{ secrets.PACT_BROKER_URL }}
-          PACT_BROKER_TOKEN: ${{ secrets.PACT_BROKER_TOKEN }}
-          GIT_SHA: ${{ github.sha }}
-          CI: true
-
-  can-i-deploy:
-    runs-on: ubuntu-latest
-    needs: provider-verify
-    steps:
-      - name: Can I Deploy?
-        run: npx pact-broker can-i-deploy \
-          --pacticipant UserAPI \
-          --version ${{ github.sha }} \
-          --to-environment production \
-          --broker-base-url=${{ secrets.PACT_BROKER_URL }} \
-          --broker-token=${{ secrets.PACT_BROKER_TOKEN }}
-```
-
----
-
-## Ferramentas por Stack
-
-| Stack | Ferramenta | Tipo |
-|-------|-----------|------|
-| **JavaScript/TypeScript** | Pact-JS | Consumer-driven |
-| **Java/Kotlin** | Pact-JVM, Spring Cloud Contract | Ambos |
-| **Python** | Pact-Python | Consumer-driven |
-| **Go** | Pact-Go | Consumer-driven |
-| **OpenAPI** | Specmatic, Prism | Schema-based |
-| **gRPC** | buf, protovalidate | Schema-based |
-
----
-
-## Pact Broker
-
-Central para compartilhar contratos:
-
-```bash
-# Docker
-docker run -d \
-  -p 9292:9292 \
-  -e PACT_BROKER_DATABASE_URL="sqlite:///pact_broker.sqlite3" \
-  pactfoundation/pact-broker
-
-# Ou use Pactflow (SaaS)
-```
-
----
-
-## Checklist
-
-- [ ] Consumer tests gerando contratos
-- [ ] Provider verificando contratos
-- [ ] Broker configurado para compartilhamento
-- [ ] CI/CD rodando testes de contrato
-- [ ] can-i-deploy bloqueando deploys incompatíveis
-- [ ] Provider states cobrindo cenários
-- [ ] Versionamento semântico de contratos
-
----
-
-## Referências
-
-- [Pact Documentation](https://docs.pact.io/)
-- [Contract Testing na Prática](https://martinfowler.com/articles/consumerDrivenContracts.html)
-- [Spring Cloud Contract](https://spring.io/projects/spring-cloud-contract)