@maestro-ai/mcp-server 1.0.0 → 1.1.0

package/dist/content/workflows/mcp-feature.md

@@ -1,385 +1,385 @@
----
-description: Adicionar nova feature com fluxo estruturado (Análise → Implementação → Deploy)
----
-
-# /mcp-feature - Nova Feature MCP
-
-$ARGUMENTS
-
----
-
-## Objetivo
-
-Adicionar nova funcionalidade em projeto existente usando fluxo estruturado de 6 fases do MCP Maestro.
-
----
-
-## Quando Usar
-
-- Adicionar feature em produto já existente
-- Feature que impacta arquitetura, modelo ou API
-- Feature que precisa de análise de impacto
-
-**NÃO usar para:**
-- Correção de bugs → Use `/mcp-debug`
-- Melhorias de código → Use `/mcp-refactor`
-- Novo projeto → Use `/mcp-start`
-
----
-
-## Fluxo de 6 Fases
-
-```
-1. Análise de Impacto
-   ↓
-2. Refinamento de Requisitos
-   ↓
-3. Design/Arquitetura
-   ↓
-4. Implementação (Contrato → FE/BE paralelo → Integração)
-   ↓
-5. Testes
-   ↓
-6. Deploy
-```
-
----
-
-## Execução
-
-### Passo 1: Coleta de Informações
-
-**Perguntar ao usuário:**
-
-```markdown
-🆕 **Nova Feature**
-
-1. Descreva a funcionalidade a ser adicionada:
-   [Exemplo: Sistema de notificações push para usuários]
-
-2. Qual o impacto estimado?
-   - **baixo**: Pequena mudança, sem impacto em arquitetura
-   - **médio**: Mudança moderada, pode afetar alguns módulos
-   - **alto**: Grande mudança, afeta arquitetura core
-
-   Escolha: [baixo/médio/alto]
-```
-
-**Se forneceu argumentos:**
-
-```bash
-/mcp-feature Sistema de notificações push
-```
-
-→ Usar como descrição, pedir apenas impacto
-
----
-
-### Passo 2: Iniciar Fluxo de Feature
-
-```typescript
-await mcp_maestro_nova_feature({
-  descricao: "[descrição fornecida]",
-  impacto_estimado: "[baixo/médio/alto]"
-});
-```
-
-**MCP cria contexto separado para a feature e retorna:**
-
-```json
-{
-  "feature_id": "FEAT-001",
-  "fases": [
-    "Análise de Impacto",
-    "Refinamento",
-    "Design",
-    "Implementação",
-    "Testes",
-    "Deploy"
-  ],
-  "fase_atual": 1
-}
-```
-
----
-
-### Passo 3: Fase 1 - Análise de Impacto
-
-**Apresentar:**
-
-```markdown
-✅ **Fluxo de Feature Iniciado** (FEAT-001)
-
----
-
-🎯 **Fase 1/6: Análise de Impacto**
-🤖 **Especialista:** Arquitetura de Software
-
-## Análise de Impacto
-
-Antes de implementar, vamos analisar:
-
-1. **Modelo de Dados** - Novas entidades ou alterações?
-   - Tabelas afetadas:
-   - Novos campos:
-   - Relacionamentos:
-
-2. **APIs** - Novos endpoints ou mudanças?
-   - Endpoints novos:
-   - Endpoints modificados:
-   - Breaking changes:
-
-3. **Arquitetura** - Novos serviços ou refatorações?
-   - Novos módulos:
-   - Dependências:
-   - Integrações externas:
-
-4. **Frontend** - Componentes e páginas?
-   - Novos componentes:
-   - Páginas afetadas:
-   - Mudanças de UX:
-
-Vamos começar. Que **entidades** ou **tabelas** serão afetadas?
-```
-
----
-
-### Passo 4: Avançar Entre Fases (Frontend-First)
-
-**Usar `/mcp-next` para cada fase:**
-
-```
-Fase 1: Análise ✅
-  ↓ /mcp-next
-Fase 2: Requisitos ✅
-  ↓ /mcp-next
-Fase 3: Design ✅
-  ✓ Gera: Contrato de API (OpenAPI)
-  ↓ /mcp-next
-Fase 4: Implementação
-  ├─ US-001-CONT (Contrato) ✅
-  ├─ US-001-FE (Frontend) 🔄 ← Paralelo
-  ├─ US-001-BE (Backend) 🔄  ← Paralelo
-  └─ INT-001 (Integração) ⏳ ← Após FE+BE
-  ↓ /mcp-next
-Fase 5: Testes ✅
-  ↓ /mcp-next
-Fase 6: Deploy ✅
-```
-
-**Protocolo Frontend-First:**
-
-1. **Contrato primeiro** (CONT-001)
-   - Gera OpenAPI YAML
-   - Gera types para FE e BE
-   - Gera mock server
-
-2. **FE e BE em paralelo**
-   - Frontend desenvolve contra mock
-   - Backend implementa contrato
-   - Ambos seguem types gerados
-
-3. **Integração no final**
-   - Remove mocks
-   - Conecta FE com BE real
-   - Testes E2E
-
----
-
-### Passo 5: Implementar História
-
-**Na Fase 4 (Implementação):**
-
-```typescript
-// Contrato
-await mcp_maestro_implementar_historia({
-  historia_id: "US-001-CONT",
-  modo: "iniciar"
-});
-
-// Frontend (pode iniciar em paralelo após contrato)
-await mcp_maestro_implementar_historia({
-  historia_id: "US-001-FE",
-  modo: "iniciar"
-});
-
-// Backend (pode iniciar em paralelo após contrato)
-await mcp_maestro_implementar_historia({
-  historia_id: "US-001-BE",
-  modo: "iniciar"
-});
-
-// Integração (somente após FE e BE finalizados)
-await mcp_maestro_implementar_historia({
-  historia_id: "INT-001",
-  modo: "iniciar"
-});
-```
-
----
-
-## Exemplos de Uso
-
-### Exemplo 1: Feature Simples (Impacto Baixo)
-
-```
-User: /mcp-feature Adicionar filtro de data na listagem de pedidos
-
-AI: Qual o impacto estimado? (baixo/médio/alto)
-
-User: baixo
-
-AI: ✅ Fluxo de Feature Iniciado (FEAT-001)
-    
-    🎯 Fase 1/6: Análise de Impacto
-    
-    ## Análise Rápida
-    
-    Impacto baixo detectado. Feature simples:
-    - Frontend: Adicionar DatePicker component
-    - Backend: Adicionar parâmetro `?date_from` e `?date_to` em GET /orders
-    - Banco: Sem mudanças (usa índice existente)
-    
-    Correto? Vamos para refinamento?
-
-User: Sim
-
-AI: [Avança para Fase 2 com /mcp-next]
-```
-
-### Exemplo 2: Feature Complexa (Impacto Alto)
-
-```
-User: /mcp-feature Sistema de notificações push em tempo real
-
-AI: Qual o impacto estimado?
-
-User: alto
-
-AI: ✅ Fluxo de Feature Iniciado (FEAT-002)
-    
-    🎯 Fase 1/6: Análise de Impacto
-    
-    ## Análise Profunda Necessária
-    
-    Impacto alto detectado. Feature complexa:
-    
-    **Modelo de Dados:**
-    - Nova tabela: `notifications`
-    - Novo relacionamento: `users` ← `notifications`
-    
-    **Arquitetura:**
-    - Novo serviço: `NotificationService`
-    - Integração: Firebase Cloud Messaging (FCM)
-    - Infraestrutura: WebSocket server
-    
-    **Frontend:**
-    - Service Worker para push
-    - Componente NotificationBell
-    - Página de configurações
-    
-    **Backend:**
-    - Endpoints: POST /notifications, GET /notifications
-    - Job: NotificationDispatcherJob
-    
-    Vamos detalhar cada parte. Começando pelo modelo de dados...
-```
-
----
-
-## Comandos Relacionados
-
-```
-/mcp-feature [descrição]    → Inicia fluxo de feature
-/mcp-next                   → Avança entre fases
-/mcp-status                 → Ver status da feature
-/mcp-debug                  → Se bug aparecer durante feature
-```
-
----
-
-## Estrutura de Arquivos Gerados
-
-```
-docs/
-├── features/
-│   └── FEAT-001-filtro-data/
-│       ├── 01-impacto.md
-│       ├── 02-requisitos.md
-│       ├── 03-design.md
-│       ├── 04-contrato.yaml
-│       ├── 05-plano-testes.md
-│       └── 06-deploy-plan.md
-```
-
----
-
-## Regras Críticas
-
-### ✅ SEMPRE:
-
-1. Fazer análise de impacto antes de implementar
-2. Gerar contrato de API antes de FE/BE
-3. Testar integração após FE+BE prontos
-4. Documentar mudanças em ADR se impacto alto
-
-### ❌ NUNCA:
-
-1. Pular análise de impacto (Fase 1)
-2. Implementar FE/BE antes do contrato
-3. Fazer breaking changes sem versionamento de API
-4. Deploy sem testes E2E
-
----
-
-## Frontend-First Protocol
-
-> [!TIP]
-> **Para features que envolvem Frontend + Backend:**
-> 
-> ```
-> 1. CONT (Contrato API)
->    ├── Gera: openapi.yaml
->    ├── Gera: types (FE + BE)
->    └── Gera: Mock Server
->    
-> 2. Paralelo ⚡
->    ├── FE (contra mock)
->    └── BE (implementa contrato)
->    
-> 3. INT (Integração)
->    ├── Remove mocks
->    ├── Conecta FE ↔ BE real
->    └── Testes E2E
-> ```
-
----
-
-## Troubleshooting
-
-### Feature Muito Grande
-
-**Sintoma:** Fase de implementação com 20+ histórias
-
-**Solução:** Quebrar em features menores (épicos):
-
-```
-FEAT-001: Sistema de Notificações (Épico)
-├─ FEAT-001-A: Backend (API + Jobs)
-├─ FEAT-001-B: Frontend (UI)
-└─ FEAT-001-C: Integração (Push)
-
-Implementar um por vez com /mcp-feature
-```
-
-### Conflito com Feature em Andamento
-
-**Sintoma:** Duas features modificando mesma área
-
-**Solução:** Finalizar uma antes de iniciar outra, ou:
-
-```
-1. Criar branch separada para cada feature
-2. Definir ordem de merge (feature A → main → feature B merge)
-3. Coordenar com /mcp-status para ver dependências
-```
+---
+description: Adicionar nova feature com fluxo estruturado (Análise → Implementação → Deploy)
+---
+
+# /mcp-feature - Nova Feature MCP
+
+$ARGUMENTS
+
+---
+
+## Objetivo
+
+Adicionar nova funcionalidade em projeto existente usando fluxo estruturado de 6 fases do MCP Maestro.
+
+---
+
+## Quando Usar
+
+- Adicionar feature em produto já existente
+- Feature que impacta arquitetura, modelo ou API
+- Feature que precisa de análise de impacto
+
+**NÃO usar para:**
+- Correção de bugs → Use `/mcp-debug`
+- Melhorias de código → Use `/mcp-refactor`
+- Novo projeto → Use `/mcp-start`
+
+---
+
+## Fluxo de 6 Fases
+
+```
+1. Análise de Impacto
+   ↓
+2. Refinamento de Requisitos
+   ↓
+3. Design/Arquitetura
+   ↓
+4. Implementação (Contrato → FE/BE paralelo → Integração)
+   ↓
+5. Testes
+   ↓
+6. Deploy
+```
+
+---
+
+## Execução
+
+### Passo 1: Coleta de Informações
+
+**Perguntar ao usuário:**
+
+```markdown
+🆕 **Nova Feature**
+
+1. Descreva a funcionalidade a ser adicionada:
+   [Exemplo: Sistema de notificações push para usuários]
+
+2. Qual o impacto estimado?
+   - **baixo**: Pequena mudança, sem impacto em arquitetura
+   - **médio**: Mudança moderada, pode afetar alguns módulos
+   - **alto**: Grande mudança, afeta arquitetura core
+
+   Escolha: [baixo/médio/alto]
+```
+
+**Se forneceu argumentos:**
+
+```bash
+/mcp-feature Sistema de notificações push
+```
+
+→ Usar como descrição, pedir apenas impacto
+
+---
+
+### Passo 2: Iniciar Fluxo de Feature
+
+```typescript
+await mcp_maestro_nova_feature({
+  descricao: "[descrição fornecida]",
+  impacto_estimado: "[baixo/médio/alto]"
+});
+```
+
+**MCP cria contexto separado para a feature e retorna:**
+
+```json
+{
+  "feature_id": "FEAT-001",
+  "fases": [
+    "Análise de Impacto",
+    "Refinamento",
+    "Design",
+    "Implementação",
+    "Testes",
+    "Deploy"
+  ],
+  "fase_atual": 1
+}
+```
+
+---
+
+### Passo 3: Fase 1 - Análise de Impacto
+
+**Apresentar:**
+
+```markdown
+✅ **Fluxo de Feature Iniciado** (FEAT-001)
+
+---
+
+🎯 **Fase 1/6: Análise de Impacto**
+🤖 **Especialista:** Arquitetura de Software
+
+## Análise de Impacto
+
+Antes de implementar, vamos analisar:
+
+1. **Modelo de Dados** - Novas entidades ou alterações?
+   - Tabelas afetadas:
+   - Novos campos:
+   - Relacionamentos:
+
+2. **APIs** - Novos endpoints ou mudanças?
+   - Endpoints novos:
+   - Endpoints modificados:
+   - Breaking changes:
+
+3. **Arquitetura** - Novos serviços ou refatorações?
+   - Novos módulos:
+   - Dependências:
+   - Integrações externas:
+
+4. **Frontend** - Componentes e páginas?
+   - Novos componentes:
+   - Páginas afetadas:
+   - Mudanças de UX:
+
+Vamos começar. Que **entidades** ou **tabelas** serão afetadas?
+```
+
+---
+
+### Passo 4: Avançar Entre Fases (Frontend-First)
+
+**Usar `/mcp-next` para cada fase:**
+
+```
+Fase 1: Análise ✅
+  ↓ /mcp-next
+Fase 2: Requisitos ✅
+  ↓ /mcp-next
+Fase 3: Design ✅
+  ✓ Gera: Contrato de API (OpenAPI)
+  ↓ /mcp-next
+Fase 4: Implementação
+  ├─ US-001-CONT (Contrato) ✅
+  ├─ US-001-FE (Frontend) 🔄 ← Paralelo
+  ├─ US-001-BE (Backend) 🔄  ← Paralelo
+  └─ INT-001 (Integração) ⏳ ← Após FE+BE
+  ↓ /mcp-next
+Fase 5: Testes ✅
+  ↓ /mcp-next
+Fase 6: Deploy ✅
+```
+
+**Protocolo Frontend-First:**
+
+1. **Contrato primeiro** (CONT-001)
+   - Gera OpenAPI YAML
+   - Gera types para FE e BE
+   - Gera mock server
+
+2. **FE e BE em paralelo**
+   - Frontend desenvolve contra mock
+   - Backend implementa contrato
+   - Ambos seguem types gerados
+
+3. **Integração no final**
+   - Remove mocks
+   - Conecta FE com BE real
+   - Testes E2E
+
+---
+
+### Passo 5: Implementar História
+
+**Na Fase 4 (Implementação):**
+
+```typescript
+// Contrato
+await mcp_maestro_implementar_historia({
+  historia_id: "US-001-CONT",
+  modo: "iniciar"
+});
+
+// Frontend (pode iniciar em paralelo após contrato)
+await mcp_maestro_implementar_historia({
+  historia_id: "US-001-FE",
+  modo: "iniciar"
+});
+
+// Backend (pode iniciar em paralelo após contrato)
+await mcp_maestro_implementar_historia({
+  historia_id: "US-001-BE",
+  modo: "iniciar"
+});
+
+// Integração (somente após FE e BE finalizados)
+await mcp_maestro_implementar_historia({
+  historia_id: "INT-001",
+  modo: "iniciar"
+});
+```
+
+---
+
+## Exemplos de Uso
+
+### Exemplo 1: Feature Simples (Impacto Baixo)
+
+```
+User: /mcp-feature Adicionar filtro de data na listagem de pedidos
+
+AI: Qual o impacto estimado? (baixo/médio/alto)
+
+User: baixo
+
+AI: ✅ Fluxo de Feature Iniciado (FEAT-001)
+    
+    🎯 Fase 1/6: Análise de Impacto
+    
+    ## Análise Rápida
+    
+    Impacto baixo detectado. Feature simples:
+    - Frontend: Adicionar DatePicker component
+    - Backend: Adicionar parâmetro `?date_from` e `?date_to` em GET /orders
+    - Banco: Sem mudanças (usa índice existente)
+    
+    Correto? Vamos para refinamento?
+
+User: Sim
+
+AI: [Avança para Fase 2 com /mcp-next]
+```
+
+### Exemplo 2: Feature Complexa (Impacto Alto)
+
+```
+User: /mcp-feature Sistema de notificações push em tempo real
+
+AI: Qual o impacto estimado?
+
+User: alto
+
+AI: ✅ Fluxo de Feature Iniciado (FEAT-002)
+    
+    🎯 Fase 1/6: Análise de Impacto
+    
+    ## Análise Profunda Necessária
+    
+    Impacto alto detectado. Feature complexa:
+    
+    **Modelo de Dados:**
+    - Nova tabela: `notifications`
+    - Novo relacionamento: `users` ← `notifications`
+    
+    **Arquitetura:**
+    - Novo serviço: `NotificationService`
+    - Integração: Firebase Cloud Messaging (FCM)
+    - Infraestrutura: WebSocket server
+    
+    **Frontend:**
+    - Service Worker para push
+    - Componente NotificationBell
+    - Página de configurações
+    
+    **Backend:**
+    - Endpoints: POST /notifications, GET /notifications
+    - Job: NotificationDispatcherJob
+    
+    Vamos detalhar cada parte. Começando pelo modelo de dados...
+```
+
+---
+
+## Comandos Relacionados
+
+```
+/mcp-feature [descrição]    → Inicia fluxo de feature
+/mcp-next                   → Avança entre fases
+/mcp-status                 → Ver status da feature
+/mcp-debug                  → Se bug aparecer durante feature
+```
+
+---
+
+## Estrutura de Arquivos Gerados
+
+```
+docs/
+├── features/
+│   └── FEAT-001-filtro-data/
+│       ├── 01-impacto.md
+│       ├── 02-requisitos.md
+│       ├── 03-design.md
+│       ├── 04-contrato.yaml
+│       ├── 05-plano-testes.md
+│       └── 06-deploy-plan.md
+```
+
+---
+
+## Regras Críticas
+
+### ✅ SEMPRE:
+
+1. Fazer análise de impacto antes de implementar
+2. Gerar contrato de API antes de FE/BE
+3. Testar integração após FE+BE prontos
+4. Documentar mudanças em ADR se impacto alto
+
+### ❌ NUNCA:
+
+1. Pular análise de impacto (Fase 1)
+2. Implementar FE/BE antes do contrato
+3. Fazer breaking changes sem versionamento de API
+4. Deploy sem testes E2E
+
+---
+
+## Frontend-First Protocol
+
+> [!TIP]
+> **Para features que envolvem Frontend + Backend:**
+> 
+> ```
+> 1. CONT (Contrato API)
+>    ├── Gera: openapi.yaml
+>    ├── Gera: types (FE + BE)
+>    └── Gera: Mock Server
+>    
+> 2. Paralelo ⚡
+>    ├── FE (contra mock)
+>    └── BE (implementa contrato)
+>    
+> 3. INT (Integração)
+>    ├── Remove mocks
+>    ├── Conecta FE ↔ BE real
+>    └── Testes E2E
+> ```
+
+---
+
+## Troubleshooting
+
+### Feature Muito Grande
+
+**Sintoma:** Fase de implementação com 20+ histórias
+
+**Solução:** Quebrar em features menores (épicos):
+
+```
+FEAT-001: Sistema de Notificações (Épico)
+├─ FEAT-001-A: Backend (API + Jobs)
+├─ FEAT-001-B: Frontend (UI)
+└─ FEAT-001-C: Integração (Push)
+
+Implementar um por vez com /mcp-feature
+```
+
+### Conflito com Feature em Andamento
+
+**Sintoma:** Duas features modificando mesma área
+
+**Solução:** Finalizar uma antes de iniciar outra, ou:
+
+```
+1. Criar branch separada para cada feature
+2. Definir ordem de merge (feature A → main → feature B merge)
+3. Coordenar com /mcp-status para ver dependências
+```