@maestro-ai/cli 1.0.0

package/content/prompts/observabilidade/chaos-testing.md

@@ -0,0 +1,237 @@
+# Prompt: Chaos Engineering
+
+> **Prioridade**: 🟢 BAIXA  
+> **Aplicável a**: Projetos Nível 3 com alta disponibilidade  
+> **Pré-requisito**: SLOs definidos
+
+---
+
+## Prompt Base: Planejar Experimento
+
+```text
+Atue como engenheiro de confiabilidade (SRE).
+
+Quero realizar experimentos de chaos engineering em:
+- Sistema: [DESCREVA ARQUITETURA]
+- Criticidade: [SLO DE DISPONIBILIDADE]
+- Ambiente alvo: [staging/produção com X% do tráfego]
+
+Objetivos:
+1. Validar resiliência a [TIPO DE FALHA]
+2. Testar [mecanismo: failover, circuit breaker, retry]
+3. Medir tempo de detecção e recuperação
+
+Gere:
+
+1. **Hipótese**
+   - Quando [FALHA], o sistema deve [COMPORTAMENTO]
+   - Impacto esperado nos SLOs: [MÁXIMO ACEITÁVEL]
+
+2. **Plano de Experimento**
+   - Escopo e blast radius
+   - Duração
+   - Métricas a observar
+   - Kill switch
+
+3. **Pré-requisitos**
+   - Observabilidade necessária
+   - Alertas que devem disparar
+   - Time de standby
+
+4. **Execução**
+   - Comandos/ferramenta para injetar falha
+   - Checklist de monitoramento
+   - Critérios para abortar
+
+5. **Pós-experimento**
+   - Template de relatório
+   - Ações de follow-up
+```
+
+---
+
+## Prompt: Experimento de Network Failure
+
+```text
+Preciso testar o comportamento quando há falha de rede entre serviços.
+
+Arquitetura:
+[DESCREVA: ex. Serviço A chama Serviço B via REST]
+
+Cenário:
+- Inserir latência de 5 segundos
+- Depois, simular timeout completo (conexão refused)
+
+Stack: [DESCREVA]
+Ferramenta: [Toxiproxy/tc netem/Chaos Mesh]
+
+Gere:
+1. Hipótese de comportamento esperado
+2. Configuração da ferramenta
+3. O que observar (métricas, logs)
+4. Resultados esperados (circuit breaker, fallback)
+```
+
+---
+
+## Prompt: Experimento de Database Failure
+
+```text
+Preciso testar o comportamento quando o banco de dados falha.
+
+Setup:
+- Banco: [PostgreSQL/MySQL com réplica]
+- ORM: [Prisma/TypeORM/etc]
+- Failover automático: [sim/não]
+
+Cenários a testar:
+1. Primary fica lento (queries demoram 10s)
+2. Primary falha completamente
+3. Réplica fica dessincronizada
+
+Gere experimentos para cada cenário com:
+- Como injetar a falha
+- Comportamento esperado da aplicação
+- Métricas críticas
+- Critérios de sucesso
+```
+
+---
+
+## Prompt: Game Day Planning
+
+```text
+Quero organizar um Game Day (simulação de incidente) para o time.
+
+Contexto:
+- Sistema: [DESCREVA]
+- Participantes: [X pessoas, roles]
+- Duração: [2-4 horas]
+
+O exercício deve:
+1. Simular um incidente realista
+2. Testar detecção e resposta
+3. Validar runbooks
+4. Treinar comunicação
+
+Crie:
+1. Cenário de incidente (o que vai "quebrar")
+2. Timeline de eventos injetados
+3. Pontos de observação para facilitadores
+4. Template de retrospectiva
+5. Métricas de sucesso do Game Day
+```
+
+---
+
+## Exemplo: Plano de Experimento
+
+```yaml
+Experiment:
+  Name: Service Dependency Timeout
+  Date: 2024-01-20
+  Lead: @engineer
+  
+Hypothesis: >
+  Quando o Payment Service não responder por 30 segundos,
+  o Checkout Service deve usar circuit breaker e retornar
+  erro gracioso em < 5 segundos, com fallback para modo offline.
+
+Scope:
+  Environment: production
+  BlastRadius: 5% of traffic (canary deployment)
+  Duration: 10 minutes
+  Services: checkout-service, payment-service
+  
+Steady State:
+  Availability: 99.9%
+  Latency_p99: 500ms
+  Error_Rate: 0.1%
+
+Injection:
+  Tool: Toxiproxy
+  Action: Add 30s latency to payment-service:8080
+  Command: |
+    toxiproxy-cli toxic add -t latency -a latency=30000 payment-service
+    
+Kill_Switch:
+  Auto:
+    - If error_rate > 1% for 2 minutes
+    - If latency_p99 > 5000ms for 1 minute
+  Manual:
+    - toxiproxy-cli toxic remove payment-service
+    - kubectl rollout undo deployment/checkout-canary
+
+Monitoring:
+  Dashboards:
+    - url: https://grafana.internal/d/checkout-slo
+    - url: https://grafana.internal/d/payment-health
+  Alerts_Expected:
+    - payment-service-high-latency
+    - checkout-circuit-breaker-open
+    
+Communication:
+  Before: Anunciar no #engineering 15 min antes
+  During: Atualizações a cada 5 min no #incidents
+  After: Resumo no #engineering
+
+Team:
+  Lead: @maria (executa experimento)
+  Observer: @joao (monitora métricas)
+  Oncall: @pedro (standby para reverter)
+```
+
+---
+
+## Prompt: Analisar Resultados
+
+```text
+Conduzi um experimento de chaos engineering:
+
+Hipótese: [DESCREVA]
+
+Resultados observados:
+- [MÉTRICAS COLETADAS]
+- [LOGS RELEVANTES]
+- [ALERTAS DISPARADOS]
+
+Incidentes durante o experimento:
+- [SE HOUVE]
+
+Analise:
+1. A hipótese foi confirmada ou refutada?
+2. Que fraquezas foram descobertas?
+3. Os mecanismos de resiliência funcionaram?
+4. Que ações de melhoria são recomendadas?
+5. Próximos experimentos sugeridos
+```
+
+---
+
+## Checklist de Experimento
+
+### Antes
+- [ ] Hipótese documentada
+- [ ] Escopo e blast radius definidos
+- [ ] Métricas baseline coletadas
+- [ ] Kill switch configurado e testado
+- [ ] Time informado
+- [ ] Janela de manutenção acordada
+
+### Durante
+- [ ] Dashboards abertos
+- [ ] Alertas monitorados
+- [ ] Comunicação ativa
+- [ ] Pronto para abortar se necessário
+
+### Depois
+- [ ] Relatório escrito
+- [ ] Descobertas compartilhadas
+- [ ] Tickets de melhoria criados
+- [ ] Data do próximo experimento
+
+---
+
+## Referências
+
+Consulte: [Guia de Chaos Engineering](../03-guias/Guia%20de%20Chaos%20Engineering.md)

package/content/prompts/observabilidade/estrategia-observabilidade.md

@@ -0,0 +1,263 @@
+# Prompt: Estratégia de Observabilidade
+
+> **Quando usar**: Fase de arquitetura ou antes de ir para produção
+> **Especialista**: [Observabilidade](../../02-especialistas/Especialista%20em%20Observabilidade.md) ou [DevOps](../../02-especialistas/Especialista%20em%20DevOps%20e%20Infraestrutura.md)
+> **Nível**: Médio a Complexo
+
+---
+
+## Fluxo de Contexto
+
+Antes de usar este prompt, tenha em mãos:
+- `docs/CONTEXTO.md` - Entendimento atual do projeto
+- `docs/05-arquitetura/arquitetura.md` - Arquitetura do sistema
+
+Após gerar, salve o resultado em:
+- `docs/08-observabilidade/estrategia-observabilidade.md`
+
+---
+
+## Prompt Completo
+
+```text
+Atue como SRE sênior especialista em observabilidade.
+
+## Contexto do Projeto
+
+[COLE O CONTEÚDO DE docs/CONTEXTO.md]
+
+## Arquitetura
+
+Componentes: [DESCREVA API, WORKERS, BANCO, CACHE, etc]
+Stack: [TECNOLOGIAS]
+Cloud: [AWS/GCP/Azure/On-premise]
+Criticidade: [ALTA/MÉDIA/BAIXA]
+SLA esperado: [UPTIME % - ex: 99.9%]
+
+---
+
+## Sua Missão
+
+Projete a estratégia de observabilidade baseada nos 3 pilares:
+
+### 1. Logging
+
+#### 1.1 Formato Estruturado
+Defina estrutura JSON padrão:
+- Campos obrigatórios em todo log
+- Campos por tipo de evento (request, error, business)
+- Contexto a incluir (traceId, userId, etc)
+
+#### 1.2 Níveis de Log
+Quando usar cada nível:
+- ERROR: [Quando usar, exemplos]
+- WARN: [Quando usar, exemplos]
+- INFO: [Quando usar, exemplos]
+- DEBUG: [Quando usar, exemplos]
+
+#### 1.3 O que Logar
+- Requests HTTP (entrada e saída)
+- Erros e exceptions (com stack trace)
+- Eventos de negócio importantes
+- Decisões do sistema (cache hit/miss, fallbacks)
+- Auditoria (quem fez o quê)
+
+#### 1.4 O que NÃO Logar
+- PII (dados pessoais) - mascarar
+- Tokens, secrets, passwords
+- Payloads grandes (limitar tamanho)
+- Health checks (ou log em nível menor)
+
+#### 1.5 Onde Enviar
+- Agregador sugerido (CloudWatch, Datadog, ELK, etc)
+- Retenção por ambiente
+- Estratégia de sampling para alto volume
+
+### 2. Métricas
+
+#### 2.1 RED Metrics (para serviços)
+- **Rate**: requests/second
+- **Errors**: error rate %
+- **Duration**: latency percentiles (p50, p95, p99)
+
+#### 2.2 USE Metrics (para recursos)
+- **Utilization**: % de uso (CPU, memory, disk)
+- **Saturation**: queue depth, waiting threads
+- **Errors**: resource errors (OOM, disk full)
+
+#### 2.3 Métricas de Negócio
+[Sugerir 5-10 métricas específicas do domínio]
+- Exemplo: agendamentos_criados_total
+- Exemplo: valor_transacoes_sum
+
+#### 2.4 Instrumentação
+- Como expor métricas (Prometheus, StatsD, etc)
+- Labels/dimensions importantes
+- Naming convention
+
+### 3. Tracing Distribuído
+
+#### 3.1 Setup
+- SDK recomendado (OpenTelemetry)
+- Propagação de contexto entre serviços
+- Instrumentação automática vs manual
+
+#### 3.2 O que Instrumentar
+- HTTP calls (in e out)
+- Database queries (com query sanitizada)
+- Cache operations
+- Message queues (publish e consume)
+- Serviços externos (APIs third-party)
+
+#### 3.3 Sampling Strategy
+- Estratégia recomendada (head-based vs tail-based)
+- Taxa de amostragem por ambiente
+- Always sample em erros
+
+### 4. SLOs e Error Budget
+
+#### 4.1 SLIs (Service Level Indicators)
+| SLI | Fórmula | Medição |
+|-----|---------|---------|
+| Disponibilidade | (requests ok / total) * 100 | Prometheus |
+| Latência | p95 < threshold | Histogram |
+| Throughput | requests/sec | Counter |
+
+#### 4.2 SLOs (Service Level Objectives)
+| SLI | SLO | Janela |
+|-----|-----|--------|
+| Disponibilidade | [X%] | 30 dias |
+| Latência p95 | < [X]ms | - |
+| Error rate | < [X%] | 1 hora |
+
+#### 4.3 Error Budget
+- Cálculo: 100% - SLO = Budget
+- Exemplo: SLO 99.9% = 43.2 min/mês de downtime permitido
+- Ações quando budget está baixo
+
+### 5. Alertas
+
+#### 5.1 Alertas Críticos (P1 - Acordar de madrugada)
+- Sistema fora do ar
+- Error rate > X%
+- Latência > X por Y minutos
+
+#### 5.2 Alertas de Warning (P2 - Horário comercial)
+- Error budget consumindo rápido
+- Recursos próximos do limite
+- Anomalias detectadas
+
+#### 5.3 Multi-Window Burn Rate
+Configuração para evitar false positives:
+- Fast burn: 5% budget em 1h → alerta
+- Slow burn: 10% budget em 6h → alerta
+
+### 6. Dashboards
+
+#### 6.1 Dashboard Principal (Four Golden Signals)
+- Latência (p50, p95, p99)
+- Tráfego (requests/sec)
+- Erros (error rate %)
+- Saturação (CPU, memory, connections)
+
+#### 6.2 Dashboard de Debug
+- Métricas detalhadas por endpoint
+- Database query times
+- Cache hit rates
+- External API latencies
+
+### 7. Runbook Template
+
+Para cada alerta, documentar:
+- O que significa o alerta
+- Impacto para o usuário
+- Passos de diagnóstico
+- Ações de mitigação
+- Escalation path
+```
+
+---
+
+## Exemplo de Uso
+
+```text
+Atue como SRE sênior especialista em observabilidade.
+
+## Contexto do Projeto
+
+Sistema de agendamento para salões de beleza.
+API em produção, precisamos de observabilidade completa.
+
+## Arquitetura
+
+Componentes:
+- API NestJS (2 pods no Kubernetes)
+- PostgreSQL RDS
+- Redis ElastiCache
+- Worker de notificações (1 pod)
+
+Stack: Node.js, TypeScript
+Cloud: AWS
+Criticidade: MÉDIA
+SLA esperado: 99.9%
+```
+
+---
+
+## Resposta Esperada
+
+### Logs - Formato JSON
+
+```json
+{
+  "timestamp": "2024-01-01T10:00:00Z",
+  "level": "info",
+  "message": "Request processed",
+  "service": "api",
+  "traceId": "abc123",
+  "spanId": "def456",
+  "userId": "user-123",
+  "method": "POST",
+  "path": "/api/agendamentos",
+  "statusCode": 201,
+  "durationMs": 45
+}
+```
+
+### Métricas RED
+
+```prometheus
+# Rate
+http_requests_total{service="api", method="POST", path="/api/agendamentos", status="201"}
+
+# Errors
+rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])
+
+# Duration
+histogram_quantile(0.95, http_request_duration_seconds{service="api"})
+```
+
+### SLOs
+
+| SLI | SLO | Error Budget |
+|-----|-----|--------------|
+| Success rate (2xx/3xx) | 99.9% | 43 min/mês |
+| Latency p95 | < 300ms | - |
+| Disponibilidade | 99.9% | 43 min/mês |
+
+---
+
+## Checklist Pós-Geração
+
+- [ ] Formato de log estruturado definido
+- [ ] Níveis de log com exemplos
+- [ ] RED metrics para serviços
+- [ ] USE metrics para recursos
+- [ ] Métricas de negócio específicas do domínio
+- [ ] OpenTelemetry configurado
+- [ ] SLIs e SLOs definidos
+- [ ] Error budget calculado
+- [ ] Alertas P1 e P2 separados
+- [ ] Dashboard principal desenhado
+- [ ] Runbook template criado
+- [ ] Salvar em `docs/08-observabilidade/estrategia-observabilidade.md`

package/content/prompts/observabilidade/estrategia-observabilidade.txt

@@ -0,0 +1,134 @@
+Atue como SRE sênior especialista em observabilidade.
+
+Sistema:
+- Arquitetura: [DESCREVA COMPONENTES]
+- Stack: [TECNOLOGIAS]
+- Criticidade: [ALTA/MÉDIA/BAIXA]
+- SLA esperado: [UPTIME %]
+
+Projete a estratégia de observabilidade:
+
+## 1. Logging
+
+### 1.1 Formato
+- Estrutura JSON recomendada
+- Campos obrigatórios
+- Contexto a incluir
+
+### 1.2 Níveis
+- Quando usar cada nível (error, warn, info, debug)
+- Exemplos
+
+### 1.3 O que logar
+- Requests HTTP
+- Erros e exceptions
+- Eventos de negócio
+- Decisões do sistema
+
+### 1.4 O que NÃO logar
+- PII
+- Tokens/secrets
+- Payloads grandes
+
+## 2. Métricas
+
+### 2.1 RED Metrics (para serviços)
+- Rate: requests/second
+- Errors: error rate
+- Duration: latency percentiles
+
+### 2.2 USE Metrics (para recursos)
+- Utilization: % uso
+- Saturation: queue depth
+- Errors: resource errors
+
+### 2.3 Métricas de Negócio
+- [Métricas específicas do domínio]
+
+### 2.4 Instrumentação
+- Como expor métricas
+- Labels/dimensions
+
+## 3. Tracing Distribuído
+
+### 3.1 Setup
+- SDK recomendado (OpenTelemetry)
+- Propagação de contexto
+
+### 3.2 O que instrumentar
+- HTTP calls
+- Database queries
+- Cache operations
+- Message queues
+
+### 3.3 Sampling
+- Estratégia recomendada
+- Taxa de amostragem
+
+## 4. SLOs e Alertas
+
+### 4.1 SLOs
+| SLI | SLO | Janela |
+|---|---|---|
+| Disponibilidade | X% | 30 dias |
+| Latência p95 | < Xms | - |
+
+### 4.2 Error Budget
+- Cálculo
+- Ações quando baixo
+
+### 4.3 Alertas
+- Alertas críticos (P1)
+- Alertas de warning (P2)
+- Multi-window burn rate
+
+## 5. Dashboards
+
+### 5.1 Dashboard Principal
+- Métricas no painel principal
+- Layout sugerido
+
+### 5.2 Dashboard de Debug
+- Métricas detalhadas
+
+## 6. Runbook Template
+
+Para cada alerta, estrutura do runbook.
+
+---
+
+## Resposta Esperada (Exemplo)
+
+### Logs - Formato JSON
+```json
+{
+  "timestamp": "2024-01-01T10:00:00Z",
+  "level": "info",
+  "message": "Request processed",
+  "traceId": "abc123",
+  "spanId": "def456",
+  "userId": "user-123",
+  "method": "POST",
+  "path": "/api/orders",
+  "statusCode": 201,
+  "durationMs": 45
+}
+```
+
+### Métricas RED
+```
+# Rate
+http_requests_total{method, path, status}
+
+# Errors
+http_requests_total{status=~"5.."}
+
+# Duration
+http_request_duration_seconds{method, path} (histogram)
+```
+
+### SLOs
+| SLI | SLO | Error Budget |
+|---|---|---|
+| Success rate (2xx/3xx) | 99.9% | 43 min/mês |
+| Latency p95 | < 200ms | - |