@maestro-ai/cli 1.0.0

package/README.md

@@ -0,0 +1,59 @@
+# @maestro/cli
+
+CLI para inicializar projetos com Maestro - Desenvolvimento assistido por IA.
+
+## Instalação
+
+```bash
+npx @maestro init
+```
+
+## Comandos
+
+### `init`
+
+Inicializa Maestro no projeto atual:
+
+```bash
+npx @maestro init          # Instalação completa
+npx @maestro init --minimal # Apenas workflows + GEMINI.md
+npx @maestro init --force   # Sobrescreve arquivos existentes
+```
+
+**O que é criado:**
+- `.maestro/config.json` - Configuração do projeto
+- `content/` - Especialistas, templates, guides
+- `.agent/workflows/` - Workflows automatizados
+- `GEMINI.md` - Rules para a IA
+
+### `update`
+
+Atualiza content para a última versão:
+
+```bash
+npx @maestro update
+npx @maestro update --force  # Sobrescreve arquivos modificados
+```
+
+## Após Inicialização
+
+Configure o MCP na sua IDE:
+
+```json
+{
+  "mcpServers": {
+    "maestro": {
+      "serverUrl": "https://maestro.deluna.dev.br/mcp"
+    }
+  }
+}
+```
+
+## Desenvolvimento
+
+```bash
+cd packages/cli
+npm install
+npm run build
+npm run dev -- init  # Testar localmente
+```

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

@@ -0,0 +1,119 @@
+# 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

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

@@ -0,0 +1,147 @@
+# 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/content/guides/Checklist Mestre de Entrega.md

@@ -0,0 +1,68 @@
+# 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/content/guides/Gates de Qualidade.md

@@ -0,0 +1,209 @@
+# 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