@maestro-ai/mcp-server 1.2.0 → 2.0.0

package/dist/content/guides/Cat/303/241logo de Stacks para Hospedagem Compartilhada.md"

@@ -1,147 +0,0 @@
-# Catálogo de Stacks para Hospedagem Compartilhada (PHP)
-
-Este catálogo organiza os **planos de entrega** pensando em ambientes como cPanel, Locaweb, Hostgator, Hostinger (shared hosting), onde PHP + MySQL + Apache/Nginx são o padrão e o suporte a Node.js é limitado.
-
-Cada plano pode ser usado em conjunto com o **Playbook de Desenvolvimento com IA** e os especialistas do guia.
-
----
-
-## Plano 1 – Landing Page Essencial
-
-**Tipo de produto:** landing page simples para validação de oferta.  
-**Complexidade:** baixa.
-
-### Stack técnico
-- **Frontend:** HTML5 + CSS3 + JavaScript (Alpine.js opcional para interatividade leve).  
-- **Estilo:** Tailwind CSS (compilado localmente em um único `.css`).  
-- **Backend (formulários):** script PHP simples (`mail.php` com PHPMailer ou similar) para envio de e-mail, sem banco de dados.  
-- **Deploy:** upload via FTP/SFTP ou automação (GitHub Actions → FTP Deploy).
-
-### Notas
-- Substitui funções serverless (Vercel etc.) por **PHP clássico**.  
-- É ideal para aplicar o Playbook em escala reduzida, focando:  
-  - Gestão de Produto (mensagem de valor)  
-  - UX (estrutura da página)  
-  - Desenvolvimento/Vibe Coding (HTML/CSS/JS + script PHP).
-
----
-
-## Plano 2 – Landing Page Pro (Next.js Estático + PHP API)
-
-**Tipo de produto:** landing moderna com interatividade rica, mas servida como site estático.  
-**Complexidade:** média.
-
-### Stack técnico
-- **Frontend:** Next.js 14+ (App Router) configurado com `output: 'export'`.  
-- **Estilo:** Tailwind CSS + shadcn/ui.  
-- **Backend (formulários):** API PHP externa (`api/contact.php`) recebendo POST do formulário React.  
-- **Deploy:** gerar pasta `out` (HTML/CSS/JS estáticos) e subir para `public_html`.
-
-### Notas
-- Do ponto de vista da hospedagem, é **só um site estático + um PHP** para formulário.  
-- IA pode ajudar fortemente em:
-  - UX/copy da landing  
-  - design dos componentes React  
-  - contrato da API (`contact.php`).
-
----
-
-## Plano 3 – Site Institucional (CMS Flat-File ou PHP Leve)
-
-**Tipo de produto:** site institucional com conteúdo gerenciável.  
-**Complexidade:** média.
-
-### Stack técnico
-- **Opção A (flat-file):** Grav CMS ou Kirby CMS (PHP, sem banco de dados).  
-- **Opção B (Laravel-based):** Statamic (modo Solo/Free), usando armazenamento em arquivos.  
-- **Deploy:** upload de arquivos PHP para a hospedagem.
-
-### Notas
-- Cliente ganha **painel administrativo** sem precisar de um MySQL pesado.  
-- Boa combinação com o Playbook nas etapas de:
-  - Modelagem e Arquitetura de Domínio (páginas, posts, coleções)  
-  - Desenvolvimento/Vibe Coding (temas, templates)  
-  - Testes (links, SEO, erros de navegação).
-
----
-
-## Plano 4 – Site Institucional Profissional (Laravel Puro)
-
-**Tipo de produto:** site institucional sob medida, com mais lógica e segurança.  
-**Complexidade:** média/alta.
-
-### Stack técnico
-- **Framework:** Laravel 10/11.  
-- **Frontend:** Blade Templates + Alpine.js + Tailwind CSS.  
-- **Otimização:** cache de resposta (por exemplo, Spatie Response Cache) para aproximar de performance estática.  
-- **Deploy:** deploy Laravel padrão, apontando a pasta `public`.
-
-### Notas
-- Cliente não tem acesso direto à estrutura de templates (Blade); você controla o que é dinâmico.  
-- Excelente para aplicar o Playbook:  
-  - Requisitos (quais seções são gerenciáveis)  
-  - Modelagem (páginas, blocos, SEO, formulários)  
-  - Vibe Coding (controllers, services, policies)  
-  - Testes de feature (Laravel). 
-
----
-
-## Plano 5 – Site Premium (Laravel + Filament CMS)
-
-**Tipo de produto:** site com painel administrativo premium e altamente customizável.  
-**Complexidade:** alta.
-
-### Stack técnico
-- **Core:** Laravel 10/11.  
-- **Painel Administrativo:** FilamentPHP v3.  
-- **Frontend:** Blade com componentes Livewire (parte pública) **ou** frontend separado (ex.: Astro) consumindo APIs Laravel.  
-- **Banco de Dados:** MySQL/MariaDB.
-
-### Notas
-- Ideal para quem quer fugir da "cara de WordPress".  
-- IA pode auxiliar em:
-  - definição de entidades/recursos (Filament Resources)  
-  - geração de formulários, tabelas, filtros  
-  - regras de permissão, roles, policies  
-  - migrações e seeders.
-
----
-
-## Plano 6 – Sistema Personalizado (Laravel Fullstack)
-
-**Tipo de produto:** sistemas sob medida (CRM, ERPs leves, dashboards, etc.).  
-**Complexidade:** alta.
-
-### Stack técnico
-- **Backend:** Laravel 11.  
-- **Frontend:**
-  - Inertia.js (Vue ou React) **ou**  
-  - Livewire 3 (fullstack Laravel).
-- **Infraestrutura:** MySQL; Redis se a hospedagem permitir (senão, drivers baseados em banco/arquivo para cache/filas).  
-- **Real-time:** Laravel Reverb (se houver suporte a WebSockets) ou serviços externos (ex.: Pusher).
-
-### Notas
-- É o melhor candidato para **exemplos completos do Playbook**, pois exige:
-  - requisitos sólidos  
-  - modelagem de domínio rica  
-  - decisões arquiteturais claras  
-  - estratégia de testes mais robusta.
-
----
-
-## Relação com o Playbook de Desenvolvimento com IA
-
-Para qualquer plano:
-
-- Use o **Playbook** para guiar o processo (Visão → Requisitos → Modelagem → Execução → Testes → Evolução).  
-- Use os **Especialistas** conforme o tipo de projeto:
-  - Landing simples: Gestão de Produto, UX, Desenvolvimento/Vibe Coding.  
-  - CMS/Institucional: adicionar Modelagem de Domínio, Arquitetura, Segurança.  
-  - Sistemas personalizados: todos os especialistas, com mais peso em Requisitos, Modelagem, Arquitetura, Testes e Plano de Execução.
-
-Nos próximos passos, você pode adicionar **exemplos práticos** por plano mostrando:
-
-- 1 user story  
-- sequência de prompts  
-- esqueleto de código  
-- esqueleto de testes.

package/dist/content/guides/Checklist Mestre de Entrega.md

@@ -1,68 +0,0 @@
-# Checklist Mestre de Entrega
-
-Definition of Done consolidado de todos os especialistas. Use antes de considerar uma feature "pronta".
-
----
-
-## ✅ Produto
-- [ ] História de usuário clara (Como/Quero/Para)
-- [ ] Critérios de aceitação definidos
-- [ ] Escopo validado com stakeholders
-
-## ✅ Requisitos
-- [ ] Requisitos funcionais documentados
-- [ ] Requisitos não-funcionais definidos
-- [ ] Dúvidas esclarecidas com cliente/PM
-
-## ✅ UX/Design
-- [ ] Fluxos de usuário mapeados (happy path + erros)
-- [ ] Wireframes/protótipos aprovados
-- [ ] Acessibilidade considerada (WCAG AA)
-
-## ✅ Arquitetura
-- [ ] Impacto no modelo de domínio analisado
-- [ ] Decisões arquiteturais documentadas (ADR)
-- [ ] APIs/contratos definidos
-
-## ✅ Código
-- [ ] Código implementado seguindo padrões do projeto
-- [ ] Code review realizado
-- [ ] Sem warnings/erros de linter
-- [ ] Commits atômicos com mensagens claras
-
-## ✅ Testes
-- [ ] Testes unitários implementados
-- [ ] Testes de integração (quando aplicável)
-- [ ] Cobertura mínima atingida (ex: 80%)
-- [ ] Testes passando no CI
-
-## ✅ Segurança
-- [ ] Validação de entrada implementada
-- [ ] Sem secrets hardcoded
-- [ ] Autenticação/autorização verificadas
-- [ ] Vulnerabilidades conhecidas checadas
-
-## ✅ Documentação
-- [ ] README atualizado (se necessário)
-- [ ] Comentários em código complexo
-- [ ] Changelog atualizado
-- [ ] API documentada (OpenAPI/Swagger)
-
-## ✅ Deploy
-- [ ] Pipeline CI/CD verde
-- [ ] Migrations preparadas
-- [ ] Rollback planejado
-- [ ] Métricas/alertas configurados
-
----
-
-## Por Fase do Projeto
-
-### MVP / v1
-Foque em: Produto, Requisitos, Código, Testes básicos
-
-### Produção
-Adicione: Segurança, Deploy, Documentação completa
-
-### Escala
-Adicione: Performance, Observabilidade, Disaster Recovery

package/dist/content/guides/Gates de Qualidade.md

@@ -1,209 +0,0 @@
-# Gates de Qualidade por Fase
-
-> **Propósito**: Validar que cada fase está completa antes de avançar.
-> Use estes checklists como "gates" entre fases.
-
----
-
-## Como Usar
-
-1. Ao finalizar uma fase, revise o gate correspondente
-2. Marque cada item como ✅ ou ❌
-3. **Não avance** se houver itens críticos pendentes
-4. Documente exceções se forçar avanço
-
----
-
-## Gate 1: Produto → Requisitos
-
-**Especialista**: Gestão de Produto  
-**Artefato**: `docs/01-produto/PRD.md`
-
-### Checklist Obrigatório
-- [ ] Problema claramente definido (não genérico)
-- [ ] Pelo menos 2 personas com dores documentadas
-- [ ] MVP definido com must-have vs nice-to-have
-- [ ] Métricas de sucesso (North Star Metric)
-- [ ] Riscos principais identificados
-
-### Critérios de Qualidade
-- [ ] PRD tem menos de 3 páginas
-- [ ] Qualquer pessoa do time entende o problema
-- [ ] Não há TBDs ou "a definir"
-
----
-
-## Gate 2: Requisitos → UX
-
-**Especialista**: Engenharia de Requisitos  
-**Artefato**: `docs/02-requisitos/requisitos.md`
-
-### Checklist Obrigatório
-- [ ] Todos os RFs têm ID único (RF-001, RF-002...)
-- [ ] Todos os RFs são testáveis (têm critério de aceite)
-- [ ] RNFs definidos (performance, segurança, disponibilidade)
-- [ ] Critérios de aceite em Gherkin para features críticas
-- [ ] **Matriz RF × Telas preenchida**
-
-### Critérios de Qualidade
-- [ ] Cada RF mapeia para pelo menos um objetivo do PRD
-- [ ] Não há requisitos duplicados
-- [ ] RNFs são mensuráveis (ex: "99.9% uptime", não "alta disponibilidade")
-
----
-
-## Gate 3: UX → Modelagem
-
-**Especialista**: UX Design  
-**Artefato**: `docs/03-ux/design-doc.md`
-
-### Checklist Obrigatório
-- [ ] Jornadas de usuário mapeadas (happy path)
-- [ ] Wireframes/fluxos dos fluxos principais
-- [ ] Arquitetura de informação definida
-- [ ] Considerações de acessibilidade básicas
-- [ ] **Mapa de navegação em Mermaid**
-
-### Critérios de Qualidade
-- [ ] Fluxos cobrem pelo menos 80% dos RFs
-- [ ] Navegação é clara e consistente
-- [ ] Estados de erro e loading considerados
-
----
-
-## Gate 4: Modelagem → Arquitetura
-
-**Especialista**: Modelagem de Domínio  
-**Artefato**: `docs/04-modelo/modelo-dominio.md`
-
-### Checklist Obrigatório
-- [ ] Entidades principais identificadas
-- [ ] Relacionamentos definidos (1-1, 1-N, N-N)
-- [ ] Atributos com tipos aproximados
-- [ ] Regras de negócio documentadas por entidade
-
-### Critérios de Qualidade
-- [ ] Modelo suporta todos os RFs
-- [ ] Não há entidades "Deus" (com muitos atributos)
-- [ ] Nomenclatura consistente (singular, PascalCase)
-
----
-
-## Gate 5: Arquitetura → Segurança
-
-**Especialista**: Arquitetura de Software  
-**Artefato**: `docs/05-arquitetura/arquitetura.md`
-
-### Checklist Obrigatório
-- [ ] Diagrama C4 (mínimo níveis 1-2)
-- [ ] Stack tecnológica com justificativas
-- [ ] ADRs para decisões críticas (mínimo 2)
-- [ ] Estratégia de autenticação definida
-- [ ] Modelo de dados detalhado
-
-### Critérios de Qualidade
-- [ ] Arquitetura suporta RNFs (escala, performance)
-- [ ] Custos estimados para infra
-- [ ] Pontos de evolução futura identificados
-
----
-
-## Gate 6: Segurança → Testes
-
-**Especialista**: Segurança da Informação  
-**Artefato**: `docs/06-seguranca/checklist.md`
-
-### Checklist Obrigatório
-- [ ] OWASP Top 10 revisado e mitigações definidas
-- [ ] Dados sensíveis identificados e classificados
-- [ ] Estratégia de autenticação/autorização detalhada
-- [ ] Criptografia (em trânsito e em repouso)
-- [ ] Rate limiting e proteção contra abuse
-
-### Critérios de Qualidade
-- [ ] Conformidade com LGPD/GDPR se aplicável
-- [ ] Secrets nunca em código (apenas env vars)
-- [ ] Logs não expõem dados sensíveis
-
----
-
-## Gate 7: Testes → Backlog
-
-**Especialista**: Análise de Testes  
-**Artefato**: `docs/07-testes/plano-testes.md`
-
-### Checklist Obrigatório
-- [ ] Estratégia de testes definida (pirâmide)
-- [ ] Ferramentas escolhidas por tipo de teste
-- [ ] Meta de cobertura definida (ex: >80%)
-- [ ] Casos críticos identificados com prioridade
-
-### Critérios de Qualidade
-- [ ] Todos os RFs têm pelo menos um caso de teste
-- [ ] Casos de borda considerados
-- [ ] Ambiente de testes definido
-
----
-
-## Gate 8: Backlog → Implementação
-
-**Especialista**: Plano de Execução  
-**Artefato**: `docs/08-backlog/backlog.md`
-
-### Checklist Obrigatório
-- [ ] Épicos definidos e priorizados
-- [ ] Histórias escritas (Como X, quero Y, para Z)
-- [ ] Critérios de aceite por história
-- [ ] Definition of Done clara
-- [ ] Estimativas (pelo menos T-shirt sizing)
-- [ ] **Diagrama de dependências visual**
-- [ ] **Telas afetadas mapeadas por feature**
-
-### Critérios de Qualidade
-- [ ] Histórias são pequenas (cabem em 1-2 dias)
-- [ ] Dependências entre histórias mapeadas
-- [ ] MVP priorizável claramente
-
----
-
-## Resumo Visual
-
-```
-┌─────────────┐     ┌─────────────┐     ┌─────────────┐
-│   Produto   │────►│ Requisitos  │────►│     UX      │
-│   (Gate 1)  │     │   (Gate 2)  │     │   (Gate 3)  │
-└─────────────┘     └─────────────┘     └─────────────┘
-                                               │
-       ┌───────────────────────────────────────┘
-       ▼
-┌─────────────┐     ┌─────────────┐     ┌─────────────┐
-│  Modelagem  │────►│ Arquitetura │────►│  Segurança  │
-│   (Gate 4)  │     │   (Gate 5)  │     │   (Gate 6)  │
-└─────────────┘     └─────────────┘     └─────────────┘
-                                               │
-       ┌───────────────────────────────────────┘
-       ▼
-┌─────────────┐     ┌─────────────┐     ┌─────────────┐
-│   Testes    │────►│   Backlog   │────►│ Implementar │
-│   (Gate 7)  │     │   (Gate 8)  │     │             │
-└─────────────┘     └─────────────┘     └─────────────┘
-```
-
----
-
-## Quando Forçar Avanço
-
-Em alguns casos, pode ser necessário avançar mesmo com itens pendentes:
-
-> [!CAUTION]
-> Documente SEMPRE os itens pulados e o motivo.
-
-### Situações Aceitáveis
-- Projeto simples onde item não se aplica
-- Sprint curta com prazo apertado (com débito técnico documentado)
-- Prova de conceito / protótipo
-
-### Não Aceitável Pular
-- Requisitos de segurança críticos
-- Autenticação/autorização
-- Tratamento de dados sensíveis