@maestro-ai/cli 1.0.0

package/content/workflows/mcp-feature.md

@@ -0,0 +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
+```