@maestro-ai/mcp-server 1.2.0 → 2.0.0

package/dist/content/prompts/database/migrations-zero-downtime.md

@@ -1,192 +0,0 @@
-# Prompt: Database Migrations Zero-Downtime
-
-> **Prioridade**: 🟠 ALTA  
-> **Aplicável a**: Sistemas em produção com tráfego contínuo
-
----
-
-## Contexto
-
-Migrations tradicionais podem causar downtime ou erros quando aplicadas em sistemas ativos. Este prompt ajuda a planejar migrations seguras.
-
----
-
-## Prompt Base: Planejar Migration
-
-```text
-Atue como DBA especialista em migrations zero-downtime.
-
-Preciso fazer a seguinte alteração no banco de dados:
-[DESCREVA A ALTERAÇÃO: ex. renomear coluna, alterar tipo, adicionar índice]
-
-Contexto:
-- Banco: [PostgreSQL/MySQL/SQL Server]
-- Tamanho da tabela: [ex. 5 milhões de registros]
-- Tráfego: [ex. 100 writes/min]
-- Deploy: [blue-green/rolling/single server]
-
-Gere um plano de migration com:
-
-1. **Análise de Risco**
-   - A operação bloqueia a tabela?
-   - Tempo estimado de execução
-   - Impacto em queries ativas
-
-2. **Estratégia de Migration**
-   - Quantos deploys são necessários?
-   - Ordem das alterações
-   - Scripts SQL para cada step
-
-3. **Backward Compatibility**
-   - Como manter código antigo funcionando?
-   - Triggers ou dual-write necessários?
-
-4. **Rollback Plan**
-   - Como reverter cada step?
-   - Dados perdidos em rollback?
-
-5. **Monitoramento**
-   - O que observar durante a migration?
-   - Alertas a configurar
-
-Siga o padrão Expand-Contract quando aplicável.
-```
-
----
-
-## Prompt: Migrar Coluna com Dados
-
-```text
-Tenho uma coluna que precisa ser transformada:
-- Tabela: [NOME]
-- Coluna atual: [NOME, TIPO]
-- Transformação: [ex. split em duas colunas, mudar encoding, converter unidade]
-- Registros: [QUANTIDADE]
-
-Stack: [DESCREVA ORM/Framework]
-
-Gere:
-1. Scripts SQL para cada fase (expand, migrate, contract)
-2. Job de backfill com batches
-3. Código para dual-write durante transição
-4. Verificações de integridade após migration
-```
-
----
-
-## Prompt: Adicionar Índice em Tabela Grande
-
-```text
-Preciso adicionar um índice para melhorar performance:
-- Tabela: [NOME], [X milhões de registros]
-- Índice: [COLUNAS, TIPO]
-- Banco: [PostgreSQL/MySQL]
-- Tolerância a downtime: [zero/alguns segundos]
-
-Gere:
-1. Comando para criar índice sem bloquear (CONCURRENTLY, ONLINE)
-2. Estimativa de tempo baseada no tamanho
-3. Monitoramento durante criação
-4. Verificação de que o índice está sendo usado
-5. Plano B se a criação falhar
-```
-
----
-
-## Prompt: Revisar Migration Existente
-
-```text
-Tenho este script de migration:
-[COLE O SCRIPT]
-
-Contexto:
-- Ambiente: produção com [X] req/s
-- Deploy: [TIPO]
-- Banco: [TIPO E VERSÃO]
-
-Analise:
-1. Há operações que bloqueiam tabelas?
-2. É backward compatible?
-3. O rollback é possível?
-4. Há riscos de perda de dados?
-
-Sugira versão zero-downtime se necessário.
-```
-
----
-
-## Exemplo: Migration Segura Completa
-
-### Cenário: Renomear `name` para `full_name`
-
-```sql
--- DEPLOY 1: Expand
--- Adiciona nova coluna
-ALTER TABLE users ADD COLUMN full_name VARCHAR(255);
-
--- Cria trigger para sincronizar
-CREATE OR REPLACE FUNCTION sync_user_name()
-RETURNS TRIGGER AS $$
-BEGIN
-    IF NEW.full_name IS NULL THEN
-        NEW.full_name := NEW.name;
-    END IF;
-    IF NEW.name IS NULL THEN
-        NEW.name := NEW.full_name;
-    END IF;
-    RETURN NEW;
-END;
-$$ LANGUAGE plpgsql;
-
-CREATE TRIGGER trg_sync_user_name
-BEFORE INSERT OR UPDATE ON users
-FOR EACH ROW EXECUTE FUNCTION sync_user_name();
-```
-
-```python
-# DEPLOY 1: Código dual-write
-class User:
-    def save(self):
-        self.full_name = self.name  # Sync
-        db.save(self)
-```
-
-```sql
--- DEPLOY 1: Backfill (pode rodar após deploy)
-UPDATE users SET full_name = name WHERE full_name IS NULL;
--- Em batches para tabelas grandes:
--- UPDATE users SET full_name = name WHERE full_name IS NULL LIMIT 10000;
-```
-
-```python
-# DEPLOY 2: Código usa nova coluna
-class User:
-    @property
-    def display_name(self):
-        return self.full_name  # Usa nova coluna
-```
-
-```sql
--- DEPLOY 3: Contract (após confirmar que nenhum código antigo está ativo)
-DROP TRIGGER trg_sync_user_name ON users;
-DROP FUNCTION sync_user_name();
-ALTER TABLE users DROP COLUMN name;
-```
-
----
-
-## Checklist
-
-- [ ] Testei em staging com dados similares a produção
-- [ ] Medi tempo de execução em tabela grande
-- [ ] Documentei cada step e ordem de execução
-- [ ] Preparei scripts de rollback
-- [ ] Informei time sobre janela de migration
-- [ ] Backup recente existe e foi testado
-- [ ] Monitoramento configurado
-
----
-
-## Referências
-
-Consulte: [Guia de Migrations Zero-Downtime](../03-guias/Guia%20de%20Migrations%20Zero-Downtime.md)

package/dist/content/prompts/database/otimizacao-queries.md

@@ -1,296 +0,0 @@
-# Prompt: Otimização de Queries e Banco de Dados
-
-> **Quando usar**: Ao identificar queries lentas ou planejar schema de banco
-> **Especialista**: DBA / [Performance e Escalabilidade](../../02-especialistas/Especialista%20em%20Performance%20e%20Escalabilidade.md)
-> **Nível**: Médio a Complexo
-
----
-
-## Fluxo de Contexto
-
-Antes de usar este prompt, tenha em mãos:
-- Schema atual do banco ou modelo de domínio
-- Queries problemáticas (se houver)
-- Volume de dados esperado
-
-Após gerar, salve o resultado em:
-- `docs/07-performance/otimizacao-database.md`
-
----
-
-## Prompt Completo
-
-```text
-Atue como DBA sênior especializado em otimização de banco de dados.
-
-## Contexto do Projeto
-
-[COLE BREVE DESCRIÇÃO DO SISTEMA]
-
-## Banco de Dados
-
-Tipo: [PostgreSQL/MySQL/MongoDB/etc]
-Versão: [Versão]
-Cloud: [RDS/Cloud SQL/Atlas/Self-hosted]
-Tamanho atual: [XGB de dados]
-Tamanho esperado: [X em 1 ano]
-
-## Schema Atual
-
-```sql
-[COLE O SCHEMA DDL OU DESCREVA AS TABELAS]
-```
-
-## Queries Problemáticas (se houver)
-
-```sql
--- Query 1: [Descrição]
-[QUERY SQL]
--- Tempo atual: Xms
--- Frequência: Y vezes/dia
-```
-
-## Volume de Dados
-
-- Tabela X: ~N registros, crescimento K/mês
-- Tabela Y: ~N registros, crescimento K/mês
-
----
-
-## Sua Missão
-
-Analise e otimize o banco de dados:
-
-### 1. Análise de Schema
-
-#### 1.1 Tipos de Dados
-- Tipos apropriados para cada coluna?
-- Tamanhos excessivos (VARCHAR(255) desnecessário)?
-- Nullable vs NOT NULL corretos?
-
-#### 1.2 Normalização
-- Está na forma normal adequada (3NF)?
-- Há desnormalização intencional justificada?
-- Redundância de dados?
-
-#### 1.3 Relacionamentos
-- Foreign keys definidas?
-- Cascade appropriado?
-- Índices em FKs?
-
-### 2. Análise de Índices
-
-#### 2.1 Índices Existentes
-- Estão sendo utilizados?
-- Há índices duplicados?
-- Ordem das colunas correta?
-
-#### 2.2 Índices Sugeridos
-Para cada índice sugerido:
-- Colunas e ordem
-- Tipo (B-tree, Hash, GIN, GiST)
-- Justificativa (queries beneficiadas)
-- Impacto em writes
-
-#### 2.3 Índices para Remover
-- Índices não utilizados
-- Índices duplicados
-
-### 3. Otimização de Queries
-
-Para cada query problemática:
-
-#### 3.1 EXPLAIN ANALYZE
-```sql
-EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) [QUERY];
-```
-
-#### 3.2 Problemas Identificados
-- Sequential scans em tabelas grandes?
-- Nested loops com muitas iterações?
-- Sort em memória vs disco?
-- Hash joins custosos?
-
-#### 3.3 Query Otimizada
-```sql
--- Query original
-[QUERY ORIGINAL]
-
--- Query otimizada
-[QUERY OTIMIZADA]
-
--- Ganho: de Xms para Yms (Z% melhoria)
-```
-
-### 4. Design de Schema (se aplicável)
-
-Para novas tabelas ou refatoração:
-
-#### 4.1 DDL Otimizado
-```sql
-CREATE TABLE tabela (
-  -- colunas com tipos otimizados
-);
-
--- Índices
-CREATE INDEX ...;
-
--- Constraints
-ALTER TABLE ...;
-```
-
-#### 4.2 Particionamento
-- Candidatos a particionamento
-- Estratégia (range, list, hash)
-- Manutenção de partições
-
-### 5. Connection Pooling
-
-- Pool size recomendado
-- Timeout configurations
-- Tool recomendada (PgBouncer, ProxySQL)
-
-### 6. Vacuum e Manutenção (PostgreSQL)
-
-- Vacuum strategy
-- autovacuum settings
-- Bloat monitoring
-- REINDEX frequency
-
-### 7. Migrations
-
-Se sugerir alterações de schema:
-```sql
--- Migration up
-ALTER TABLE ...;
-
--- Migration down (rollback)
-ALTER TABLE ...;
-```
-
-### 8. Métricas e Monitoramento
-
-- Métricas essenciais
-- Queries lentas (slow query log)
-- Alertas recomendados
-```
-
----
-
-## Exemplo de Uso
-
-```text
-Atue como DBA sênior especializado em otimização de banco de dados.
-
-## Contexto do Projeto
-
-Sistema de agendamento para salões de beleza.
-Consultas frequentes de disponibilidade.
-
-## Banco de Dados
-
-Tipo: PostgreSQL
-Versão: 15
-Cloud: AWS RDS (db.t3.medium)
-Tamanho atual: 2GB
-Tamanho esperado: 50GB em 1 ano
-
-## Schema Atual
-
-```sql
-CREATE TABLE clientes (
-  id UUID PRIMARY KEY,
-  nome VARCHAR(255),
-  telefone VARCHAR(255),
-  email VARCHAR(255),
-  criado_em TIMESTAMP
-);
-
-CREATE TABLE agendamentos (
-  id UUID PRIMARY KEY,
-  cliente_id UUID REFERENCES clientes(id),
-  profissional_id UUID REFERENCES profissionais(id),
-  servico_id UUID REFERENCES servicos(id),
-  data_hora TIMESTAMP,
-  status VARCHAR(50),
-  criado_em TIMESTAMP
-);
-```
-
-## Queries Problemáticas
-
-```sql
--- Query 1: Buscar disponibilidade de um profissional
-SELECT * FROM agendamentos 
-WHERE profissional_id = $1 
-AND data_hora BETWEEN $2 AND $3
-AND status != 'CANCELADO';
--- Tempo atual: 800ms
--- Frequência: 1000 vezes/dia
-```
-
-## Volume de Dados
-
-- clientes: ~10.000 registros, +500/mês
-- agendamentos: ~100.000 registros, +5.000/mês
-```
-
----
-
-## Resposta Esperada
-
-### Schema Otimizado
-
-```sql
--- Problema: VARCHAR(255) excessivo e sem índices
--- Correção: tipos adequados e índices
-
-ALTER TABLE clientes ALTER COLUMN telefone TYPE VARCHAR(20);
-ALTER TABLE clientes ALTER COLUMN email TYPE VARCHAR(100);
-ALTER TABLE agendamentos ALTER COLUMN status TYPE VARCHAR(20);
-
--- Índices para a query de disponibilidade
-CREATE INDEX idx_agendamentos_disponibilidade 
-ON agendamentos (profissional_id, data_hora) 
-WHERE status != 'CANCELADO';
-```
-
-### Query Otimizada
-
-```sql
--- EXPLAIN original: Seq Scan (800ms)
--- EXPLAIN otimizado: Index Scan (15ms)
-
--- Query otimizada (mesma, mas usando índice parcial)
-SELECT id, cliente_id, servico_id, data_hora, status
-FROM agendamentos 
-WHERE profissional_id = $1 
-  AND data_hora >= $2 
-  AND data_hora < $3
-  AND status != 'CANCELADO';
-
--- Ganho: de 800ms para 15ms (98% melhoria)
-```
-
-### Índices Recomendados
-
-| Tabela | Índice | Tipo | Justificativa |
-|--------|--------|------|---------------|
-| agendamentos | (profissional_id, data_hora) | B-tree parcial | Query de disponibilidade |
-| agendamentos | (cliente_id, data_hora) | B-tree | Histórico do cliente |
-| agendamentos | (data_hora) | B-tree | Relatórios por período |
-
----
-
-## Checklist Pós-Geração
-
-- [ ] Tipos de dados otimizados
-- [ ] Índices sugeridos com justificativa
-- [ ] EXPLAIN ANALYZE das queries
-- [ ] Queries otimizadas com ganho estimado
-- [ ] Connection pooling configurado
-- [ ] Particionamento avaliado (se dados grandes)
-- [ ] Vacuum/maintenance configurado
-- [ ] Métricas de monitoramento
-- [ ] Migrations para alterações
-- [ ] Salvar em `docs/07-performance/otimizacao-database.md`