@maestro-ai/mcp-server 1.2.0 → 2.1.0

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

@@ -1,237 +0,0 @@
-# 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/dist/content/prompts/observabilidade/estrategia-observabilidade.md

@@ -1,263 +0,0 @@
-# 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/dist/content/prompts/observabilidade/estrategia-observabilidade.txt

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