@maestro-ai/cli 1.0.0

package/content/guides/Guia de Otimiza/303/247/303/243o de Custos Cloud.md"

@@ -0,0 +1,195 @@
+# Guia de Otimização de Custos Cloud
+
+> **Prioridade**: 🟢 BAIXA  
+> **Aplicável a**: Projetos em produção com custos significativos de cloud
+
+---
+
+## Por que Otimizar?
+
+Cloud custa caro se não for gerenciada. Otimização pode reduzir 20-50% dos custos sem impacto em performance.
+
+---
+
+## Pilares de Otimização
+
+### 1. Right-Sizing
+
+Usar instâncias do tamanho certo para a carga.
+
+| Sinal | Problema | Ação |
+|-------|----------|------|
+| CPU < 20% constante | Superdimensionado | Diminuir tier |
+| CPU > 80% frequente | Subdimensionado | Aumentar ou escalar |
+| Memória < 30% usada | Superdimensionado | Diminuir tier |
+| Picos curtos, idle longo | Má distribuição | Considerar serverless |
+
+### 2. Reserved Instances / Savings Plans
+
+| Tipo | Desconto | Trade-off |
+|------|----------|-----------|
+| On-Demand | 0% | Flexibilidade total |
+| Reserved 1 ano | 30-40% | Compromisso |
+| Reserved 3 anos | 50-60% | Compromisso maior |
+| Spot/Preemptible | 60-90% | Pode ser terminado |
+
+**Regra**: Reserve workloads estáveis, on-demand para variáveis.
+
+### 3. Auto-Scaling
+
+```yaml
+# Exemplo AWS Auto Scaling
+ScalingPolicy:
+  - Name: scale-on-cpu
+    MetricType: CPUUtilization
+    TargetValue: 70
+    ScaleInCooldown: 300
+    ScaleOutCooldown: 60
+```
+
+### 4. Storage Optimization
+
+| Classe | Custo | Uso |
+|--------|-------|-----|
+| Standard | $$$ | Acesso frequente |
+| Infrequent Access | $$ | Acesso mensal |
+| Glacier/Archive | $ | Backups, compliance |
+
+**Política de Lifecycle**:
+```json
+{
+  "Rules": [{
+    "ID": "ArchiveOldData",
+    "Filter": { "Prefix": "logs/" },
+    "Transitions": [
+      { "Days": 30, "StorageClass": "STANDARD_IA" },
+      { "Days": 90, "StorageClass": "GLACIER" }
+    ],
+    "Expiration": { "Days": 365 }
+  }]
+}
+```
+
+### 5. Database Optimization
+
+| Estratégia | Economia |
+|------------|----------|
+| Read replicas para leitura | Menos carga no primário |
+| Serverless DB (Aurora, PlanetScale) | Paga por uso |
+| Indices eficientes | Menos CPU |
+| Query optimization | Menos tempo de CPU |
+| Connection pooling | Menos instâncias |
+
+### 6. Containerização e Serverless
+
+| Workload | Melhor Opção |
+|----------|--------------|
+| Carga constante 24/7 | Containers (ECS, GKE) |
+| Picos esporádicos | Serverless (Lambda, Cloud Run) |
+| Batch jobs | Spot instances + containers |
+| APIs leves | Serverless |
+
+---
+
+## Checklist de Auditoria de Custos
+
+### Compute
+- [ ] Instâncias idle identificadas e terminadas
+- [ ] Right-sizing aplicado baseado em métricas
+- [ ] Reserved instances para workloads estáveis
+- [ ] Spot instances para workloads tolerantes
+- [ ] Auto-scaling configurado corretamente
+
+### Storage
+- [ ] Buckets/volumes não utilizados deletados
+- [ ] Lifecycle policies configuradas
+- [ ] Snapshots antigos removidos
+- [ ] EBS volumes orfãos identificados
+- [ ] Classe de storage correta por tipo de dado
+
+### Network
+- [ ] Data transfer entre regiões minimizado
+- [ ] NAT Gateway otimizado (VPC endpoints)
+- [ ] CDN para conteúdo estático
+- [ ] Endpoints privados quando possível
+
+### Database
+- [ ] Instâncias provisionadas corretamente
+- [ ] Read replicas só onde necessário
+- [ ] Backups retidos pelo tempo correto
+- [ ] Queries otimizadas (índices)
+
+---
+
+## Ferramentas de Análise
+
+| Provedor | Ferramenta |
+|----------|-----------|
+| **AWS** | Cost Explorer, Trusted Advisor, Compute Optimizer |
+| **GCP** | Cost Management, Recommender |
+| **Azure** | Cost Management, Advisor |
+| **Multi-cloud** | Kubecost, CloudHealth, Infracost |
+
+---
+
+## Budget e Alertas
+
+```yaml
+# AWS Budget example
+Budget:
+  Name: MonthlyBudget
+  Amount: 5000
+  TimeUnit: MONTHLY
+  Notifications:
+    - ThresholdPercentage: 50
+      NotificationType: ACTUAL
+      Recipients: [team@company.com]
+    - ThresholdPercentage: 80
+      NotificationType: ACTUAL
+      Recipients: [finance@company.com, team@company.com]
+    - ThresholdPercentage: 100
+      NotificationType: FORECASTED
+      Recipients: [all-hands@company.com]
+```
+
+---
+
+## Métricas para Monitorar
+
+| Métrica | Meta |
+|---------|------|
+| Custo por request | Tendência de queda |
+| Custo por usuário | Estável ou queda |
+| % de Reserved usage | > 80% |
+| Recursos idle | 0 |
+| Custo vs Budget | < 100% |
+
+---
+
+## Quick Wins
+
+1. **Desligar ambientes dev/staging fora do horário**
+   ```bash
+   # Lambda para desligar EC2 à noite
+   aws ec2 stop-instances --instance-ids $(filter-dev-instances)
+   ```
+
+2. **Tagging para identificar ownership**
+   ```yaml
+   Tags:
+     Environment: production
+     Team: backend
+     CostCenter: engineering
+   ```
+
+3. **Alertas de custo diário**
+
+4. **Revisão mensal de custos** (cerimônia do time)
+
+---
+
+## Referências
+
+- [AWS Well-Architected - Cost Optimization](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/)
+- [GCP Cost Optimization](https://cloud.google.com/architecture/framework/cost-optimization)
+- [FinOps Foundation](https://www.finops.org/)

package/content/guides/Guia de Refatora/303/247/303/243o de C/303/263digo Legado com IA.md"

@@ -0,0 +1,162 @@
+# Guia de Refatoração de Código Legado com IA
+
+Fluxo estruturado para modernizar código existente com apoio de IA.
+
+---
+
+## Quando Refatorar
+
+- Código difícil de entender ou modificar
+- Testes inexistentes ou frágeis
+- Padrões desatualizados
+- Performance inadequada
+- Dívida técnica acumulada
+
+---
+
+## Fluxo de Refatoração
+
+```
+1. Análise → 2. Testes → 3. Refatoração → 4. Validação → 5. Documentação
+```
+
+---
+
+## 1. Análise do Código
+
+### Identificar code smells
+
+```text
+Atue como revisor de código sênior.
+
+Aqui está um módulo/classe legado:
+[COLE CÓDIGO]
+
+Identifique:
+- Code smells presentes (God Class, Long Method, etc.)
+- Violações de SOLID
+- Oportunidades de simplificação
+- Dependências problemáticas
+
+Priorize por impacto e facilidade de correção.
+```
+
+### Entender lógica existente
+
+```text
+Este código foi escrito há anos e preciso entendê-lo:
+[COLE CÓDIGO]
+
+Explique:
+- O que este código faz
+- Fluxo principal de execução
+- Dependências externas
+- Casos de borda tratados
+```
+
+---
+
+## 2. Adicionar Testes (antes de refatorar)
+
+```text
+Aqui está uma função/classe que vou refatorar:
+[COLE CÓDIGO]
+
+Gere testes de caracterização que capturem o comportamento atual:
+- Casos de uso principais
+- Casos de borda
+- Comportamento com inputs inválidos
+
+Use [FRAMEWORK DE TESTES].
+```
+
+---
+
+## 3. Refatoração Incremental
+
+### Extrair método
+
+```text
+Este método está muito longo:
+[COLE CÓDIGO]
+
+Sugira extrações de métodos que:
+- Melhorem legibilidade
+- Sigam SRP (Single Responsibility)
+- Mantenham comportamento idêntico
+```
+
+### Simplificar condicionais
+
+```text
+Estas condicionais estão complexas:
+[COLE CÓDIGO]
+
+Refatore usando:
+- Early returns
+- Guard clauses
+- Polimorfismo (se apropriado)
+```
+
+### Modernizar sintaxe
+
+```text
+Este código usa padrões antigos de [LINGUAGEM]:
+[COLE CÓDIGO]
+
+Modernize para usar:
+- Sintaxe atual da linguagem
+- Padrões idiomáticos
+- Recursos modernos (async/await, destructuring, etc.)
+```
+
+---
+
+## 4. Validação
+
+- [ ] Todos os testes passando
+- [ ] Cobertura mantida ou melhorada
+- [ ] Performance não degradou
+- [ ] Comportamento idêntico ao original
+
+---
+
+## 5. Documentação
+
+```text
+Acabei de refatorar o seguinte código:
+
+Antes:
+[COLE CÓDIGO ANTIGO]
+
+Depois:
+[COLE CÓDIGO NOVO]
+
+Gere um resumo das mudanças para o PR, explicando:
+- Por que a refatoração foi feita
+- Principais alterações
+- Impacto no comportamento (nenhum, se correto)
+```
+
+---
+
+## Estratégias de Refatoração
+
+| Técnica | Quando Usar | Risco |
+|---|---|---|
+| **Renomear** | Nomes confusos | Baixo |
+| **Extrair método** | Métodos longos | Baixo |
+| **Extrair classe** | Classe com muitas responsabilidades | Médio |
+| **Mover método** | Método na classe errada | Médio |
+| **Substituir condicional por polimorfismo** | Switch/if complexos | Alto |
+| **Introduzir padrão de design** | Código duplicado, acoplamento | Alto |
+
+---
+
+## Boas Práticas
+
+1. **Sempre tenha testes antes de refatorar**
+2. **Mudanças pequenas e frequentes** - commits atômicos
+3. **Uma refatoração por vez** - não misture com features
+4. **Valide após cada passo** - rode testes frequentemente
+5. **Use IA como assistente** - revise sempre as sugestões

package/content/guides/Guia de SLOs e Error Budgets.md

@@ -0,0 +1,315 @@
+# Guia de SLOs e Error Budgets
+
+> **Aplicável a**: Projetos Nível 2 (Médio) e Nível 3 (Complexo)  
+> **Pré-requisitos**: Observabilidade básica configurada (logs, métricas)
+
+---
+
+## O que são SLOs?
+
+**SLO (Service Level Objective)** é uma meta interna de confiabilidade que define "bom o suficiente" para seu serviço.
+
+```
+SLI → SLO → SLA → Error Budget
+
+SLI: A métrica que você mede
+SLO: A meta que você quer atingir
+SLA: O contrato com seu cliente
+Error Budget: Quanto você pode errar sem violar o SLO
+```
+
+---
+
+## Por que SLOs são Importantes?
+
+### Sem SLOs
+- ❌ "O sistema está lento?" - "Depende..."
+- ❌ "Podemos fazer deploy?" - "Acho que sim..."
+- ❌ "Devemos priorizar feature ou bug?" - "Não sei..."
+
+### Com SLOs
+- ✅ "Latência p95 está em 180ms, dentro do SLO de 200ms"
+- ✅ "Error budget em 60%, deploys liberados"
+- ✅ "Error budget em 85%, priorizar estabilidade"
+
+---
+
+## Como Definir SLOs
+
+### Passo 1: Identificar Jornadas Críticas
+
+Liste as ações mais importantes do usuário:
+
+| Jornada | Criticidade | Frequência |
+|---------|-------------|------------|
+| Login | Alta | 1000x/dia |
+| Checkout | Crítica | 500x/dia |
+| Busca de produtos | Média | 5000x/dia |
+
+### Passo 2: Escolher SLIs
+
+Para cada jornada, defina indicadores mensuráveis:
+
+| Jornada | SLI de Disponibilidade | SLI de Latência |
+|---------|------------------------|-----------------|
+| Login | Logins bem-sucedidos / tentativas | Tempo até token retornado |
+| Checkout | Pedidos confirmados / tentativas | Tempo até confirmação |
+
+### Passo 3: Definir Targets
+
+Baseie-se em:
+- **Dados históricos**: O que você está entregando hoje?
+- **Expectativas do usuário**: O que é aceitável?
+- **Custo de melhoria**: Vale o investimento para ir de 99.9% para 99.99%?
+
+| SLO | Custo Aproximado | Justifica para... |
+|-----|------------------|-------------------|
+| 99% | Baixo | MVPs, ferramentas internas |
+| 99.9% | Médio | SaaS, apps consumer |
+| 99.99% | Alto | Fintech, healthcare |
+| 99.999% | Muito Alto | Infraestrutura crítica |
+
+### Passo 4: Calcular Error Budget
+
+```
+Error Budget = 100% - SLO Target
+
+SLO 99.9% → Error Budget = 0.1%
+- Por mês (30 dias): 43.2 minutos de downtime permitido
+- Por semana: ~10 minutos
+```
+
+**Tabela de Referência:**
+
+| SLO | Downtime/mês | Downtime/ano |
+|-----|--------------|--------------|
+| 99% | 7.2 horas | 3.65 dias |
+| 99.5% | 3.6 horas | 1.83 dias |
+| 99.9% | 43.2 min | 8.76 horas |
+| 99.95% | 21.6 min | 4.38 horas |
+| 99.99% | 4.32 min | 52.6 min |
+
+---
+
+## Error Budget Policy
+
+### Níveis de Consumo
+
+```mermaid
+graph LR
+    A[0-50%] -->|Normal| B[Deploys OK]
+    B --> C[50-75%]
+    C -->|Atenção| D[Revisar deploys]
+    D --> E[75-90%]
+    E -->|Alerta| F[Freeze parcial]
+    F --> G[90-100%]
+    G -->|Crítico| H[Freeze total]
+    H --> I[>100%]
+    I -->|Violação| J[Post-mortem]
+```
+
+### Template de Policy
+
+```markdown
+## Error Budget Policy - [SISTEMA]
+
+### 0-50% Consumido (🟢 Normal)
+- Deploys normais
+- Features priorizadas
+- Experimentos permitidos
+
+### 50-75% Consumido (🟡 Atenção)
+- Deploys com revisão extra
+- Priorizar bugs críticos
+- Reduzir experimentos arriscados
+
+### 75-90% Consumido (🟠 Alerta)
+- Apenas bug fixes e melhorias de confiabilidade
+- Cancelar deploys não-críticos
+- Investigar causa do consumo
+
+### 90-100% Consumido (🔴 Crítico)
+- Freeze total de features
+- Todas as mãos em estabilidade
+- Escalar para liderança
+
+### >100% Violação (⚫ Emergência)
+- Post-mortem obrigatório em 48h
+- Plano de ação documentado
+- Revisão de SLOs se necessário
+```
+
+---
+
+## Implementação Prática
+
+### Ferramentas de Observabilidade
+
+| Ferramenta | SLI/SLO Features |
+|------------|------------------|
+| **Prometheus + Grafana** | Recording rules para SLIs, alertas, dashboards |
+| **Datadog** | SLO tracking nativo, error budget dashboards |
+| **New Relic** | SLI wizard, burn rate alerts |
+| **Google Cloud SLO** | Nativo para GCP, integrado com alertas |
+
+### Exemplo: Prometheus Recording Rules
+
+```yaml
+# prometheus-rules.yaml
+groups:
+  - name: slo_slis
+    rules:
+      # SLI: Disponibilidade
+      - record: sli:availability:ratio
+        expr: |
+          sum(rate(http_requests_total{status!~"5.."}[5m]))
+          /
+          sum(rate(http_requests_total[5m]))
+
+      # SLI: Latência p99
+      - record: sli:latency:p99
+        expr: |
+          histogram_quantile(0.99,
+            sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
+          )
+
+      # Error Budget Restante
+      - record: slo:error_budget:remaining
+        expr: |
+          1 - (
+            (1 - sli:availability:ratio) 
+            / 
+            (1 - 0.999)  # SLO target 99.9%
+          )
+```
+
+### Exemplo: Alertas de Burn Rate
+
+```yaml
+# Alerta quando error budget está sendo consumido rapidamente
+groups:
+  - name: slo_alerts
+    rules:
+      - alert: HighErrorBudgetBurn
+        expr: |
+          (
+            1 - sli:availability:ratio
+          ) > 14.4 * (1 - 0.999)
+        for: 1h
+        labels:
+          severity: critical
+        annotations:
+          summary: "Error budget sendo consumido 14x mais rápido que o normal"
+          
+      - alert: ErrorBudgetLow
+        expr: slo:error_budget:remaining < 0.25
+        for: 5m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Menos de 25% do error budget restante"
+```
+
+---
+
+## Dashboard Essencial
+
+### Elementos Obrigatórios
+
+1. **Gauge de Error Budget**
+   - Cor por nível (verde/amarelo/vermelho)
+   - Tendência (subindo/descendo)
+
+2. **SLIs em Tempo Real**
+   - Disponibilidade atual
+   - Latência p95/p99
+   - Taxa de erros
+
+3. **Histórico de 30 dias**
+   - Linha do SLO target
+   - Área de SLI real
+   - Marcadores de incidentes
+
+4. **Projeção**
+   - Se mantiver a taxa atual, violaremos em X dias?
+
+---
+
+## Post-Mortem de Violação
+
+### Template
+
+```markdown
+# Post-Mortem: Violação de SLO [DATA]
+
+## Resumo
+- **SLO Violado**: Disponibilidade < 99.9%
+- **Duração**: 2h 15min
+- **Error Budget Consumido**: 150% do mensal
+
+## Linha do Tempo
+- 14:00 - Primeiro alerta
+- 14:15 - Time acionado
+- 14:30 - Causa identificada
+- 15:45 - Mitigação aplicada
+- 16:15 - Sistema estável
+
+## Causa Raiz
+[Descrição técnica]
+
+## Impacto
+- Usuários afetados: 5000
+- Transações perdidas: 120
+
+## Ações Corretivas
+1. [Ação imediata - responsável - prazo]
+2. [Ação preventiva - responsável - prazo]
+
+## Lições Aprendidas
+- O que funcionou bem
+- O que pode melhorar
+```
+
+---
+
+## Checklist de Adoção
+
+### Semana 1
+- [ ] Identificar 3-5 jornadas críticas
+- [ ] Definir SLIs mensuráveis
+- [ ] Configurar coleta de métricas
+
+### Semana 2
+- [ ] Analisar dados históricos
+- [ ] Definir SLO targets iniciais
+- [ ] Calcular error budgets
+
+### Semana 3
+- [ ] Criar dashboard de SLOs
+- [ ] Configurar alertas
+- [ ] Documentar Error Budget Policy
+
+### Semana 4
+- [ ] Treinar time
+- [ ] Primeiro ciclo de review
+- [ ] Ajustar targets se necessário
+
+---
+
+## Armadilhas Comuns
+
+| Armadilha | Solução |
+|-----------|---------|
+| SLOs muito ambiciosos | Comece com targets conservadores |
+| SLIs difíceis de medir | Simplifique, use métricas disponíveis |
+| Ignorar error budget | Automatize alertas e policies |
+| Nunca revisar SLOs | Agende revisão trimestral |
+| SLOs por componente | Foque em jornadas do usuário |
+
+---
+
+## Referências
+
+- [Google SRE Book - SLOs](https://sre.google/sre-book/service-level-objectives/)
+- [Implementing SLOs (Google SRE Workbook)](https://sre.google/workbook/implementing-slos/)
+- [The Art of SLOs (Coursera)](https://www.coursera.org/learn/site-reliability-engineering-slos)