@maestro-ai/mcp-server 1.2.0 → 2.1.0

package/dist/content/prompts/arquitetura/arquitetura-c4-completo.md

@@ -1,190 +0,0 @@
-# Prompt: Arquitetura C4 Completa
-
-> **Quando usar**: Início da fase de arquitetura, para definir visão geral do sistema
-> **Especialista**: [Arquitetura de Software](../../02-especialistas/Especialista%20em%20Arquitetura%20de%20Software.md)
-> **Nível**: Médio a Complexo
-
----
-
-## Fluxo de Contexto
-
-Antes de usar este prompt, tenha em mãos:
-- `docs/CONTEXTO.md` - Entendimento atual do projeto
-- `docs/02-requisitos/requisitos.md` - Requisitos funcionais e não-funcionais
-
-Após gerar, salve o resultado em:
-- `docs/05-arquitetura/arquitetura-c4.md`
-
----
-
-## Prompt Completo
-
-```text
-Atue como arquiteto de software sênior especializado em arquitetura C4.
-
-## Contexto do Projeto
-
-[COLE O CONTEÚDO DE docs/CONTEXTO.md]
-
-## Requisitos
-
-Requisitos funcionais:
-[COLE RFs DE docs/02-requisitos/requisitos.md]
-
-Requisitos não-funcionais:
-[COLE RNFs DE docs/02-requisitos/requisitos.md]
-
-Stack sugerida: [DESCREVA A STACK PREFERENCIAL]
-Escala esperada: [X usuários simultâneos, Y requests/segundo]
-Orçamento de infra: [ORÇAMENTO MENSAL]
-
----
-
-## Sua Missão
-
-Entregue uma arquitetura completa usando o modelo C4:
-
-### 1. Diagrama C4 Nível 1 (Contexto)
-- Atores externos (tipos de usuários)
-- Sistemas externos que integram
-- O sistema como caixa única
-- Gere em formato Mermaid
-
-### 2. Diagrama C4 Nível 2 (Containers)
-- Aplicações (web, API, mobile)
-- Bancos de dados
-- Message brokers (se aplicável)
-- Caches
-- Para cada container: tecnologia e responsabilidade
-- Gere em formato Mermaid
-
-### 3. Diagrama C4 Nível 3 (Componentes) para o container principal
-- Módulos/pacotes principais
-- Responsabilidades de cada componente
-- Dependências entre componentes
-- Gere em formato Mermaid
-
-### 4. Decisões Arquiteturais (ADRs)
-
-Para cada decisão, justifique:
-
-**Padrão arquitetural**: [MVC/Hexagonal/DDD/Clean Architecture]
-- Por que este padrão?
-- Alternativas consideradas e por que foram descartadas
-
-**Estratégia de persistência**:
-- Banco escolhido e justificativa
-- Estratégia de cache
-
-**Estratégia de escalabilidade**:
-- O que escala horizontalmente
-- Pontos de bottleneck potenciais
-
-**Observabilidade**:
-- Logs, métricas, traces
-- Ferramentas sugeridas
-
-**Segurança**:
-- Autenticação/autorização
-- Proteção de dados sensíveis
-
-### 5. Trade-offs e Custos
-- Prós e contras das decisões
-- O que sacrificamos e por quê
-- Custo estimado de infraestrutura (MVP e 6 meses)
-- Riscos técnicos identificados
-
-### 6. Estrutura de Pastas
-- Proposta de estrutura de diretórios do projeto
-```
-
----
-
-## Exemplo de Uso
-
-```text
-Atue como arquiteto de software sênior especializado em arquitetura C4.
-
-## Contexto do Projeto
-
-Sistema de agendamento online para salões de beleza. Permite que 
-clientes agendem horários via web/mobile e recebam confirmação via WhatsApp.
-
-## Requisitos
-
-Requisitos funcionais:
-- RF-001: O sistema deve permitir agendamento online
-- RF-002: O sistema deve enviar confirmação via WhatsApp
-- RF-003: O sistema deve permitir cancelamento até 2h antes
-
-Requisitos não-funcionais:
-- RNF-001: Tempo de resposta < 2 segundos
-- RNF-002: Disponibilidade 99.5%
-
-Stack sugerida: Node.js + TypeScript + PostgreSQL + Redis
-Escala esperada: 500 usuários simultâneos, 50 requests/segundo
-Orçamento de infra: R$ 300/mês
-
-[CONTINUA COM O PROMPT COMPLETO]
-```
-
----
-
-## Resposta Esperada
-
-### 1. Contexto (C4 L1)
-
-```mermaid
-graph TB
-    U[Usuário Final]
-    A[Admin do Salão]
-    S[Sistema de Agendamento]
-    P[Gateway de Pagamento]
-    W[API WhatsApp]
-    
-    U -->|Usa| S
-    A -->|Gerencia| S
-    S -->|Processa| P
-    S -->|Notifica| W
-```
-
-### 2. Containers (C4 L2)
-
-```mermaid
-graph TB
-    subgraph Sistema
-        WEB[Next.js - Frontend]
-        API[NestJS - API]
-        DB[(PostgreSQL)]
-        CACHE[(Redis)]
-    end
-    
-    WEB --> API
-    API --> DB
-    API --> CACHE
-```
-
-### 4. Decisões
-
-**Padrão**: Hexagonal Architecture
-- **Por quê**: Separação clara entre domínio e infraestrutura
-- **Alternativa descartada**: MVC - menos testável
-
-**Banco**: PostgreSQL
-- **Por quê**: ACID, JSON support, maturidade
-- **Cache**: Redis para sessões e queries frequentes
-
----
-
-## Checklist Pós-Geração
-
-Após receber a arquitetura, valide:
-
-- [ ] Diagrama C4 inclui níveis 1, 2 e 3
-- [ ] Padrão arquitetural está justificado
-- [ ] Pelo menos 4 ADRs documentados
-- [ ] Estrutura de pastas proposta
-- [ ] Estimativa de custos presente (MVP e 6 meses)
-- [ ] Stack justificada com prós/contras
-- [ ] Riscos técnicos identificados
-- [ ] Salvar em `docs/05-arquitetura/arquitetura-c4.md`

package/dist/content/prompts/arquitetura/clean-architecture.md

@@ -1,151 +0,0 @@
-# Prompt: Arquitetura Clean Architecture
-
-> **Quando usar**: Projetos de nível Médio (1-3 meses, 5-15 entidades)
-> **Especialista**: Arquitetura de Software
-
----
-
-## Prompt Completo
-
-```text
-Atue como arquiteto de software sênior especializado em Clean Architecture.
-
-## Contexto do Projeto
-
-PRD:
-[COLE O CONTEÚDO DE docs/01-produto/PRD.md]
-
-Requisitos:
-[COLE O CONTEÚDO DE docs/02-requisitos/requisitos.md]
-
-Modelo de Domínio:
-[COLE O CONTEÚDO DE docs/04-modelo/modelo-dominio.md]
-
-Stack preferencial: [DESCREVA SUA STACK]
-Prazo: [PRAZO DO MVP]
-Orçamento de infra: [ORÇAMENTO MENSAL]
-
----
-
-## Sua Missão
-
-Proponha uma arquitetura em Clean Architecture considerando:
-
-### 1. Camadas da Arquitetura
-
-Defina cada camada com responsabilidades claras:
-
-- **Domain Layer** (mais interna):
-  - Entidades de domínio (não são ORM models)
-  - Value Objects
-  - Regras de negócio puras
-  - Interfaces de repositórios (ports)
-
-- **Application Layer**:
-  - Use Cases / Application Services
-  - DTOs de entrada e saída
-  - Orquestração de fluxos
-  - Sem dependência de frameworks
-
-- **Infrastructure Layer**:
-  - Implementações de repositórios (adapters)
-  - Serviços externos (email, pagamento, etc)
-  - Configurações de banco de dados
-  - Clientes HTTP
-
-- **Interface Layer** (mais externa):
-  - Controllers / Handlers
-  - Presenters / Serializers
-  - Middlewares
-  - Validação de input
-
-### 2. Diagrama C4
-
-Gere diagramas em Mermaid para:
-
-**Nível 1 - Contexto**:
-- Usuários e sistemas externos
-- Relações de alto nível
-
-**Nível 2 - Containers**:
-- Frontend, Backend, Banco, Cache, etc
-- Tecnologias de cada container
-
-**Nível 3 - Componentes** (para o backend):
-- Módulos principais
-- Fluxo de dependências
-
-### 3. Decisões Arquiteturais (ADRs)
-
-Para cada decisão importante, documente:
-- Contexto: Por que é necessário decidir
-- Decisão: O que foi escolhido
-- Alternativas: O que foi descartado e por quê
-- Consequências: Prós e contras
-
-ADRs obrigatórios:
-- Escolha da stack
-- Padrão de arquitetura (Clean vs outras)
-- Estratégia de autenticação
-- Estratégia de persistência
-
-### 4. Trade-offs
-
-Explique:
-- Por que Clean Architecture e não algo mais simples
-- Por que não microserviços (se aplicável)
-- Custos de infra estimados (MVP e 6 meses)
-- Pontos de escalabilidade futura
-
-### 5. Formato de Saída
-
-Retorne um documento Markdown estruturado seguindo o template:
-- Use diagramas Mermaid
-- Inclua code snippets de exemplo para cada camada
-- Liste arquivos/pastas da estrutura proposta
-```
-
----
-
-## Exemplo de Uso
-
-```text
-Atue como arquiteto de software sênior especializado em Clean Architecture.
-
-## Contexto do Projeto
-
-PRD:
-Sistema de gestão de tarefas para equipes remotas. Permite criar projetos, 
-adicionar tarefas com prazos, e acompanhar progresso.
-
-Requisitos:
-- RF-001: Usuário pode criar projetos
-- RF-002: Usuário pode adicionar tarefas a projetos
-- RF-003: Tarefas têm título, descrição, prazo e status
-- RNF-001: Suportar 1000 usuários simultâneos
-- RNF-002: Tempo de resposta < 200ms
-
-Modelo de Domínio:
-- User (id, name, email)
-- Project (id, name, ownerId)
-- Task (id, title, description, dueDate, status, projectId)
-
-Stack preferencial: Node.js + TypeScript + PostgreSQL
-Prazo: 2 meses
-Orçamento de infra: R$ 500/mês
-
-[CONTINUA COM O PROMPT COMPLETO ACIMA]
-```
-
----
-
-## Checklist Pós-Geração
-
-Após receber a arquitetura, valide:
-
-- [ ] Diagrama C4 inclui níveis 1 e 2
-- [ ] Camadas estão bem definidas
-- [ ] Pelo menos 3 ADRs documentados
-- [ ] Estrutura de pastas proposta
-- [ ] Estimativa de custos presente
-- [ ] Stack justificada com prós/contras

package/dist/content/prompts/arquitetura/multi-tenancy.md

@@ -1,235 +0,0 @@
-# Prompt: Multi-tenancy
-
-> **Prioridade**: 🟡 MÉDIA  
-> **Aplicável a**: SaaS, plataformas white-label, sistemas B2B
-
----
-
-## Prompt Base: Projetar Multi-tenancy
-
-```text
-Atue como arquiteto de software especialista em SaaS.
-
-Preciso implementar multi-tenancy para:
-- Tipo de produto: [ex. CRM SaaS, e-commerce white-label]
-- Número esperado de tenants: [ex. 100 / 10.000 / 1M]
-- Isolamento necessário: [ex. dados apenas / compliance rígido]
-- Customização por tenant: [ex. branding / features / workflows]
-
-Constraints:
-- Stack: [DESCREVA]
-- Orçamento de infra: [DESCREVA]
-- Time: [DESCREVA]
-
-Projete:
-
-1. **Modelo de Isolamento**
-   - Database per tenant, schema per tenant, ou row-level?
-   - Justificativa para o contexto
-   - Estratégia para tenants com necessidades especiais
-
-2. **Identificação de Tenant**
-   - Como identificar o tenant em cada request
-   - Subdomain, header, JWT, ou combinação
-   - Fallback se não identificado
-
-3. **Implementação de Dados**
-   - Schema das tabelas (com tenant_id)
-   - Middleware/interceptor para filtrar
-   - Como garantir que queries não vazem dados
-
-4. **Customização**
-   - Configurações por tenant
-   - Feature flags por plano
-   - Branding (logo, cores)
-
-5. **Operacional**
-   - Provisioning de novo tenant
-   - Migrations multi-tenant
-   - Backup/restore por tenant
-   - Monitoramento por tenant
-```
-
----
-
-## Prompt: Migrar para Multi-tenant
-
-```text
-Tenho um sistema single-tenant que precisa virar multi-tenant:
-[DESCREVA ESTRUTURA ATUAL]
-
-Requisitos:
-- Manter dados do tenant atual
-- Adicionar suporte a novos tenants
-- Mínimo de breaking changes
-- Timeline: [PRAZO]
-
-Gere um plano de migração com:
-1. Alterações de schema (adicionar tenant_id)
-2. Migrations de dados existentes
-3. Mudanças de código (queries, middlewares)
-4. Testes de validação
-5. Rollout gradual
-```
-
----
-
-## Prompt: Implementar Row-Level Security
-
-```text
-Preciso implementar isolamento por row-level security.
-
-Stack: [ex. PostgreSQL + Prisma + Node.js]
-
-Tabelas principais:
-[LISTE TABELAS]
-
-Gere:
-1. Migrations para adicionar tenant_id
-2. Policies RLS no PostgreSQL  
-3. Middleware para setar current_tenant
-4. Repository base com tenant scope
-5. Testes de isolamento
-```
-
----
-
-## Prompt: Tenant Provisioning
-
-```text
-Preciso automatizar o onboarding de novos tenants.
-
-Quando um novo tenant é criado, preciso:
-- [ex. Criar registro no banco]
-- [ex. Configurar subdomain no DNS]
-- [ex. Criar usuário admin]
-- [ex. Popular dados iniciais]
-- [ex. Enviar email de boas-vindas]
-
-Stack: [DESCREVA]
-
-Gere:
-1. Endpoint/workflow de provisioning
-2. Jobs assíncronos necessários
-3. Rollback se algum step falhar
-4. Notificações de progresso
-5. Documentação do processo
-```
-
----
-
-## Prompt: Limites e Quotas por Tenant
-
-```text
-Preciso implementar limites por plano:
-
-| Recurso | Free | Pro | Enterprise |
-|---------|------|-----|------------|
-| Usuários | 5 | 50 | Ilimitado |
-| Storage | 1GB | 10GB | 100GB |
-| API calls/dia | 1000 | 10000 | Ilimitado |
-| Features | [X,Y] | [X,Y,Z] | Todas |
-
-Stack: [DESCREVA]
-
-Gere:
-1. Schema para quotas e usage tracking
-2. Service para verificar limites
-3. Middleware para bloquear quando excede
-4. Dashboard de usage para tenant admin
-5. Alerts quando próximo do limite
-```
-
----
-
-## Exemplo: Tenant Context Completo
-
-```typescript
-// src/tenancy/TenantContext.ts
-import { AsyncLocalStorage } from 'async_hooks';
-import { PrismaClient } from '@prisma/client';
-
-interface TenantContext {
-  tenantId: string;
-  config: TenantConfig;
-  user?: User;
-}
-
-interface TenantConfig {
-  id: string;
-  subdomain: string;
-  plan: 'free' | 'pro' | 'enterprise';
-  quotas: {
-    maxUsers: number;
-    maxStorage: number;
-    maxApiCalls: number;
-  };
-  features: string[];
-}
-
-const storage = new AsyncLocalStorage<TenantContext>();
-
-// Middleware
-export async function tenantMiddleware(req, res, next) {
-  const tenantId = extractTenantIdFromRequest(req);
-  
-  if (!tenantId) {
-    return res.status(400).json({ error: 'Tenant not found' });
-  }
-
-  const config = await loadTenantConfig(tenantId);
-  
-  storage.run({ tenantId, config }, next);
-}
-
-// Getters
-export function getTenant(): TenantContext {
-  const ctx = storage.getStore();
-  if (!ctx) throw new Error('No tenant context');
-  return ctx;
-}
-
-export function getTenantId(): string {
-  return getTenant().tenantId;
-}
-
-export function hasFeature(feature: string): boolean {
-  return getTenant().config.features.includes(feature);
-}
-
-// Prisma extension para injetar tenant automaticamente
-export const prisma = new PrismaClient().$extends({
-  query: {
-    $allModels: {
-      async findMany({ args, query }) {
-        args.where = { ...args.where, tenantId: getTenantId() };
-        return query(args);
-      },
-      async create({ args, query }) {
-        args.data = { ...args.data, tenantId: getTenantId() };
-        return query(args);
-      },
-      // ... outras operações
-    }
-  }
-});
-```
-
----
-
-## Checklist
-
-- [ ] Modelo de isolamento definido
-- [ ] Identificação de tenant implementada
-- [ ] Todas as queries filtram por tenant
-- [ ] Testes de isolamento automatizados
-- [ ] Provisioning automatizado
-- [ ] Limites e quotas por plano
-- [ ] Monitoramento por tenant
-- [ ] Documentação de onboarding
-
----
-
-## Referências
-
-Consulte: [Guia de Multi-tenancy](../03-guias/Guia%20de%20Multi-tenancy.md)