npm - @maestro-ai/mcp-server - Versions diffs - 1.0.0 → 1.1.0 - Mend

@maestro-ai/mcp-server 1.0.0 → 1.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (448) hide show

package/dist/content/content/prompts/arquitetura/multi-tenancy.md DELETED Viewed

@@ -1,235 +0,0 @@
-# Prompt: Multi-tenancy
-> **Prioridade**: 🟡 MÉDIA
-> **Aplicável a**: SaaS, plataformas white-label, sistemas B2B
----
-## Prompt Base: Projetar Multi-tenancy
-```text
-Atue como arquiteto de software especialista em SaaS.
-Preciso implementar multi-tenancy para:
-- Tipo de produto: [ex. CRM SaaS, e-commerce white-label]
-- Número esperado de tenants: [ex. 100 / 10.000 / 1M]
-- Isolamento necessário: [ex. dados apenas / compliance rígido]
-- Customização por tenant: [ex. branding / features / workflows]
-Constraints:
-- Stack: [DESCREVA]
-- Orçamento de infra: [DESCREVA]
-- Time: [DESCREVA]
-Projete:
-1. **Modelo de Isolamento**
-   - Database per tenant, schema per tenant, ou row-level?
-   - Justificativa para o contexto
-   - Estratégia para tenants com necessidades especiais
-2. **Identificação de Tenant**
-   - Como identificar o tenant em cada request
-   - Subdomain, header, JWT, ou combinação
-   - Fallback se não identificado
-3. **Implementação de Dados**
-   - Schema das tabelas (com tenant_id)
-   - Middleware/interceptor para filtrar
-   - Como garantir que queries não vazem dados
-4. **Customização**
-   - Configurações por tenant
-   - Feature flags por plano
-   - Branding (logo, cores)
-5. **Operacional**
-   - Provisioning de novo tenant
-   - Migrations multi-tenant
-   - Backup/restore por tenant
-   - Monitoramento por tenant
-```
----
-## Prompt: Migrar para Multi-tenant
-```text
-Tenho um sistema single-tenant que precisa virar multi-tenant:
-[DESCREVA ESTRUTURA ATUAL]
-Requisitos:
-- Manter dados do tenant atual
-- Adicionar suporte a novos tenants
-- Mínimo de breaking changes
-- Timeline: [PRAZO]
-Gere um plano de migração com:
-1. Alterações de schema (adicionar tenant_id)
-2. Migrations de dados existentes
-3. Mudanças de código (queries, middlewares)
-4. Testes de validação
-5. Rollout gradual
-```
----
-## Prompt: Implementar Row-Level Security
-```text
-Preciso implementar isolamento por row-level security.
-Stack: [ex. PostgreSQL + Prisma + Node.js]
-Tabelas principais:
-[LISTE TABELAS]
-Gere:
-1. Migrations para adicionar tenant_id
-2. Policies RLS no PostgreSQL
-3. Middleware para setar current_tenant
-4. Repository base com tenant scope
-5. Testes de isolamento
-```
----
-## Prompt: Tenant Provisioning
-```text
-Preciso automatizar o onboarding de novos tenants.
-Quando um novo tenant é criado, preciso:
-- [ex. Criar registro no banco]
-- [ex. Configurar subdomain no DNS]
-- [ex. Criar usuário admin]
-- [ex. Popular dados iniciais]
-- [ex. Enviar email de boas-vindas]
-Stack: [DESCREVA]
-Gere:
-1. Endpoint/workflow de provisioning
-2. Jobs assíncronos necessários
-3. Rollback se algum step falhar
-4. Notificações de progresso
-5. Documentação do processo
-```
----
-## Prompt: Limites e Quotas por Tenant
-```text
-Preciso implementar limites por plano:
-| Recurso | Free | Pro | Enterprise |
-|---------|------|-----|------------|
-| Usuários | 5 | 50 | Ilimitado |
-| Storage | 1GB | 10GB | 100GB |
-| API calls/dia | 1000 | 10000 | Ilimitado |
-| Features | [X,Y] | [X,Y,Z] | Todas |
-Stack: [DESCREVA]
-Gere:
-1. Schema para quotas e usage tracking
-2. Service para verificar limites
-3. Middleware para bloquear quando excede
-4. Dashboard de usage para tenant admin
-5. Alerts quando próximo do limite
-```
----
-## Exemplo: Tenant Context Completo
-```typescript
-// src/tenancy/TenantContext.ts
-import { AsyncLocalStorage } from 'async_hooks';
-import { PrismaClient } from '@prisma/client';
-interface TenantContext {
-  tenantId: string;
-  config: TenantConfig;
-  user?: User;
-}
-interface TenantConfig {
-  id: string;
-  subdomain: string;
-  plan: 'free' | 'pro' | 'enterprise';
-  quotas: {
-    maxUsers: number;
-    maxStorage: number;
-    maxApiCalls: number;
-  };
-  features: string[];
-}
-const storage = new AsyncLocalStorage<TenantContext>();
-// Middleware
-export async function tenantMiddleware(req, res, next) {
-  const tenantId = extractTenantIdFromRequest(req);
-  if (!tenantId) {
-    return res.status(400).json({ error: 'Tenant not found' });
-  }
-  const config = await loadTenantConfig(tenantId);
-  storage.run({ tenantId, config }, next);
-}
-// Getters
-export function getTenant(): TenantContext {
-  const ctx = storage.getStore();
-  if (!ctx) throw new Error('No tenant context');
-  return ctx;
-}
-export function getTenantId(): string {
-  return getTenant().tenantId;
-}
-export function hasFeature(feature: string): boolean {
-  return getTenant().config.features.includes(feature);
-}
-// Prisma extension para injetar tenant automaticamente
-export const prisma = new PrismaClient().$extends({
-  query: {
-    $allModels: {
-      async findMany({ args, query }) {
-        args.where = { ...args.where, tenantId: getTenantId() };
-        return query(args);
-      },
-      async create({ args, query }) {
-        args.data = { ...args.data, tenantId: getTenantId() };
-        return query(args);
-      },
-      // ... outras operações
-    }
-  }
-});
-```
----
-## Checklist
-- [ ] Modelo de isolamento definido
-- [ ] Identificação de tenant implementada
-- [ ] Todas as queries filtram por tenant
-- [ ] Testes de isolamento automatizados
-- [ ] Provisioning automatizado
-- [ ] Limites e quotas por plano
-- [ ] Monitoramento por tenant
-- [ ] Documentação de onboarding
----
-## Referências
-Consulte: [Guia de Multi-tenancy](../03-guias/Guia%20de%20Multi-tenancy.md)

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

@@ -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/content/prompts/database/otimizacao-queries.md DELETED Viewed

@@ -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`