@maestro-ai/mcp-server 1.0.0 → 1.0.1

package/dist/content/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/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/content/prompts/arquitetura/ddd-bounded-contexts.md

@@ -1,183 +0,0 @@
-# Prompt: DDD - Bounded Contexts e Strategic Design
-
-> **Quando usar**: Projetos complexos com múltiplos domínios ou equipes
-> **Especialista**: [Arquitetura de Software](../../02-especialistas/Especialista%20em%20Arquitetura%20de%20Software.md)
-> **Nível**: Complexo (3+ meses, domínio rico)
-
----
-
-## Fluxo de Contexto
-
-Antes de usar este prompt, tenha em mãos:
-- `docs/CONTEXTO.md` - Entendimento atual do projeto
-- `docs/04-modelo/modelo-dominio.md` - Modelo de domínio inicial
-
-Após gerar, salve o resultado em:
-- `docs/05-arquitetura/bounded-contexts.md`
-
----
-
-## Prompt Completo
-
-```text
-Atue como arquiteto de software especialista em Domain-Driven Design.
-
-## Contexto do Projeto
-
-[COLE O CONTEÚDO DE docs/CONTEXTO.md]
-
-## Modelo de Domínio Atual
-
-[COLE ENTIDADES E RELACIONAMENTOS DE docs/04-modelo/modelo-dominio.md]
-
-## Requisitos de Negócio
-
-[COLE REQUISITOS OU REGRAS DE NEGÓCIO PRINCIPAIS]
-
----
-
-## Sua Missão
-
-Aplique Strategic DDD e Tactical DDD:
-
-### 1. Strategic Design
-
-#### 1.1 Bounded Contexts
-Para cada contexto identificado:
-- Nome do contexto
-- Classificação: **Core Domain** / **Supporting** / **Generic**
-- Responsabilidade principal (1-2 frases)
-- Linguagem Ubíqua (termos específicos deste contexto)
-- Time responsável sugerido
-
-#### 1.2 Context Map
-Mapeie relacionamentos entre contextos:
-- **Partnership**: Colaboração mútua
-- **Shared Kernel**: Código compartilhado
-- **Customer-Supplier**: Upstream → Downstream
-- **Conformist**: Downstream adapta-se ao Upstream
-- **Anti-Corruption Layer (ACL)**: Proteção contra modelo externo
-- **Open Host Service / Published Language**: API pública
-
-#### 1.3 Diagrama de Contextos
-Em Mermaid, mostre os bounded contexts e seus relacionamentos.
-
-### 2. Tactical Design
-
-Para cada Bounded Context **Core**:
-
-#### 2.1 Aggregates
-- Nome do Aggregate
-- Raiz do Aggregate (Aggregate Root)
-- Entidades internas
-- Value Objects
-- Invariantes (regras que SEMPRE devem ser verdade)
-- Limites transacionais
-
-#### 2.2 Domain Events
-- Evento (nome no passado: PedidoCriado)
-- Quando é disparado
-- Payload (dados que carrega)
-- Quem consome (outros contextos ou serviços)
-
-#### 2.3 Domain Services
-Lógica que não pertence a uma entidade específica.
-
-#### 2.4 Repository Interfaces
-Interface do repositório para cada Aggregate Root.
-
-### 3. Decisões e Trade-offs
-- Por que esses contextos e não outros?
-- Riscos de comunicação entre contextos
-- Sugestão de tecnologia para integração
-```
-
----
-
-## Exemplo de Uso
-
-```text
-Atue como arquiteto de software especialista em Domain-Driven Design.
-
-## Contexto do Projeto
-
-Marketplace de serviços locais conectando prestadores e clientes.
-Inclui agendamento, pagamentos e avaliações.
-
-## Modelo de Domínio Atual
-
-- Usuario (id, nome, email, tipo)
-- Servico (id, nome, preco, prestadorId)
-- Agendamento (id, clienteId, servicoId, data, status)
-- Pagamento (id, agendamentoId, valor, status)
-- Avaliacao (id, agendamentoId, nota, comentario)
-
-## Requisitos de Negócio
-
-- Prestadores definem disponibilidade
-- Clientes agendam e pagam antecipadamente
-- Após conclusão do serviço, cliente pode avaliar
-- Prestador recebe após 7 dias da conclusão
-```
-
----
-
-## Resposta Esperada
-
-### 1. Bounded Contexts
-
-| Contexto | Tipo | Responsabilidade | Linguagem |
-|---|---|---|---|
-| **Agendamentos** | Core | Gerenciar agendas e horários | Agendamento, Slot, Confirmação |
-| **Clientes** | Supporting | Cadastro e perfil de clientes | Cliente, Preferências |
-| **Pagamentos** | Generic | Processar cobranças | Transação, Fatura |
-| **Notificações** | Generic | Enviar comunicações | Notificação, Template |
-
-### Context Map
-
-```mermaid
-graph TB
-    AG[Agendamentos - Core]
-    CL[Clientes - Supporting]
-    PG[Pagamentos - Generic]
-    NT[Notificações - Generic]
-    
-    AG -->|"Customer-Supplier"| CL
-    AG -->|"ACL"| PG
-    AG -->|"Published Language"| NT
-```
-
-### 2. Aggregate: Agendamento
-
-**Raiz:** Agendamento
-
-**Entidades:**
-- Agendamento (raiz)
-- Servico (dentro do agregado)
-
-**Value Objects:**
-- HorarioSlot { inicio: DateTime, fim: DateTime }
-- StatusAgendamento { tipo: enum }
-
-**Invariantes:**
-- Um agendamento não pode sobrepor outro do mesmo profissional
-- Cancelamento só é permitido até 2h antes
-- Agendamento só pode ser confirmado se pagamento estiver aprovado
-
-**Eventos:**
-- AgendamentoCriado { id, clienteId, horario }
-- AgendamentoCancelado { id, motivo }
-- AgendamentoConfirmado { id }
-- AgendamentoConcluido { id }
-
----
-
-## Checklist Pós-Geração
-
-- [ ] 3-5 Bounded Contexts identificados
-- [ ] Contextos classificados (Core/Supporting/Generic)
-- [ ] Context Map com relações claras
-- [ ] Aggregates definidos com invariantes
-- [ ] Domain Events listados com payload
-- [ ] Linguagem ubíqua definida por contexto
-- [ ] Salvar em `docs/05-arquitetura/bounded-contexts.md`

package/dist/content/content/prompts/arquitetura/ddd-cqrs.md

@@ -1,176 +0,0 @@
-# Prompt: Arquitetura DDD + CQRS
-
-> **Quando usar**: Projetos de nível Complexo (3+ meses, domínio rico, múltiplos contextos)
-> **Especialista**: Arquitetura Avançada
-
----
-
-## Prompt Completo
-
-```text
-Atue como arquiteto especialista em Domain-Driven Design e sistemas distribuídos.
-
-## 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]
-
-Complexidade específica:
-- Multi-tenant: [SIM/NÃO]
-- Compliance: [LGPD/SOC2/HIPAA/Nenhum]
-- SLA disponibilidade: [99%/99.9%/99.99%]
-- Pico de usuários: [NÚMERO]
-
----
-
-## Sua Missão
-
-Proponha uma arquitetura DDD com CQRS considerando:
-
-### 1. Strategic Design (Bounded Contexts)
-
-Identifique e documente:
-
-- **Bounded Contexts** (3-5 contextos):
-  - Nome e responsabilidade de cada contexto
-  - Ubiquitous Language de cada um
-  - Qual é o Core Domain vs Supporting/Generic
-
-- **Context Map**:
-  - Relações entre contextos (diagrama)
-  - Tipo de integração:
-    - Shared Kernel
-    - Customer-Supplier
-    - Conformist
-    - Anti-Corruption Layer
-    - Open Host Service / Published Language
-
-### 2. Tactical Design (por Bounded Context)
-
-Para cada contexto, defina:
-
-- **Aggregates**:
-  - Aggregate Roots
-  - Invariantes que protegem
-  - Limites transacionais
-
-- **Entities e Value Objects**:
-  - Quais são Entities (identidade)
-  - Quais são Value Objects (imutáveis)
-
-- **Domain Events**:
-  - Eventos que cada agregado publica
-  - Subscribers internos e externos
-
-- **Domain Services**:
-  - Operações que não pertencem a uma entidade
-
-### 3. CQRS (Command Query Responsibility Segregation)
-
-Defina:
-
-- **Command Side (Write Model)**:
-  - Commands e Command Handlers
-  - Agregados que processam
-  - Validações
-
-- **Query Side (Read Model)**:
-  - Views/Projections otimizadas
-  - Como são atualizadas (sync vs async)
-  - Tecnologia (mesmo banco vs banco separado)
-
-- **Event Sourcing** (se aplicável):
-  - Justificativa para usar ou não
-  - Event Store
-  - Snapshots
-
-### 4. Integração entre Contextos
-
-- **Message Broker**:
-  - Escolha (Kafka/RabbitMQ/SQS) com justificativa
-  - Tópicos/Filas por tipo de evento
-
-- **Sagas** (se necessário):
-  - Fluxos que cruzam contextos
-  - Compensação em caso de falha
-
-- **Consistência Eventual**:
-  - Onde é aceitável
-  - SLAs de propagação
-
-### 5. Observabilidade
-
-- **Distributed Tracing**:
-  - Correlation IDs entre serviços
-  - Ferramentas (Jaeger, Zipkin, etc)
-
-- **Métricas de Domínio**:
-  - KPIs por bounded context
-  - Alertas críticos
-
-### 6. ADRs Obrigatórios
-
-- Por que DDD e não arquitetura mais simples
-- Escolha do message broker
-- Event Sourcing sim/não
-- Estratégia de consistência eventual
-- Tecnologia do Event Store
-
----
-
-## Formato de Saída
-
-Retorne um documento Markdown com:
-
-1. **Context Map** (diagrama Mermaid)
-2. **Detalhamento de cada Bounded Context**
-3. **Fluxo de eventos entre contextos**
-4. **ADRs completos**
-5. **Estrutura de projetos/módulos**
-6. **Estimativa de complexidade e riscos**
-```
-
----
-
-## Exemplo de Context Map
-
-```mermaid
-graph LR
-    subgraph Core["Core Domain"]
-        ORDERS[Orders Context]
-    end
-    
-    subgraph Supporting["Supporting"]
-        INVENTORY[Inventory Context]
-        SHIPPING[Shipping Context]
-    end
-    
-    subgraph Generic["Generic"]
-        IDENTITY[Identity Context]
-        PAYMENTS[Payments Context]
-    end
-    
-    ORDERS -->|Customer-Supplier| INVENTORY
-    ORDERS -->|Customer-Supplier| SHIPPING
-    ORDERS -->|ACL| PAYMENTS
-    ORDERS -->|Conformist| IDENTITY
-```
-
----
-
-## Checklist Pós-Geração
-
-- [ ] Bounded Contexts identificados (3-5)
-- [ ] Context Map com relações claras
-- [ ] Aggregates definidos com invariantes
-- [ ] Domain Events listados
-- [ ] CQRS com Write/Read separados
-- [ ] Message broker escolhido e justificado
-- [ ] ADRs para decisões críticas
-- [ ] Riscos e complexidade documentados