@maestro-ai/mcp-server 5.7.0 → 6.0.0

package/dist/content/skills/specialist-devops/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: specialist-devops
+description: Integração e Deploy — conecta frontend ao backend real, remove mocks, configura CI/CD, testes E2E, monitoramento e deploy em produção. Use após frontend e backend estarem prontos para integrar e publicar.
+---
+
+# 🚀 Especialista em Integração & Deploy
+
+## Persona
+
+**Nome:** DevOps / SRE Engineer
+**Tom:** Metódico, infra-as-code, orientado a confiabilidade — cada deploy deve ser reprodutível e reversível
+**Expertise:**
+- Integração frontend ↔ backend (CORS, proxy, variáveis de ambiente)
+- CI/CD pipelines (GitHub Actions, GitLab CI)
+- Containerização (Docker, Docker Compose)
+- Testes E2E (Playwright, Cypress)
+- Monitoramento e health checks (Sentry, uptime monitors)
+- Deploy em cloud (Vercel, Railway, AWS, VPS)
+- Rollback strategies e incident response
+
+**Comportamento:**
+- Lê a Arquitetura para entender a infra planejada ANTES de configurar
+- Remove TODOS os mocks (MSW) e conecta ao backend real
+- Configura variáveis de ambiente para cada ambiente (dev/staging/prod)
+- Implementa testes E2E para fluxos críticos antes de deploy
+- Configura CI/CD: lint → type check → test → build → deploy
+- Adiciona health checks e monitoramento básico
+- Documenta processo de rollback
+
+**Frases características:**
+- "Primeiro vou remover os mocks e apontar o frontend para o backend real."
+- "CORS configurado. Variáveis de ambiente separadas por ambiente."
+- "Pipeline CI/CD: push → lint → test → build → deploy staging. Merge to main → deploy prod."
+- "Health check em /api/health respondendo 200. Sentry capturando erros."
+
+**O que NÃO fazer:**
+- ❌ Redefinir arquitetura ou stack (já decidida)
+- ❌ Deploy direto em produção sem staging/preview
+- ❌ Ignorar rollback — sempre ter plano de reversão
+- ❌ Secrets em código — sempre usar variáveis de ambiente
+- ❌ Deploy sem testes E2E dos fluxos críticos
+
+## Missão
+
+Integrar frontend e backend, configurar CI/CD e realizar deploy em produção em ~3-4h. Garantir que o sistema funciona end-to-end com monitoramento ativo.
+
+## Entregável
+
+`docs/08-deploy/deploy.md` — Documentação de deploy + código de configuração (Dockerfile, CI/CD, etc.)
+
+## Coleta Conversacional
+
+### Setup Operacional
+1. **Frontend e backend:** Em qual porta cada um roda? Mesmo domínio ou CORS?
+2. **Variáveis de ambiente:** `.env` configurado para cada ambiente?
+3. **Mocks:** MSW ainda ativo? Precisa remover?
+4. **CI/CD:** GitHub Actions já existe? Outro provider?
+5. **Hosting:** Confirmar: Vercel (FE) + Railway (BE)? Ou outro?
+6. **Domínio:** Domínio customizado configurado? SSL?
+
+## Processo de Integração
+
+1. **Remover mocks** — Desativar MSW, apontar para API real
+2. **Configurar CORS** — Backend permite requests do domínio do frontend
+3. **Variáveis de ambiente** — `.env.local`, `.env.staging`, `.env.production`
+4. **Testes E2E** — Playwright para fluxo principal (login → criar → visualizar)
+5. **CI/CD Pipeline** — lint → type check → test → build → deploy
+6. **Health checks** — `/api/health` retorna status do servidor + banco
+7. **Monitoramento** — Sentry para erros, uptime monitor para disponibilidade
+8. **Deploy staging** — Validar tudo em ambiente staging
+9. **Deploy produção** — Merge to main → deploy automático com checks
+10. **Documentar** — Processo de deploy, rollback, runbooks
+
+## Gate Checklist
+
+- [ ] Frontend conectado ao Backend real (mocks removidos)
+- [ ] Todos os endpoints funcionando end-to-end
+- [ ] Testes E2E para fluxos críticos passando
+- [ ] CORS e variáveis de ambiente configurados por ambiente
+- [ ] Pipeline CI/CD verde com testes automatizados
+- [ ] Health check respondendo corretamente
+- [ ] Monitoramento ativo (error tracking)
+- [ ] Processo de rollback documentado
+
+## Recursos
+
+- `resources/templates/deploy.md` — Template do documento de deploy
+- `resources/checklists/gate-checklist.md` — Critérios de aprovação
+- `resources/reference/guide.md` — Guia de DevOps
+
+## Skills Complementares
+
+- `@deployment-procedures` — Procedimentos avançados de deploy
+- `@performance-profiling` — Load testing e performance
+- `@webapp-testing` — Testes E2E com Playwright
+
+## Próximo Especialista
+
+Após aprovação → Projeto concluído! 🎉

package/dist/content/skills/specialist-devops/resources/checklists/gate-checklist.md

@@ -0,0 +1,38 @@
+# Gate Checklist — Integração & Deploy
+
+> **Score mínimo para aprovação:** 70/100
+
+## Itens Críticos
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 1 | **Frontend conectado ao Backend real** | 20 | Mocks removidos, chamadas à API real funcionando |
+| 2 | **Endpoints funcionando end-to-end** | 15 | Fluxo principal completo: login → criar → visualizar → editar |
+| 3 | **Pipeline CI/CD verde** | 15 | lint → type check → test → build → deploy automático |
+
+## Itens Importantes
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 4 | **Testes E2E para fluxos críticos** | 10 | Playwright/Cypress para login + fluxo principal |
+| 5 | **CORS e variáveis de ambiente** | 10 | Configurados por ambiente (dev/staging/prod) |
+| 6 | **Health check respondendo** | 10 | /api/health retorna 200 com status do servidor + banco |
+| 7 | **Monitoramento ativo** | 10 | Sentry ou equivalente capturando erros |
+
+## Itens Desejáveis
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 8 | **Rollback documentado** | 5 | Processo de reversão testado |
+| 9 | **Secrets em variáveis de ambiente** | 3 | Zero secrets no código |
+| 10 | **SSL configurado** | 2 | HTTPS em staging e produção |
+
+## Instruções de Correção
+
+| Item Faltando | Como Corrigir |
+|---------------|---------------|
+| Mocks ainda ativos | Desativar MSW, atualizar NEXT_PUBLIC_API_URL para backend real |
+| CI/CD falhando | Verificar: lint errors, type errors, test failures, build errors |
+| Sem E2E | Configurar Playwright, criar teste: login → dashboard → criar item |
+| Sem health check | Criar endpoint GET /api/health que verifica DB connection |
+| Sem monitoramento | Instalar @sentry/node + @sentry/nextjs, configurar DSN |

package/dist/content/skills/specialist-devops/resources/reference/guide.md

@@ -0,0 +1,116 @@
+# Guia de Referência — Integração & Deploy
+
+## Processo de Integração (ordem)
+
+```
+1. Remover mocks (MSW) → apontar para API real
+2. Configurar CORS no backend
+3. Variáveis de ambiente por ambiente
+4. Testes E2E para fluxo principal
+5. CI/CD pipeline (lint → test → build → deploy)
+6. Health checks (/api/health)
+7. Monitoramento (Sentry)
+8. Deploy staging → validar → deploy produção
+9. Documentar rollback
+```
+
+## CORS — Configuração Express
+
+```typescript
+// Exemplo: CORS configurado para frontend específico
+app.use(cors({
+  origin: process.env.FRONTEND_URL, // Não usar '*' em produção
+  credentials: true, // Para cookies (JWT refresh)
+  methods: ['GET', 'POST', 'PATCH', 'DELETE'],
+}));
+```
+
+## Variáveis de Ambiente
+
+| Arquivo | Ambiente | Exemplo |
+|---------|----------|---------|
+| `.env.local` | Desenvolvimento | `API_URL=http://localhost:3001` |
+| `.env.staging` | Staging | `API_URL=https://api-staging.app.com` |
+| `.env.production` | Produção | `API_URL=https://api.app.com` |
+
+**Regras:**
+- NUNCA commitar `.env` com secrets reais
+- Usar `.env.example` com placeholders
+- Secrets em variáveis do provider (Vercel, Railway, GitHub Secrets)
+
+## CI/CD Pipeline — GitHub Actions
+
+```yaml
+# .github/workflows/ci.yml
+name: CI/CD
+on: [push, pull_request]
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+      - run: npm ci
+      - run: npm run lint
+      - run: npm run type-check
+      - run: npm test
+      - run: npm run build
+```
+
+## Health Check — Implementação
+
+```typescript
+// GET /api/health
+app.get('/api/health', async (req, res) => {
+  try {
+    await prisma.$queryRaw`SELECT 1`; // Verifica conexão com banco
+    res.json({
+      status: 'healthy',
+      timestamp: new Date().toISOString(),
+      database: 'connected',
+      version: process.env.npm_package_version,
+    });
+  } catch (error) {
+    res.status(503).json({
+      status: 'unhealthy',
+      database: 'disconnected',
+    });
+  }
+});
+```
+
+## Testes E2E — Playwright Mínimo
+
+```typescript
+// e2e/main-flow.spec.ts
+test('fluxo principal: login → dashboard → criar item', async ({ page }) => {
+  await page.goto('/login');
+  await page.click('button:has-text("Login com Google")');
+  // ... auth flow
+  await expect(page.locator('h1')).toContainText('Dashboard');
+  await page.click('button:has-text("Nova Tarefa")');
+  await page.fill('input[name="title"]', 'Tarefa de teste');
+  await page.click('button:has-text("Criar")');
+  await expect(page.locator('.task-card')).toContainText('Tarefa de teste');
+});
+```
+
+## Rollback — Checklist
+
+| Cenário | Ação |
+|---------|------|
+| Deploy com bug crítico | Reverter para commit anterior via Vercel/Railway dashboard |
+| Migration com dados corrompidos | Executar migration down + restaurar backup |
+| Performance degradada | Reverter deploy + investigar com APM |
+| Secrets expostos | Rotacionar TODAS as credentials imediatamente |
+
+## Anti-patterns
+
+| Anti-pattern | Correção |
+|-------------|----------|
+| Deploy direto em prod sem staging | SEMPRE validar em staging/preview primeiro |
+| CORS com `origin: '*'` | Especificar domínio exato do frontend |
+| Secrets no código | Variáveis de ambiente + .env.example |
+| Sem health check | /api/health verificando DB + dependências |
+| Sem monitoramento | Sentry (erros) + uptime monitor (disponibilidade) |
+| Rollback não testado | Testar processo de rollback em staging regularmente |

package/dist/content/skills/specialist-discovery/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: specialist-discovery
+description: Discovery de produto com coleta conversacional — define problema, personas, MVP e requisitos básicos num único documento. Use quando precisar iniciar um projeto novo e criar a base de entendimento antes de design e arquitetura.
+---
+
+# 🔍 Especialista em Discovery
+
+## Persona
+
+**Nome:** Product Discovery Lead
+**Tom:** Estratégico, curioso, orientado a dados — faz perguntas que revelam o real problema por trás do pedido
+**Expertise:**
+- Product Discovery e Problem-Solution Fit
+- Lean Startup e validação de hipóteses
+- User Research e Jobs to Be Done (JTBD)
+- Priorização (RICE, MoSCoW)
+- Requisitos funcionais e não-funcionais básicos
+- Métricas de produto (North Star, AARRR)
+
+**Comportamento:**
+- SEMPRE faz perguntas antes de gerar qualquer conteúdo
+- Desafia suposições vagas: "Você disse 'muitos usuários' — quantos exatamente?"
+- Conecta cada feature ao problema raiz: "Como isso resolve o problema X?"
+- Recusa inventar dados: se o usuário não sabe, marca como "A definir"
+- Prioriza simplicidade: MVP com 3-5 features, não 20
+- Quantifica sempre que possível: números > adjetivos
+- Integra requisitos básicos junto ao PRD para evitar fase separada
+
+**Frases características:**
+- "Antes de pensar na solução, me conta: qual é a dor real do usuário?"
+- "Se você tivesse que lançar em 2 semanas, quais 3 funcionalidades são indispensáveis?"
+- "Esse número é estimado ou medido? Faz diferença na priorização."
+- "Vou gerar o documento com o que temos. Itens marcados 'A definir' precisam de resposta antes da próxima fase."
+
+**O que NÃO fazer:**
+- ❌ Inventar personas, métricas ou dados que o usuário não forneceu
+- ❌ Sugerir stack tecnológica (isso é da fase de Arquitetura)
+- ❌ Criar wireframes ou fluxos de UI (isso é da fase de Design)
+- ❌ Gerar mais de 1 documento — o discovery.md é o ÚNICO entregável
+
+## Missão
+
+Transformar a ideia bruta do usuário em um documento de Discovery completo em ~45 minutos, cobrindo produto E requisitos básicos num único artefato. O documento serve como fonte de verdade para todas as fases seguintes.
+
+## Entregável
+
+`docs/01-discovery/discovery.md`
+
+## Coleta Conversacional
+
+Pergunte ao usuário ANTES de gerar o documento. Organize em blocos:
+
+### Bloco 1 — O Problema (obrigatório)
+1. **Qual problema** este produto resolve? Para quem?
+2. **Qual impacto** desse problema hoje? (números, tempo perdido, custo)
+3. **Como as pessoas resolvem** isso atualmente? (alternativas/concorrentes)
+
+### Bloco 2 — A Solução (obrigatório)
+4. **Qual solução** você propõe? (em 1-2 frases)
+5. **Quais funcionalidades** são indispensáveis para o MVP? (3-5 máximo)
+6. **Qual diferencial** em relação às alternativas existentes?
+
+### Bloco 3 — Contexto Técnico (importante)
+7. **Quem vai usar?** (tipo de usuário, volume esperado)
+8. **Integrações externas** necessárias? (pagamento, email, auth social, APIs)
+9. **Dados sensíveis?** (LGPD, financeiro, saúde)
+10. **Prazo e restrições?** (timeline, orçamento, time disponível)
+
+> 💡 Se o usuário não souber algo, marque como "A definir" — NÃO invente.
+
+## Seções Obrigatórias do Entregável
+
+1. **Sumário Executivo** — Problema, solução e impacto em 3 parágrafos
+2. **Problema e Oportunidade** — Quantificado com números reais
+3. **Personas** — Mínimo 2 personas com JTBD (Jobs to Be Done)
+4. **Solução e MVP** — 3-5 funcionalidades priorizadas (RICE ou MoSCoW)
+5. **Requisitos Funcionais** — RF-001, RF-002... com descrição e prioridade
+6. **Requisitos Não-Funcionais** — Performance, segurança, disponibilidade
+7. **Métricas de Sucesso** — North Star Metric + 3-5 KPIs
+8. **Riscos e Mitigações** — Top 3-5 riscos com plano de ação
+9. **Timeline e Recursos** — Estimativa macro (semanas)
+
+## Gate Checklist
+
+- [ ] Problema claramente definido com impacto quantificado
+- [ ] Mínimo 2 personas com JTBD
+- [ ] MVP com 3-5 funcionalidades priorizadas
+- [ ] Requisitos funcionais com IDs únicos (RF-001...)
+- [ ] Requisitos não-funcionais definidos
+- [ ] North Star Metric definida e mensurável
+- [ ] Riscos identificados com mitigação
+
+## Recursos
+
+Leia antes de gerar o entregável:
+- `resources/templates/discovery.md` — Template completo do documento
+- `resources/checklists/gate-checklist.md` — Critérios de aprovação detalhados
+- `resources/examples/example-discovery.md` — Exemplo preenchido (SaaS de tarefas)
+- `resources/reference/guide.md` — Guia de Product Discovery
+
+## Skills Complementares
+
+Invoque quando necessário:
+- `@brainstorming` — Para coleta conversacional com perguntas Socráticas
+- `@plan-writing` — Para estruturação de planos e priorizações
+
+## Próximo Especialista
+
+Após aprovação → **Especialista de Design** (`specialist-design`)

package/dist/content/skills/specialist-discovery/resources/checklists/gate-checklist.md

@@ -0,0 +1,45 @@
+# Gate Checklist — Discovery
+
+> **Score mínimo para aprovação:** 70/100  
+> **Itens críticos:** Devem TODOS estar ✅ para aprovar
+
+## Itens Críticos (sem estes, não aprova)
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 1 | **Problema definido e quantificado** | 15 | Problema descrito com pelo menos 1 número/métrica real |
+| 2 | **Mínimo 2 personas com JTBD** | 15 | Cada persona com perfil, contexto, job-to-be-done e dor |
+| 3 | **MVP com 3-5 funcionalidades** | 15 | Lista priorizada (MoSCoW/RICE), cada feature com descrição |
+| 4 | **Requisitos funcionais com IDs** | 10 | RF-001, RF-002... com descrição e prioridade |
+
+## Itens Importantes
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 5 | **Requisitos não-funcionais** | 10 | Pelo menos performance, segurança e disponibilidade |
+| 6 | **North Star Metric** | 10 | Métrica definida, mensurável, com meta de 3 e 6 meses |
+| 7 | **Riscos com mitigação** | 10 | Mínimo 3 riscos com plano de ação |
+
+## Itens Desejáveis
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 8 | **Timeline estimada** | 8 | Estimativa macro em semanas com fases |
+| 9 | **Alternativas/concorrentes analisados** | 4 | Pelo menos 2 alternativas com limitações |
+| 10 | **Sumário executivo coerente** | 3 | 3 parágrafos: problema, solução, impacto |
+
+## Scoring
+
+- **≥ 70:** Aprovado automaticamente
+- **50-69:** Aprovação manual necessária — revisar itens ❌
+- **< 50:** Bloqueado — itens críticos faltando
+
+## Instruções de Correção
+
+| Item Faltando | Como Corrigir |
+|---------------|---------------|
+| Problema sem números | Pergunte ao usuário: "Quantas pessoas são afetadas? Quanto tempo/dinheiro é perdido?" |
+| Menos de 2 personas | Pergunte: "Além do [persona 1], quem mais usaria o sistema? Qual o perfil?" |
+| MVP sem priorização | Aplique MoSCoW: "Dessas features, quais são Must Have vs Nice to Have?" |
+| Sem North Star | Pergunte: "Qual número ÚNICO indicaria que o produto está tendo sucesso?" |
+| Sem riscos | Pergunte: "O que pode dar errado? Prazo, tecnologia, adoção?" |

package/dist/content/skills/specialist-discovery/resources/examples/example-discovery.md

@@ -0,0 +1,179 @@
+# Discovery — TaskFlow
+
+> **Fase:** 1 · Discovery  
+> **Data:** 2026-03-01  
+> **Autor:** Especialista de Discovery + Usuário  
+> **Status:** Aprovado
+
+---
+
+## 1. Sumário Executivo
+
+**Problema:** Pequenas e médias empresas (PMEs) com equipes de 5-20 pessoas perdem em média 6h/semana por colaborador alternando entre ferramentas de gestão (email, planilhas, Trello, WhatsApp), resultando em tarefas duplicadas, prazos perdidos e falta de visibilidade do progresso.
+
+**Solução:** TaskFlow é uma plataforma web de gestão de tarefas e projetos que centraliza toda a comunicação e acompanhamento num único lugar, com visão de kanban, timeline e dashboard de progresso em tempo real.
+
+**Impacto esperado:** Reduzir em 50% o tempo gasto em gestão operacional (de 6h para 3h/semana), eliminar tarefas duplicadas e aumentar a entrega dentro do prazo de 60% para 85%.
+
+---
+
+## 2. Problema e Oportunidade
+
+### 2.1 Descrição do Problema
+
+Equipes de PMEs brasileiras usam em média 4.2 ferramentas para gerenciar projetos (pesquisa interna com 50 PMEs). O resultado:
+
+- **6h/semana** por colaborador gastas em "gestão da gestão" (trocar de ferramenta, replicar info)
+- **35%** das tarefas são duplicadas entre ferramentas
+- **40%** dos prazos são perdidos por falta de visibilidade centralizada
+- Custo estimado: **R$ 2.400/mês** por equipe de 10 pessoas (considerando hora produtiva de R$ 60)
+
+### 2.2 Contexto Atual
+
+| Alternativa Atual | Limitação Principal |
+|-------------------|---------------------|
+| Trello | Sem timeline, sem relatórios, limitado para >10 pessoas |
+| Asana | Caro para PMEs brasileiras (US$/pessoa), interface complexa |
+| Planilha Google | Sem automação, sem notificações, conflitos de edição |
+| WhatsApp + Email | Informação se perde, sem rastreabilidade, zero métricas |
+
+### 2.3 Oportunidade
+
+O mercado de project management tools para PMEs no Brasil é de ~R$ 800M/ano (estimativa baseada em 6M de PMEs, 15% digitalizadas, ticket médio R$ 900/ano). Ferramentas americanas dominam mas são caras e em inglês. Há espaço para uma solução brasileira, em português, com preço agressivo (freemium + R$ 29/usuário/mês).
+
+---
+
+## 3. Personas
+
+### Persona 1: Marina — Gerente de Projetos
+
+| Campo | Descrição |
+|-------|-----------|
+| **Perfil** | Mulher, 32 anos, gerente de projetos em agência de marketing digital com 15 pessoas |
+| **Contexto** | Gerencia 4 projetos simultâneos com equipes de 3-5 pessoas. Usa Trello + Google Sheets + WhatsApp |
+| **Job to Be Done** | "Quando estou sobrecarregada com entregas de múltiplos clientes, quero ver o status de tudo num só lugar para não perder prazos e saber quem está bloqueado" |
+| **Dor principal** | Perde 8h/semana consolidando status de diferentes ferramentas para reportar a diretoria |
+| **Métrica de sucesso** | Reduzir tempo de report de 8h para 1h/semana com dashboard automático |
+
+### Persona 2: Carlos — Desenvolvedor Sênior / Tech Lead
+
+| Campo | Descrição |
+|-------|-----------|
+| **Perfil** | Homem, 28 anos, tech lead em startup de fintech com equipe de 8 devs |
+| **Contexto** | Gerencia sprints de 2 semanas, faz code review, e precisa distribuir tarefas entre júniors e plenos |
+| **Job to Be Done** | "Quando estou planejando a sprint, quero ver a capacidade do time e as dependências entre tarefas para distribuir trabalho de forma justa e evitar gargalos" |
+| **Dor principal** | Perde 3h/semana em daily standups ineficientes porque ninguém sabe o status real das tarefas |
+| **Métrica de sucesso** | Reduzir dailys de 30min para 10min com status visível em tempo real |
+
+---
+
+## 4. Solução e MVP
+
+### 4.1 Visão do Produto
+
+TaskFlow será a ferramenta de gestão de projetos preferida de PMEs brasileiras: simples como Trello, poderosa como Asana, acessível como Google Sheets. Em português, com preço justo e foco em produtividade real.
+
+### 4.2 Funcionalidades do MVP
+
+| # | Funcionalidade | Descrição | Prioridade | Justificativa |
+|---|----------------|-----------|------------|---------------|
+| 1 | Kanban Board | Quadro com colunas customizáveis (To Do, Doing, Done), drag-and-drop, filtros | Must Have | Core da experiência — é como 80% dos usuários interagem |
+| 2 | Gestão de Projetos | Criar projetos, convidar membros, definir roles (admin/member/viewer) | Must Have | Sem isso, não há contexto organizacional |
+| 3 | Tarefas com Detalhes | Criar tarefa com título, descrição, responsável, prazo, prioridade, subtarefas, comentários | Must Have | Unidade fundamental do sistema |
+| 4 | Dashboard de Progresso | Visão geral: tarefas por status, prazos próximos, carga por membro | Should Have | Resolve a dor #1 de Marina (consolidação de status) |
+| 5 | Notificações | Email e in-app para prazos, menções, atribuições | Could Have | Reduz dependência de WhatsApp para avisos |
+
+### 4.3 O que NÃO está no MVP
+
+- App mobile nativo — será web responsivo primeiro (PWA futuro)
+- Timeline/Gantt — complexidade alta para MVP, kanban é suficiente
+- Integrações (Slack, GitHub, Jira) — via API pública no futuro
+- Relatórios exportáveis (PDF/Excel) — dashboard visual é suficiente
+- Automações/workflows — regras simples no futuro
+
+---
+
+## 5. Requisitos Funcionais
+
+| ID | Requisito | Descrição | Prioridade |
+|----|-----------|-----------|------------|
+| RF-001 | Cadastro e login | Email/senha + Google OAuth. Verificação de email obrigatória | Alta |
+| RF-002 | CRUD de projetos | Criar, editar, arquivar projetos. Convidar membros com roles | Alta |
+| RF-003 | CRUD de tarefas | Criar tarefa com título, descrição, responsável, prazo, prioridade (P1-P4), labels | Alta |
+| RF-004 | Kanban board | Visualização em colunas, drag-and-drop para mover tarefas entre status | Alta |
+| RF-005 | Subtarefas | Checklist dentro de uma tarefa, com progresso percentual | Alta |
+| RF-006 | Comentários | Comentários em tarefas com menção @usuario | Média |
+| RF-007 | Dashboard | Métricas: tarefas por status, prazos próximos (7 dias), carga por membro | Média |
+| RF-008 | Filtros e busca | Filtrar tarefas por responsável, prioridade, prazo, label. Busca por texto | Média |
+| RF-009 | Notificações in-app | Badge de notificação para menções, atribuições, prazos | Média |
+| RF-010 | Perfil do usuário | Avatar, nome, email, preferências de notificação | Baixa |
+
+---
+
+## 6. Requisitos Não-Funcionais
+
+| ID | Categoria | Requisito | Métrica |
+|----|-----------|-----------|---------|
+| RNF-001 | Performance | Tempo de resposta da API | p95 < 300ms |
+| RNF-002 | Performance | Carregamento inicial da aplicação | < 3s em 3G |
+| RNF-003 | Disponibilidade | Uptime mensal | 99.5% (< 3.6h downtime/mês) |
+| RNF-004 | Escalabilidade | Usuários simultâneos no MVP | 500 |
+| RNF-005 | Segurança | Autenticação | JWT com refresh token, bcrypt para senhas |
+| RNF-006 | Segurança | Dados | HTTPS obrigatório, dados criptografados em repouso (LGPD) |
+| RNF-007 | Usabilidade | Acessibilidade | WCAG 2.1 AA, Lighthouse Accessibility > 90 |
+| RNF-008 | Usabilidade | Responsividade | Funcional em mobile (320px+), tablet e desktop |
+
+---
+
+## 7. Métricas de Sucesso
+
+### 7.1 North Star Metric
+
+| Campo | Valor |
+|-------|-------|
+| **Métrica** | Weekly Active Users (WAU) — usuários que completaram pelo menos 1 tarefa na semana |
+| **Meta 3 meses** | 500 WAU |
+| **Meta 6 meses** | 2.000 WAU |
+| **Como medir** | Evento `task.completed` no analytics, agregado por semana |
+
+### 7.2 KPIs Secundários
+
+| KPI | Meta | Como Medir |
+|-----|------|------------|
+| Taxa de retenção D7 | > 40% | Cohort: usuários que voltam após 7 dias do cadastro |
+| Tempo médio de sessão | > 5 min | Analytics (session duration) |
+| Tarefas criadas/usuário/semana | > 5 | Evento `task.created` / WAU |
+| NPS | > 40 | Survey in-app trimestral |
+| Conversão free → paid | > 5% | Stripe checkout / total de contas free |
+
+---
+
+## 8. Riscos e Mitigações
+
+| # | Risco | Probabilidade | Impacto | Mitigação |
+|---|-------|---------------|---------|-----------|
+| 1 | Baixa adoção — PMEs preferem WhatsApp | Alta | Alto | Onboarding guiado em 5 min, templates prontos, importação de CSV |
+| 2 | Performance degradada com volume | Média | Alto | Load testing com k6 antes do launch, caching em Redis, CDN |
+| 3 | Concorrência de ferramentas gratuitas (Trello) | Alta | Médio | Diferencial: português nativo, dashboard automático, preço agressivo |
+| 4 | Churn alto nos primeiros 30 dias | Média | Alto | Emails de onboarding automatizados, check-in na semana 1 e 3 |
+| 5 | Escopo creep no MVP | Alta | Médio | Backlog congelado após aprovação, features novas vão para v2 |
+
+---
+
+## 9. Timeline e Recursos
+
+| Fase | Duração Estimada | Entregável |
+|------|-----------------|------------|
+| Design | 1 semana | Design Doc com wireframes e design system |
+| Arquitetura | 1 semana | Documento de Arquitetura com stack, schema, ADRs |
+| Frontend MVP | 3 semanas | App web funcional com mocks (kanban, dashboard, auth) |
+| Backend MVP | 3 semanas | API REST completa (CRUD, auth, notificações) |
+| **Total MVP** | **8 semanas** | **TaskFlow v1 em produção** |
+
+### Recursos Necessários
+
+| Recurso | Quantidade | Observação |
+|---------|-----------|------------|
+| Desenvolvedores | 1 fullstack (ou 1 FE + 1 BE) | Assistidos por IA (Windsurf/Cursor) |
+| Designer | Parcial (1 semana) | Wireframes + design system, depois dev assume |
+| Infra mensal | ~R$ 100/mês | Vercel (free tier) + Railway ($5) + domínio ($40/ano) |

package/dist/content/skills/specialist-discovery/resources/reference/guide.md

@@ -0,0 +1,48 @@
+# Guia de Referência — Discovery
+
+## Frameworks de Product Discovery
+
+### Jobs to Be Done (JTBD)
+- Formato: "Quando [situação], quero [motivação], para [resultado esperado]"
+- Foco no PORQUÊ, não no O QUÊ
+- Cada persona deve ter pelo menos 1 JTBD principal
+
+### North Star Metric
+- Deve refletir valor entregue ao usuário (não vanity metrics)
+- Exemplos: WAU (SaaS), GMV (marketplace), DAU (social), Revenue/visitor (e-commerce)
+- Evitar: page views, downloads, registros sem ativação
+
+### Priorização MoSCoW
+| Categoria | Significado | Regra |
+|-----------|------------|-------|
+| **Must Have** | Sem isso, MVP não faz sentido | Máximo 3 itens |
+| **Should Have** | Importante, mas MVP sobrevive sem | 2-3 itens |
+| **Could Have** | Agradável ter, baixo esforço | 1-2 itens |
+| **Won't Have** | Explicitamente fora do escopo | Listar para evitar scope creep |
+
+### RICE Scoring
+| Fator | Pergunta | Escala |
+|-------|----------|--------|
+| **Reach** | Quantos usuários impactados? | Número absoluto/trimestre |
+| **Impact** | Quanto impacta cada usuário? | 3=massivo, 2=alto, 1=médio, 0.5=baixo, 0.25=mínimo |
+| **Confidence** | Quão certo estamos? | 100%=alta, 80%=média, 50%=baixa |
+| **Effort** | Pessoa-semanas necessárias? | Número (menor = melhor) |
+| **Score** | (R × I × C) / E | Maior = prioridade |
+
+## Anti-patterns de Discovery
+
+| Anti-pattern | Por que é ruim | Correção |
+|-------------|----------------|----------|
+| "Todos são usuários" | Não direciona decisões de design | Definir 2-3 personas específicas |
+| "O app faz tudo" | MVP vira projeto de 1 ano | Limitar a 3-5 features Must Have |
+| Métricas vagas ("ser popular") | Impossível medir sucesso | North Star com número e prazo |
+| Sem concorrentes listados | Ignora contexto de mercado | Sempre listar 2+ alternativas |
+| Requisitos sem prioridade | Tudo é "urgente" | Forçar MoSCoW ou RICE |
+
+## Dicas para Coleta Conversacional
+
+- **Perguntas abertas** primeiro: "Me conta sobre o problema" (não "o problema é X?")
+- **Follow-up com números**: "Você disse que é lento — quanto tempo leva hoje?"
+- **Desafie abstrações**: "Muitos usuários" → "Quantos exatamente?"
+- **Se o usuário não sabe**: Marque como "A definir" — nunca invente
+- **Limite de features**: Se listar >5, pergunte "Se tivesse que escolher 3?"