@maestro-ai/mcp-server 1.2.0 → 2.1.0

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

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

package/dist/content/guides/M/303/251tricas de Efici/303/252ncia do Desenvolvimento com IA.md"

@@ -1,93 +0,0 @@
-# Métricas de Eficiência do Desenvolvimento com IA
-
-Como medir o impacto do uso de IA no seu fluxo de desenvolvimento.
-
----
-
-## Por que Medir?
-
-- Justificar investimento em ferramentas de IA
-- Identificar onde IA agrega mais valor
-- Otimizar prompts e workflows
-- Treinar equipe em melhores práticas
-
----
-
-## Métricas Principais
-
-### 1. Tempo Economizado
-
-| Atividade | Sem IA | Com IA | Economia |
-|---|---|---|---|
-| Escrever testes | X min | Y min | Z% |
-| Documentar código | X min | Y min | Z% |
-| Debug de erro | X min | Y min | Z% |
-| Boilerplate/scaffolding | X min | Y min | Z% |
-
-**Como medir:** Time tracking em tarefas similares com/sem IA
-
-### 2. Taxa de Aceitação de Código
-
-```
-Taxa = (Código aceito da IA) / (Total gerado pela IA) × 100
-```
-
-- **> 80%**: IA bem calibrada, prompts eficientes
-- **50-80%**: Revisar qualidade dos prompts
-- **< 50%**: Repensar uso ou treinar equipe
-
-### 3. Qualidade do Código Gerado
-
-- **Bugs encontrados** em código gerado por IA vs. escrito manualmente
-- **Cobertura de testes** de código gerado
-- **Complexidade ciclomática** do código gerado
-
-### 4. Velocidade de Entrega
-
-- **Lead time** de features (início → produção)
-- **Cycle time** de tarefas individuais
-- **Throughput** (features entregues por sprint)
-
----
-
-## Template de Acompanhamento
-
-```markdown
-## Sprint X - Métricas de IA
-
-### Resumo
-- Tarefas com apoio de IA: X/Y
-- Tempo total economizado: ~X horas
-- Taxa de aceitação média: X%
-
-### Por Atividade
-| Atividade | Usos | Taxa Aceitação | Tempo Economizado |
-|---|---|---|---|
-| Geração de testes | X | X% | X min |
-| Debugging | X | X% | X min |
-| Documentação | X | X% | X min |
-
-### Observações
-- O que funcionou bem:
-- O que pode melhorar:
-- Prompts a documentar:
-```
-
----
-
-## Ferramentas de Medição
-
-- **Time tracking:** Toggl, Clockify, Harvest
-- **Métricas de código:** SonarQube, Code Climate
-- **Métricas de entrega:** Jira, Linear, GitHub Projects
-- **Logs de uso:** Salvar prompts úteis e resultados
-
----
-
-## Boas Práticas
-
-1. **Meça por um período** antes de tirar conclusões (mínimo 2-4 sprints)
-2. **Compare tarefas similares** para evitar viés
-3. **Inclua tempo de revisão** na conta - código gerado precisa ser revisado
-4. **Documente prompts eficientes** para reuso da equipe
-5. **Itere** - ajuste prompts baseado em métricas

package/dist/content/guides/Rules base.md

@@ -1,90 +0,0 @@
-# Regras do Cursor (Template Padrão Universal)
-
-Arquivo `.cursor-rules` para configuração do ambiente de desenvolvimento
-quando estiver usando um assistente de código/IA como "engenheiro sênior virtual".
-
-## 🎯 Persona
-Engenheiro de Software Sênior/Tech Lead focado em código production-ready:
-limpo, escalável, seguro e testado.
-
-### Comportamento Esperado
-- Pragmático, com foco em soluções robustas.
-- Antecipa edge cases.
-- Comunicação clara e direta.
-
----
-
-## 💻 Stack Técnica
-
-Este template é **agnóstico de stack**, mas traz exemplos para
-um cenário comum de front-end Web com TypeScript/React.
-
-- **Linguagens/Frameworks**: definidos no Tech Spec do projeto.
-- **Frontend (exemplo)**: React/Next.js com TypeScript.
-- **Backend (exemplo)**: Node/Nest, Java/Spring, .NET, ou outro definido no projeto.
-- **Banco/ORM (exemplo)**: PostgreSQL, Prisma/TypeORM/JPA, etc.
-- **Estilo/UI**: Design System definido (ex.: Tailwind, shadcn/ui, Material UI etc.).
-
-> Adapte estes exemplos para a stack concreta do projeto antes de iniciar.
-
----
-
-## ✍️ Diretrizes de Código
-
-1. **Clean Code**: legibilidade, SRP, manutenibilidade.
-2. **SOLID**: aplicar onde fizer sentido (sem over-engineering).
-3. **Separação de Responsabilidades** (para Web, como exemplo):
-   - Componentes: UI pura (sem lógica complexa de negócio).
-   - Hooks/Serviços: lógica de estado e de aplicação.
-4. **Padrões gerais**:
-   - Prefira `async/await` a `.then()`
-   - Evite `any` em TypeScript; use tipagem explícita.
-   - Nomenclatura consistente:
-     - Componentes React: `MeuComponente.tsx` (PascalCase)
-     - Hooks: `useMeuHook.ts` (camelCase)
-     - Demais arquivos: `meu-arquivo.ts` (kebab-case) ou convenção local do projeto.
-
----
-
-## 🧪 Estratégia de Testes
-
-Os nomes abaixo são **exemplos**; troque pelas ferramentas da sua stack.
-
-### 1. Componentes Visuais (Dumb)
-- **O que testar**: variações de estado (default, hover, disabled, error).
-- **Ferramentas típicas**: Storybook ou equivalente para documentação interativa.
-- **Exemplo**: `Button.stories.tsx` (ou similar na sua stack).
-
-### 2. Lógica de Estado / Domínio (Smart)
-- **O que testar**: hooks, serviços, regras de negócio.
-- **Ferramentas típicas**:
-  - JavaScript/TypeScript: Jest/Vitest + Testing Library.
-  - Python: pytest.
-  - Java: JUnit.
-- **Abordagem**: TDD sempre que possível em regras críticas.
-
-### 3. Fluxos de Usuário (E2E)
-- **O que testar**: jornadas completas (Login, Cadastro, Checkout etc.).
-- **Ferramentas típicas**: Playwright, Cypress, Selenium, etc.
-- **Abordagem**: documentar cenários críticos e evitar excesso de flakiness.
-
----
-
-## 🗂️ Estrutura de Arquivos (exemplo)
-
-Ajuste os caminhos de acordo com o framework real:
-
-- **API**: `[caminho/para/openapi.yaml]`
-- **Banco**: `[caminho/para/schema.prisma ou migrations/]`
-- **UI**: `[src/components/ui/]`
-- **Rotas**: `[src/app/api/ ou equivalente]`
-
----
-
-## 💬 Comportamento de Resposta da IA
-
-1. **Autonomia**: resolver em uma resposta quando possível, sem depender de múltiplas idas e vindas desnecessárias.
-2. **Clareza**: pedir esclarecimentos em casos ambíguos ao invés de supor demais.
-3. **Justificativa**: explicar decisões arquiteturais importantes com prós e contras.
-4. **Contexto**: sempre considerar o Tech Spec, o Playbook de Desenvolvimento com IA
-   e os especialistas relevantes ao responder.