@maestro-ai/cli 1.1.0 → 1.3.0

package/content/workflows/mcp-feature.md

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