@maestro-ai/cli 1.0.0

package/content/prompts/arquitetura/ddd-bounded-contexts.md

@@ -0,0 +1,183 @@
+# 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/content/prompts/arquitetura/ddd-cqrs.md

@@ -0,0 +1,176 @@
+# 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

package/content/prompts/arquitetura/modelo-dominio.md

@@ -0,0 +1,207 @@
+# Prompt: Modelo de Domínio
+
+> **Quando usar**: Início do projeto, após refinar requisitos
+> **Especialista**: [Engenharia de Requisitos](../../02-especialistas/Especialista%20em%20Engenharia%20de%20Requisitos%20com%20IA.md) ou [Arquitetura de Software](../../02-especialistas/Especialista%20em%20Arquitetura%20de%20Software.md)
+> **Nível**: Simples a Médio
+
+---
+
+## 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
+
+Após gerar, salve o resultado em:
+- `docs/04-modelo/modelo-dominio.md`
+
+---
+
+## Prompt Completo
+
+```text
+Atue como analista de domínio especializado em modelagem de dados.
+
+## Contexto do Projeto
+
+[COLE O CONTEÚDO DE docs/CONTEXTO.md]
+
+## Requisitos
+
+[COLE REQUISITOS DE docs/02-requisitos/requisitos.md]
+
+---
+
+## Sua Missão
+
+Proponha um modelo de domínio inicial completo:
+
+### 1. Entidades Principais
+Para cada entidade:
+- Nome da entidade
+- Descrição (1 frase)
+- Atributos com tipos (use tipos genéricos: string, int, decimal, datetime, boolean, UUID)
+- Marque campos obrigatórios vs opcionais
+- Indique campos únicos (unique)
+
+### 2. Value Objects
+Identifique conceitos que são melhor representados como Value Objects:
+- Nome
+- Atributos
+- Regras de validação
+
+### 3. Relacionamentos
+- Cardinalidade (1:1, 1:N, N:N)
+- Direção da navegação
+- Cascade (o que acontece ao deletar)
+
+### 4. Diagrama ER
+Gere um diagrama Mermaid do modelo.
+
+### 5. Dúvidas Abertas
+Liste perguntas que ainda precisam ser respondidas pelo cliente.
+
+### 6. Considerações Técnicas
+- Índices que serão necessários
+- Campos que podem crescer muito (text, blob)
+- Dados sensíveis que precisam de criptografia
+```
+
+---
+
+## Exemplo de Uso
+
+```text
+Atue como analista de domínio especializado em modelagem de dados.
+
+## Contexto do Projeto
+
+Sistema de agendamento online para salões de beleza.
+
+## Requisitos
+
+- RF-001: Cliente pode se cadastrar com nome, telefone e email
+- RF-002: Salão pode cadastrar serviços com nome, duração e preço
+- RF-003: Cliente pode agendar um serviço para uma data/hora
+- RF-004: Sistema deve enviar confirmação por WhatsApp
+- RF-005: Cliente pode cancelar até 2h antes
+- RF-006: Salão pode ver relatório de agendamentos
+```
+
+---
+
+## Resposta Esperada
+
+### 1. Entidades
+
+**Cliente**
+| Atributo | Tipo | Obrigatório | Único | Notas |
+|----------|------|-------------|-------|-------|
+| id | UUID | ✓ | ✓ | PK |
+| nome | string(100) | ✓ | | |
+| telefone | string(20) | ✓ | ✓ | WhatsApp |
+| email | string(255) | | ✓ | |
+| criadoEm | datetime | ✓ | | default: now |
+
+**Servico**
+| Atributo | Tipo | Obrigatório | Único | Notas |
+|----------|------|-------------|-------|-------|
+| id | UUID | ✓ | ✓ | PK |
+| nome | string(100) | ✓ | | |
+| duracao | int | ✓ | | minutos |
+| preco | decimal(10,2) | ✓ | | |
+| ativo | boolean | ✓ | | default: true |
+
+**Agendamento**
+| Atributo | Tipo | Obrigatório | Único | Notas |
+|----------|------|-------------|-------|-------|
+| id | UUID | ✓ | ✓ | PK |
+| clienteId | UUID | ✓ | | FK → Cliente |
+| servicoId | UUID | ✓ | | FK → Servico |
+| dataHora | datetime | ✓ | | |
+| status | enum | ✓ | | pendente, confirmado, cancelado, concluido |
+| criadoEm | datetime | ✓ | | default: now |
+
+### 2. Value Objects
+
+**Telefone**
+- numero: string
+- ddi: string (default: +55)
+- Validação: formato válido de WhatsApp
+
+**StatusAgendamento**
+- Enum: PENDENTE, CONFIRMADO, CANCELADO, CONCLUIDO
+- Transições válidas definidas
+
+### 3. Relacionamentos
+
+```
+Cliente 1 ──── N Agendamento
+Servico 1 ──── N Agendamento
+```
+
+- Cliente → Agendamento: Cascade soft delete
+- Servico → Agendamento: Não permite deletar serviço com agendamentos futuros
+
+### 4. Diagrama ER
+
+```mermaid
+erDiagram
+    Cliente ||--o{ Agendamento : "faz"
+    Servico ||--o{ Agendamento : "é agendado"
+    
+    Cliente {
+        UUID id PK
+        string nome
+        string telefone UK
+        string email UK
+        datetime criadoEm
+    }
+    
+    Servico {
+        UUID id PK
+        string nome
+        int duracao
+        decimal preco
+        boolean ativo
+    }
+    
+    Agendamento {
+        UUID id PK
+        UUID clienteId FK
+        UUID servicoId FK
+        datetime dataHora
+        enum status
+        datetime criadoEm
+    }
+```
+
+### 5. Dúvidas
+
+- [ ] Um agendamento pode ter múltiplos serviços?
+- [ ] Há profissionais diferentes por serviço?
+- [ ] Cliente pode ter mais de um telefone?
+- [ ] Qual a política de reagendamento?
+
+### 6. Considerações Técnicas
+
+**Índices necessários:**
+- `agendamento.dataHora` - Consultas por período
+- `agendamento.status` - Filtros por status
+- `agendamento(servicoId, dataHora)` - Verificar conflitos
+
+**Dados sensíveis:**
+- `cliente.telefone` - Considerar mascarar em logs
+- `cliente.email` - Verificar LGPD
+
+---
+
+## Checklist Pós-Geração
+
+- [ ] Todas as entidades têm PK definida
+- [ ] Relacionamentos têm cardinalidade clara
+- [ ] Campos obrigatórios vs opcionais definidos
+- [ ] Diagrama ER gerado em Mermaid
+- [ ] Dúvidas listadas para validar com cliente
+- [ ] Índices sugeridos para queries principais
+- [ ] Salvar em `docs/04-modelo/modelo-dominio.md`