@maestro-ai/mcp-server 1.2.0 → 2.1.0

package/dist/content/examples/Exemplo de Fluxo Completo com Laravel e Livewire.md

@@ -1,261 +0,0 @@
-# Exemplo de Fluxo Completo com Laravel e Livewire (Plano 6)
-
-Este exemplo mostra como aplicar o **Playbook de Desenvolvimento com IA**
-para um **Sistema Personalizado** em **Laravel + Livewire**.
-
-Funcionalidade de exemplo: **Gestão de Tarefas (To-Do Kanban simples)**.
-
-Stack alvo (alinhada ao Plano 6):
-- Laravel 11
-- Livewire 3
-- Tailwind CSS
-- MySQL/MariaDB
-- Hospedagem compartilhada.
-
----
-
-## 1. Visão & Problema
-
-### Contexto
-
-Sistema interno simples para um pequeno time organizar tarefas em colunas:
-- A Fazer
-- Em Progresso
-- Concluído
-
-Cada tarefa tem título, descrição, responsável e prazo.
-
-### Prompt sugerido
-
-```text
-Você é um engenheiro de software sênior especialista em Laravel + Livewire.
-
-Contexto:
-- Sistema interno de gestão de tarefas em estilo Kanban simples
-- Colunas: A Fazer, Em Progresso, Concluído
-- Campos da tarefa: título, descrição, responsável, prazo
-
-Me ajude a descrever a visão técnica mínima dessa funcionalidade,
-incluindo:
-- atores
-- fluxos principais
-- riscos ou dúvidas técnicas.
-```
-
----
-
-## 2. Engenharia de Requisitos com IA
-
-### Requisitos funcionais (esperados)
-
-- RF1: Criar tarefa com título, descrição, responsável, prazo, status inicial "A Fazer".
-- RF2: Mover tarefa entre colunas (status).
-- RF3: Editar tarefa.
-- RF4: Listar tarefas por coluna.
-
-### Requisitos não funcionais (exemplos)
-
-- RNF1: Interface responsiva com atualização em tempo real (sem recarregar página).
-- RNF2: Simplicidade de uso para equipe não técnica.
-
-### Prompt sugerido
-
-```text
-A partir da visão abaixo:
-[COLE VISÃO]
-
-Liste requisitos funcionais e não funcionais para o sistema de tarefas,
-com critérios de aceitação em bullets.
-```
-
----
-
-## 3. Modelagem & Arquitetura com IA
-
-### Modelo de domínio esperado
-
-Entidade `Task`:
-- id
-- title
-- description
-- assignee (string ou relação futura com usuário)
-- due_date
-- status (enum: todo, doing, done)
-- created_at, updated_at
-
-### Prompt para modelo de domínio
-
-```text
-Com base nestes requisitos do sistema de tarefas:
-[COLE REQUISITOS]
-
-Proponha o modelo de domínio em Laravel para a entidade Task,
-com campos, tipos e enum de status.
-
-Gere um esboço da migração e do model Task com casts apropriados.
-```
-
-### Prompt para arquitetura (components Livewire)
-
-```text
-Quero implementar a interface em Livewire 3.
-
-Descreva uma arquitetura de componentes Livewire para o Kanban,
-com:
-- um componente principal (ex.: TaskBoard)
-- componentes para cada coluna ou lista de tarefas (opcional)
-- eventos necessários para criar, atualizar e mover tarefas.
-```
-
----
-
-## 4. Planejamento / Backlog com IA
-
-### User story principal
-
-```text
-Como membro da equipe,
-Quero organizar minhas tarefas em colunas,
-Para ter clareza do que fazer e do que já foi concluído.
-```
-
-### Prompt para backlog
-
-```text
-Usando a user story e requisitos abaixo:
-[COLE]
-
-Gere uma lista de tarefas técnicas para implementar essa funcionalidade
-em Laravel + Livewire 3, incluindo:
-- migração e model Task
-- componentes Livewire necessários
-- rotas e views
-- testes básicos (modelo e componentes).
-
-Organize as tarefas em ordem de execução recomendada.
-```
-
----
-
-## 5. Implementação (Vibe Coding Estruturado) com IA
-
-### 5.1. Model e migração
-
-```text
-Vamos implementar a migração e o model Task em Laravel.
-
-Campos:
-- title (string, obrigatório)
-- description (text, opcional)
-- assignee (string, opcional)
-- due_date (date, opcional)
-- status (string ou enum: todo, doing, done; default todo)
-
-Gere o código da migração e do model Task,
-com casts/atributos necessários.
-```
-
-### 5.2. Componente Livewire principal
-
-```text
-Com base no model Task:
-[COLE]
-
-Gere um componente Livewire `TaskBoard` que:
-- carregue tarefas agrupadas por status
-- permita criar nova tarefa (form inline ou modal)
-- permita alterar o status de uma tarefa (ex.: via dropdown ou botões)
-
-Use Tailwind CSS para a estrutura básica do layout (3 colunas).
-```
-
-### 5.3. Interações e UX
-
-```text
-Aqui está o esqueleto do componente TaskBoard:
-[COLE]
-
-Sugira melhorias de UX:
-- feedback visual ao mover tarefas
-- confirmações para exclusão (se houver)
-- tratamento de erros (validação de formulário, falha de salvamento).
-
-Gere o código ajustado considerando essas melhorias.
-```
-
----
-
-## 6. Testes com IA
-
-### Testes de modelo
-
-```text
-Aqui está o model Task:
-[COLE]
-
-Gere testes de modelo em PHPUnit verificando:
-- criação de tarefa válida
-- valor default de status (todo)
-- comportamento de campos opcionais.
-```
-
-### Testes de componente Livewire
-
-```text
-Aqui está o componente TaskBoard:
-[COLE]
-
-Sugira testes de componente Livewire para:
-- exibir tarefas por coluna corretamente
-- criar uma nova tarefa via formulário
-- mover tarefa de uma coluna para outra.
-```
-
----
-
-## 7. Documentação & Revisão com IA
-
-### Documentação funcional
-
-```text
-Com base nos requisitos e no código do sistema de tarefas:
-[COLE]
-
-Gere uma documentação funcional em linguagem de negócio,
-explicando:
-- o que o sistema faz
-- como usar o quadro Kanban
-- principais limitações da primeira versão.
-```
-
-### Revisão técnica
-
-```text
-Atue como revisor de código sênior em Laravel + Livewire.
-
-Aqui estão o model Task e o componente TaskBoard:
-[COLE]
-
-Avalie legibilidade, simplicidade e possíveis problemas de performance/usabilidade.
-Sugira refatorações se necessário.
-```
-
----
-
-## 8. Feedback & Evolução
-
-Depois de em uso, IA pode ajudar a:
-
-- analisar padrões de tarefas (onde ficam presas: todo/doing)
-- sugerir novas colunas ou estados
-- propor filtros (por responsável, prazo, tags).
-
-Prompt exemplo:
-
-```text
-Aqui estão dados exportados do sistema de tarefas (status, datas, responsáveis):
-[COLE]
-
-Identifique padrões (ex.: tarefas que demoram mais em cada status)
- e sugira melhorias de fluxo para o time.
-```

package/dist/content/examples/Exemplo de Fluxo Completo com Node e NestJS.md

@@ -1,258 +0,0 @@
-# Exemplo de Fluxo Completo com Node e NestJS
-
-Este exemplo mostra, de forma resumida, como aplicar o **Playbook de Desenvolvimento com IA**
-para implementar uma funcionalidade simples usando **Node.js + NestJS**.
-
-Funcionalidade de exemplo: **Cadastro de Leads** em uma landing page.
-
----
-
-## 1. Visão & Problema
-
-### Contexto
-
-Uma landing page captura leads (nome, e-mail, origem). Queremos salvar esses dados em um banco
-(PostgreSQL) e ter um endpoint para listar os leads.
-
-### Prompt sugerido
-
-```text
-Você é um engenheiro de software sênior especialista em Node.js e NestJS.
-
-Contexto do produto:
-- Landing page para captura de leads com formulário (nome, email, origem)
-- Backend: API NestJS + PostgreSQL
-
-Me ajude a descrever a visão técnica mínima para essa feature, incluindo:
-- objetivo principal
-- atores
-- principais fluxos (cadastrar lead, listar leads)
-- riscos ou dúvidas técnicas.
-```
-
----
-
-## 2. Engenharia de Requisitos com IA
-
-### Requisitos funcionais (esperados)
-
-- RF1: O sistema deve permitir cadastrar um lead com `nome`, `email`, `origem`.
-- RF2: O sistema deve listar leads cadastrados, com paginação simples.
-
-### Requisitos não funcionais (exemplos)
-
-- RNF1: E-mail deve ser validado.
-- RNF2: API deve responder em < 500ms (p95) em condições normais.
-
-### Prompt sugerido
-
-```text
-A partir da visão abaixo, detalhe os requisitos funcionais e não funcionais
-para a funcionalidade de cadastro de leads.
-
-Visão:
-[COLE A VISÃO GERADA NA ETAPA 1]
-
-Responda com:
-- requisitos funcionais numerados (RF1, RF2...)
-- requisitos não funcionais principais
-- critérios de aceitação para cada requisito.
-```
-
----
-
-## 3. Modelagem & Arquitetura com IA
-
-### Modelo de domínio esperado
-
-Entidade `Lead`:
-- id (UUID)
-- nome (string)
-- email (string)
-- origem (string)
-- criadoEm (datetime)
-
-### Prompt para modelo de domínio
-
-```text
-Com base nestes requisitos:
-[COLE REQUISITOS]
-
-Proponha um modelo de domínio mínimo em NestJS + Prisma com:
-- entidades
-- campos e tipos
-- relacionamentos (se houver)
-
-Explique se há algo ambíguo ou faltando.
-```
-
-### Prompt para arquitetura/API
-
-```text
-Stack:
-- NestJS
-- Prisma
-- PostgreSQL
-
-Quero implementar a API de leads.
-
-Descreva:
-- endpoints necessários (rota, método, payload)
-- formato de resposta
-- status HTTP para casos de sucesso/erro
-- validações obrigatórias.
-```
-
----
-
-## 4. Planejamento / Backlog com IA
-
-### User story
-
-```text
-Como um analista de marketing,
-Quero cadastrar e consultar leads de uma landing page,
-Para que eu possa acompanhar o desempenho das campanhas.
-```
-
-### Prompt para backlog
-
-```text
-Usando a user story e requisitos abaixo:
-[COLE]
-
-Gere uma lista de tarefas técnicas para implementar isso em NestJS + Prisma:
-- modelagem de banco
-- criação de módulo/serviço/controller
-- validações
-- testes unitários e de integração
-
-Organize em uma sequência lógica de implementação.
-```
-
----
-
-## 5. Implementação (Vibe Coding Estruturado) com IA
-
-### Passo 1 – Service de domínio
-
-Prompt sugerido:
-
-```text
-Vamos implementar o serviço de domínio para cadastro e listagem de leads
-em NestJS usando Prisma.
-
-Contexto:
-- entidade Lead: id (UUID), nome, email, origem, criadoEm
-- regras: email obrigatório e válido; nome obrigatório
-
-Gere apenas o código do serviço (LeadService) com métodos:
-- createLead(dto)
-- listLeads(pagination)
-
-Use boas práticas de NestJS e Prisma.
-Não gere controller ainda.
-```
-
-### Passo 2 – Controller/Rotas
-
-```text
-Aqui está o LeadService que acabamos de implementar:
-[COLE CÓDIGO]
-
-Gere o controller NestJS correspondente (LeadController), com rotas:
-- POST /leads
-- GET /leads
-
-Inclua:
-- DTOs de entrada/saída com class-validator
-- tratamento básico de erros (ex.: BadRequestException).
-```
-
----
-
-## 6. Testes com IA
-
-### Testes unitários (service)
-
-```text
-Aqui está a implementação do LeadService em NestJS:
-[COLE]
-
-Gere testes unitários em Jest cobrindo:
-- criação de lead válido
-- erro quando email é inválido
-- listagem de leads com paginação.
-
-Explique em 1 linha o objetivo de cada teste.
-```
-
-### Testes de integração (API)
-
-```text
-Com base no controller de leads e requisitos da API:
-[COLE]
-
-Sugira testes de integração usando o testing module do NestJS,
-validando pelo menos:
-- POST /leads com payload válido (201)
-- POST /leads com payload inválido (400)
-- GET /leads retornando lista paginada.
-```
-
----
-
-## 7. Documentação & Revisão com IA
-
-### Prompt para revisão de código
-
-```text
-Atue como revisor de código sênior em NestJS.
-
-Aqui estão os arquivos do módulo de leads (service + controller + DTOs):
-[COLE]
-
-Avalie:
-- legibilidade
-- possíveis bugs
-- aderência às boas práticas de NestJS
-
-Sugira melhorias e, se necessário, proponha refatorações.
-```
-
-### Prompt para documentação técnica
-
-```text
-Com base no módulo de leads implementado:
-[COLE]
-
-Gere uma documentação técnica resumida com:
-- o que o módulo faz
-- endpoints expostos
-- principais validações
-- dependências externas.
-```
-
----
-
-## 8. Feedback & Evolução
-
-Depois de em produção, IA pode ajudar a:
-
-- Analisar logs/erros de requisições para `POST /leads`.
-- Sugerir melhorias de UX no formulário (com apoio do Especialista em UX).
-- Encontrar oportunidades de segmentação de leads.
-
-Prompt exemplo:
-
-```text
-Aqui estão logs de erros da API de leads e alguns feedbacks de usuários:
-[COLE]
-
-Agrupe em:
-- problemas de validação
-- problemas de usabilidade
-- bugs reais
-
-Sugira melhorias de curto prazo e possíveis ajustes na arquitetura.
-```

package/dist/content/guides/Cat/303/241logo de Stacks para Cloud Moderna.md"

@@ -1,119 +0,0 @@
-# Catálogo de Stacks para Cloud Moderna
-
-Complemento ao catálogo de hospedagem compartilhada, focado em infraestrutura cloud.
-
----
-
-## Plano 1 – Serverless Simples
-
-**Tipo:** APIs leves, funções acionadas por eventos  
-**Complexidade:** Baixa
-
-### Stack
-- **Runtime:** Vercel Functions, Netlify Functions, AWS Lambda
-- **Banco:** PlanetScale, Supabase, Neon (PostgreSQL serverless)
-- **Auth:** Clerk, Auth0, Supabase Auth
-
-### Casos de Uso
-- APIs para landing pages
-- Webhooks e integrações
-- Backend-for-frontend (BFF)
-
----
-
-## Plano 2 – Aplicação Containerizada (PaaS)
-
-**Tipo:** Apps web completas, APIs com estado  
-**Complexidade:** Média
-
-### Stack
-- **Deploy:** Railway, Render, Fly.io
-- **Containers:** Docker
-- **Banco:** PostgreSQL gerenciado (Railway, Render, Supabase)
-- **Cache:** Redis (Upstash, Railway)
-
-### Casos de Uso
-- MVPs e apps early-stage
-- Projetos com orçamento limitado
-- Deploy rápido sem gerenciar infra
-
----
-
-## Plano 3 – AWS Estruturado
-
-**Tipo:** Sistemas de médio/grande porte  
-**Complexidade:** Alta
-
-### Stack
-- **Compute:** ECS Fargate, EC2, Lambda
-- **Banco:** RDS (PostgreSQL/MySQL), DynamoDB
-- **Storage:** S3
-- **CDN:** CloudFront
-- **Auth:** Cognito
-- **IaC:** Terraform, CDK
-
-### Casos de Uso
-- Sistemas enterprise
-- Alta disponibilidade necessária
-- Compliance (SOC2, HIPAA)
-
----
-
-## Plano 4 – GCP Moderno
-
-**Tipo:** Apps data-intensive, ML  
-**Complexidade:** Alta
-
-### Stack
-- **Compute:** Cloud Run, GKE
-- **Banco:** Cloud SQL, Firestore
-- **Data:** BigQuery, Dataflow
-- **ML:** Vertex AI
-- **IaC:** Terraform
-
-### Casos de Uso
-- Analytics e BI
-- Pipelines de ML
-- Integração com Google Workspace
-
----
-
-## Plano 5 – Kubernetes Full
-
-**Tipo:** Microserviços, multi-tenant  
-**Complexidade:** Muito Alta
-
-### Stack
-- **Orquestração:** EKS, GKE, AKS, ou self-hosted
-- **Ingress:** NGINX, Traefik
-- **Service Mesh:** Istio, Linkerd
-- **GitOps:** ArgoCD, Flux
-- **Observability:** Prometheus, Grafana, Loki
-
-### Casos de Uso
-- Microserviços em escala
-- Multi-tenant SaaS
-- Equipes grandes com autonomia
-
----
-
-## Comparativo
-
-| Critério | Serverless | PaaS | AWS/GCP | K8s Full |
-|---|---|---|---|---|
-| **Custo inicial** | Baixo | Baixo | Médio | Alto |
-| **Escala** | Auto | Auto | Configurável | Configurável |
-| **Complexidade** | Baixa | Baixa | Alta | Muito Alta |
-| **Vendor lock-in** | Alto | Médio | Médio | Baixo |
-| **Time to deploy** | Minutos | Minutos | Horas | Dias |
-
----
-
-## Relação com o Playbook
-
-Para qualquer plano cloud:
-
-1. Use o **Especialista em DevOps** para definir pipelines
-2. Use o **Especialista em Arquitetura** para decisões de design
-3. Use o **Especialista em Segurança** para IAM, secrets e compliance
-4. Documente decisões em ADRs