@maestro-ai/mcp-server 1.2.0 → 2.1.0

package/dist/content/guides/Guia de Multi-tenancy.md

@@ -1,368 +0,0 @@
-# Guia de Multi-tenancy
-
-> **Prioridade**: 🟡 MÉDIA  
-> **Aplicável a**: SaaS, plataformas com múltiplos clientes/organizações
-
----
-
-## O que é Multi-tenancy?
-
-Multi-tenancy é uma arquitetura onde uma única instância de software serve múltiplos clientes (tenants) com isolamento de dados.
-
-```
-┌─────────────────────────────────────────────────────────┐
-│                    Aplicação SaaS                       │
-├─────────────────────────────────────────────────────────┤
-│  Tenant A  │  Tenant B  │  Tenant C  │  Tenant D        │
-│  (Empresa X)│ (Empresa Y) │ (Startup Z)│ (Corp W)       │
-└─────────────────────────────────────────────────────────┘
-```
-
----
-
-## Modelos de Isolamento
-
-### 1. Database per Tenant
-
-Cada tenant tem seu próprio banco de dados.
-
-```mermaid
-graph TD
-    App[Aplicação] --> DB1[(Tenant A DB)]
-    App --> DB2[(Tenant B DB)]
-    App --> DB3[(Tenant C DB)]
-```
-
-| Prós | Contras |
-|------|---------|
-| Isolamento máximo | Maior custo de infra |
-| Fácil backups por tenant | Complexidade operacional |
-| Boa para compliance | Migrations em muitos DBs |
-| Customização por tenant | Não escala para muitos tenants |
-
-**Usar quando**: Enterprise customers, compliance rígido (HIPAA, PCI), <100 tenants
-
-### 2. Schema per Tenant
-
-Um banco, mas schemas separados por tenant.
-
-```mermaid
-graph TD
-    App[Aplicação] --> DB[(Database)]
-    DB --> S1[schema_tenant_a]
-    DB --> S2[schema_tenant_b]
-    DB --> S3[schema_tenant_c]
-```
-
-| Prós | Contras |
-|------|---------|
-| Bom isolamento | Migrations por schema |
-| Mais barato que DB separado | Limite de schemas |
-| Fácil backup por tenant | Consultas cross-tenant complexas |
-
-**Usar quando**: Poucas centenas de tenants, isolamento importante
-
-### 3. Row-Level Security (Shared Database)
-
-Todos os tenants na mesma tabela, filtrados por tenant_id.
-
-```sql
--- Todas as tabelas têm tenant_id
-CREATE TABLE orders (
-    id UUID PRIMARY KEY,
-    tenant_id UUID NOT NULL,
-    customer_name VARCHAR(255),
-    ...
-);
-
-CREATE INDEX idx_orders_tenant ON orders(tenant_id);
-```
-
-| Prós | Contras |
-|------|---------|
-| Escala para milhares de tenants | Risco de vazamento de dados |
-| Operação simples | Queries precisam sempre filtrar |
-| Migrations únicas | Backup por tenant é complexo |
-| Menor custo | Menos isolamento de performance |
-
-**Usar quando**: Muitos tenants pequenos (1000+), dados similares, startups
-
-### 4. Híbrido
-
-Tenants pequenos compartilham, grandes têm DB próprio.
-
-```mermaid
-graph TD
-    App[Aplicação] --> DB1[(Shared DB)]
-    App --> DB2[(Enterprise A DB)]
-    App --> DB3[(Enterprise B DB)]
-    DB1 --> T1[tenant_1..99]
-```
-
-**Usar quando**: Freemium + Enterprise, mix de necessidades
-
----
-
-## Implementação: Row-Level Security
-
-### PostgreSQL RLS
-
-```sql
--- Habilitar RLS
-ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
-
--- Policy: usuários só veem dados do seu tenant
-CREATE POLICY tenant_isolation ON orders
-    FOR ALL
-    USING (tenant_id = current_setting('app.current_tenant')::uuid);
-
--- No código, antes de cada requisição:
--- SET app.current_tenant = 'tenant-uuid';
-```
-
-### Middleware de Tenant (Node.js)
-
-```typescript
-// middleware/tenantContext.ts
-import { AsyncLocalStorage } from 'async_hooks';
-
-interface TenantContext {
-  tenantId: string;
-  tenantConfig?: TenantConfig;
-}
-
-export const tenantStorage = new AsyncLocalStorage<TenantContext>();
-
-export function tenantMiddleware(req, res, next) {
-  // Extrair tenant de: subdomain, header, JWT, etc.
-  const tenantId = extractTenantId(req);
-  
-  if (!tenantId) {
-    return res.status(400).json({ error: 'Tenant not identified' });
-  }
-
-  tenantStorage.run({ tenantId }, () => {
-    // Setar no Prisma/TypeORM para RLS
-    db.$executeRaw`SET app.current_tenant = ${tenantId}`;
-    next();
-  });
-}
-
-function extractTenantId(req): string | null {
-  // Opção 1: Subdomain (tenant1.app.com)
-  const subdomain = req.hostname.split('.')[0];
-  if (subdomain !== 'www' && subdomain !== 'app') {
-    return getTenantIdBySubdomain(subdomain);
-  }
-  
-  // Opção 2: Header
-  if (req.headers['x-tenant-id']) {
-    return req.headers['x-tenant-id'];
-  }
-  
-  // Opção 3: JWT claim
-  if (req.user?.tenantId) {
-    return req.user.tenantId;
-  }
-  
-  return null;
-}
-
-// Helper para acessar tenant em qualquer lugar
-export function getCurrentTenant(): TenantContext {
-  const context = tenantStorage.getStore();
-  if (!context) throw new Error('No tenant context');
-  return context;
-}
-```
-
-### Repository Pattern com Tenant Scope
-
-```typescript
-// repositories/BaseRepository.ts
-import { getCurrentTenant } from '../middleware/tenantContext';
-
-export abstract class BaseRepository<T> {
-  protected abstract tableName: string;
-
-  async findAll(): Promise<T[]> {
-    const { tenantId } = getCurrentTenant();
-    return db.query(
-      `SELECT * FROM ${this.tableName} WHERE tenant_id = $1`,
-      [tenantId]
-    );
-  }
-
-  async findById(id: string): Promise<T | null> {
-    const { tenantId } = getCurrentTenant();
-    return db.queryOne(
-      `SELECT * FROM ${this.tableName} WHERE id = $1 AND tenant_id = $2`,
-      [id, tenantId]
-    );
-  }
-
-  async create(data: Omit<T, 'id' | 'tenant_id'>): Promise<T> {
-    const { tenantId } = getCurrentTenant();
-    return db.insert(this.tableName, { ...data, tenant_id: tenantId });
-  }
-}
-
-// Uso
-class OrderRepository extends BaseRepository<Order> {
-  tableName = 'orders';
-  
-  async findByStatus(status: string): Promise<Order[]> {
-    const { tenantId } = getCurrentTenant();
-    return db.query(
-      `SELECT * FROM orders WHERE status = $1 AND tenant_id = $2`,
-      [status, tenantId]
-    );
-  }
-}
-```
-
----
-
-## Identificação de Tenant
-
-| Método | Exemplo | Prós | Contras |
-|--------|---------|------|---------|
-| **Subdomain** | `acme.app.com` | Óbvio para usuário | DNS/SSL por tenant |
-| **Path** | `app.com/acme/...` | Simples | Polui URLs |
-| **Header** | `X-Tenant-ID` | Limpo | Só para APIs |
-| **JWT Claim** | `{ tenantId: '...' }` | Seguro, autenticado | Precisa de auth |
-| **Query Param** | `?tenant=acme` | Fácil testar | Fácil vazar |
-
-**Recomendação**: Subdomain para apps, Header/JWT para APIs.
-
----
-
-## Customização por Tenant
-
-### Configurações
-
-```typescript
-interface TenantConfig {
-  id: string;
-  name: string;
-  subdomain: string;
-  plan: 'free' | 'pro' | 'enterprise';
-  features: {
-    maxUsers: number;
-    customBranding: boolean;
-    ssoEnabled: boolean;
-    apiAccess: boolean;
-  };
-  branding?: {
-    logo: string;
-    primaryColor: string;
-  };
-}
-
-// Cache de config por tenant
-const tenantConfigCache = new Map<string, TenantConfig>();
-
-async function getTenantConfig(tenantId: string): Promise<TenantConfig> {
-  if (tenantConfigCache.has(tenantId)) {
-    return tenantConfigCache.get(tenantId)!;
-  }
-  
-  const config = await db.tenants.findById(tenantId);
-  tenantConfigCache.set(tenantId, config);
-  return config;
-}
-```
-
-### Feature Flags por Tenant
-
-```typescript
-async function hasFeature(feature: string): Promise<boolean> {
-  const { tenantId } = getCurrentTenant();
-  const config = await getTenantConfig(tenantId);
-  return config.features[feature] === true;
-}
-
-// Uso
-if (await hasFeature('ssoEnabled')) {
-  // Mostrar opções de SSO
-}
-```
-
----
-
-## Segurança
-
-### Checklist de Isolamento
-
-- [ ] Todas as queries filtram por tenant_id
-- [ ] Índices incluem tenant_id
-- [ ] Uploads/Storage segregados por tenant
-- [ ] Logs incluem tenant para auditoria
-- [ ] Rate limiting por tenant
-- [ ] Testes verificam isolamento
-
-### Testes de Isolamento
-
-```typescript
-describe('Tenant Isolation', () => {
-  it('should not access data from other tenants', async () => {
-    // Setup: criar dados em dois tenants
-    await asTenant('tenant-a', async () => {
-      await orderRepo.create({ product: 'A' });
-    });
-    
-    await asTenant('tenant-b', async () => {
-      await orderRepo.create({ product: 'B' });
-    });
-
-    // Verificar isolamento
-    await asTenant('tenant-a', async () => {
-      const orders = await orderRepo.findAll();
-      expect(orders.every(o => o.tenant_id === 'tenant-a')).toBe(true);
-      expect(orders.find(o => o.product === 'B')).toBeUndefined();
-    });
-  });
-});
-```
-
----
-
-## Migrations Multi-tenant
-
-### Para Shared Database
-
-```sql
--- Migration normal - aplica para todos
-ALTER TABLE orders ADD COLUMN priority INT DEFAULT 0;
-```
-
-### Para Schema per Tenant
-
-```bash
-# Script para aplicar migration em todos os schemas
-for schema in $(psql -t -c "SELECT schema_name FROM information_schema.schemata WHERE schema_name LIKE 'tenant_%'"); do
-  psql -c "SET search_path TO $schema; -- migration SQL here;"
-done
-```
-
----
-
-## Checklist de Implementação
-
-- [ ] Modelo de isolamento escolhido e documentado
-- [ ] Middleware de identificação de tenant
-- [ ] Todas as queries incluem tenant_id
-- [ ] Testes de isolamento automatizados
-- [ ] Config/features por tenant
-- [ ] Rate limiting por tenant
-- [ ] Logs e métricas por tenant
-- [ ] Backup/restore por tenant (se necessário)
-- [ ] Provisioning de novo tenant automatizado
-
----
-
-## Referências
-
-- [Multi-tenancy Patterns (Microsoft)](https://docs.microsoft.com/en-us/azure/architecture/guide/multitenant/overview)
-- [PostgreSQL Row-Level Security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)
-- [Multi-tenant SaaS Patterns (AWS)](https://aws.amazon.com/solutions/implementations/saas-tenant-isolation/)

package/dist/content/guides/Guia de Otimiza/303/247/303/243o de Custos Cloud.md"

@@ -1,195 +0,0 @@
-# Guia de Otimização de Custos Cloud
-
-> **Prioridade**: 🟢 BAIXA  
-> **Aplicável a**: Projetos em produção com custos significativos de cloud
-
----
-
-## Por que Otimizar?
-
-Cloud custa caro se não for gerenciada. Otimização pode reduzir 20-50% dos custos sem impacto em performance.
-
----
-
-## Pilares de Otimização
-
-### 1. Right-Sizing
-
-Usar instâncias do tamanho certo para a carga.
-
-| Sinal | Problema | Ação |
-|-------|----------|------|
-| CPU < 20% constante | Superdimensionado | Diminuir tier |
-| CPU > 80% frequente | Subdimensionado | Aumentar ou escalar |
-| Memória < 30% usada | Superdimensionado | Diminuir tier |
-| Picos curtos, idle longo | Má distribuição | Considerar serverless |
-
-### 2. Reserved Instances / Savings Plans
-
-| Tipo | Desconto | Trade-off |
-|------|----------|-----------|
-| On-Demand | 0% | Flexibilidade total |
-| Reserved 1 ano | 30-40% | Compromisso |
-| Reserved 3 anos | 50-60% | Compromisso maior |
-| Spot/Preemptible | 60-90% | Pode ser terminado |
-
-**Regra**: Reserve workloads estáveis, on-demand para variáveis.
-
-### 3. Auto-Scaling
-
-```yaml
-# Exemplo AWS Auto Scaling
-ScalingPolicy:
-  - Name: scale-on-cpu
-    MetricType: CPUUtilization
-    TargetValue: 70
-    ScaleInCooldown: 300
-    ScaleOutCooldown: 60
-```
-
-### 4. Storage Optimization
-
-| Classe | Custo | Uso |
-|--------|-------|-----|
-| Standard | $$$ | Acesso frequente |
-| Infrequent Access | $$ | Acesso mensal |
-| Glacier/Archive | $ | Backups, compliance |
-
-**Política de Lifecycle**:
-```json
-{
-  "Rules": [{
-    "ID": "ArchiveOldData",
-    "Filter": { "Prefix": "logs/" },
-    "Transitions": [
-      { "Days": 30, "StorageClass": "STANDARD_IA" },
-      { "Days": 90, "StorageClass": "GLACIER" }
-    ],
-    "Expiration": { "Days": 365 }
-  }]
-}
-```
-
-### 5. Database Optimization
-
-| Estratégia | Economia |
-|------------|----------|
-| Read replicas para leitura | Menos carga no primário |
-| Serverless DB (Aurora, PlanetScale) | Paga por uso |
-| Indices eficientes | Menos CPU |
-| Query optimization | Menos tempo de CPU |
-| Connection pooling | Menos instâncias |
-
-### 6. Containerização e Serverless
-
-| Workload | Melhor Opção |
-|----------|--------------|
-| Carga constante 24/7 | Containers (ECS, GKE) |
-| Picos esporádicos | Serverless (Lambda, Cloud Run) |
-| Batch jobs | Spot instances + containers |
-| APIs leves | Serverless |
-
----
-
-## Checklist de Auditoria de Custos
-
-### Compute
-- [ ] Instâncias idle identificadas e terminadas
-- [ ] Right-sizing aplicado baseado em métricas
-- [ ] Reserved instances para workloads estáveis
-- [ ] Spot instances para workloads tolerantes
-- [ ] Auto-scaling configurado corretamente
-
-### Storage
-- [ ] Buckets/volumes não utilizados deletados
-- [ ] Lifecycle policies configuradas
-- [ ] Snapshots antigos removidos
-- [ ] EBS volumes orfãos identificados
-- [ ] Classe de storage correta por tipo de dado
-
-### Network
-- [ ] Data transfer entre regiões minimizado
-- [ ] NAT Gateway otimizado (VPC endpoints)
-- [ ] CDN para conteúdo estático
-- [ ] Endpoints privados quando possível
-
-### Database
-- [ ] Instâncias provisionadas corretamente
-- [ ] Read replicas só onde necessário
-- [ ] Backups retidos pelo tempo correto
-- [ ] Queries otimizadas (índices)
-
----
-
-## Ferramentas de Análise
-
-| Provedor | Ferramenta |
-|----------|-----------|
-| **AWS** | Cost Explorer, Trusted Advisor, Compute Optimizer |
-| **GCP** | Cost Management, Recommender |
-| **Azure** | Cost Management, Advisor |
-| **Multi-cloud** | Kubecost, CloudHealth, Infracost |
-
----
-
-## Budget e Alertas
-
-```yaml
-# AWS Budget example
-Budget:
-  Name: MonthlyBudget
-  Amount: 5000
-  TimeUnit: MONTHLY
-  Notifications:
-    - ThresholdPercentage: 50
-      NotificationType: ACTUAL
-      Recipients: [team@company.com]
-    - ThresholdPercentage: 80
-      NotificationType: ACTUAL
-      Recipients: [finance@company.com, team@company.com]
-    - ThresholdPercentage: 100
-      NotificationType: FORECASTED
-      Recipients: [all-hands@company.com]
-```
-
----
-
-## Métricas para Monitorar
-
-| Métrica | Meta |
-|---------|------|
-| Custo por request | Tendência de queda |
-| Custo por usuário | Estável ou queda |
-| % de Reserved usage | > 80% |
-| Recursos idle | 0 |
-| Custo vs Budget | < 100% |
-
----
-
-## Quick Wins
-
-1. **Desligar ambientes dev/staging fora do horário**
-   ```bash
-   # Lambda para desligar EC2 à noite
-   aws ec2 stop-instances --instance-ids $(filter-dev-instances)
-   ```
-
-2. **Tagging para identificar ownership**
-   ```yaml
-   Tags:
-     Environment: production
-     Team: backend
-     CostCenter: engineering
-   ```
-
-3. **Alertas de custo diário**
-
-4. **Revisão mensal de custos** (cerimônia do time)
-
----
-
-## Referências
-
-- [AWS Well-Architected - Cost Optimization](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/)
-- [GCP Cost Optimization](https://cloud.google.com/architecture/framework/cost-optimization)
-- [FinOps Foundation](https://www.finops.org/)

package/dist/content/guides/Guia de Refatora/303/247/303/243o de C/303/263digo Legado com IA.md"

@@ -1,162 +0,0 @@
-# Guia de Refatoração de Código Legado com IA
-
-Fluxo estruturado para modernizar código existente com apoio de IA.
-
----
-
-## Quando Refatorar
-
-- Código difícil de entender ou modificar
-- Testes inexistentes ou frágeis
-- Padrões desatualizados
-- Performance inadequada
-- Dívida técnica acumulada
-
----
-
-## Fluxo de Refatoração
-
-```
-1. Análise → 2. Testes → 3. Refatoração → 4. Validação → 5. Documentação
-```
-
----
-
-## 1. Análise do Código
-
-### Identificar code smells
-
-```text
-Atue como revisor de código sênior.
-
-Aqui está um módulo/classe legado:
-[COLE CÓDIGO]
-
-Identifique:
-- Code smells presentes (God Class, Long Method, etc.)
-- Violações de SOLID
-- Oportunidades de simplificação
-- Dependências problemáticas
-
-Priorize por impacto e facilidade de correção.
-```
-
-### Entender lógica existente
-
-```text
-Este código foi escrito há anos e preciso entendê-lo:
-[COLE CÓDIGO]
-
-Explique:
-- O que este código faz
-- Fluxo principal de execução
-- Dependências externas
-- Casos de borda tratados
-```
-
----
-
-## 2. Adicionar Testes (antes de refatorar)
-
-```text
-Aqui está uma função/classe que vou refatorar:
-[COLE CÓDIGO]
-
-Gere testes de caracterização que capturem o comportamento atual:
-- Casos de uso principais
-- Casos de borda
-- Comportamento com inputs inválidos
-
-Use [FRAMEWORK DE TESTES].
-```
-
----
-
-## 3. Refatoração Incremental
-
-### Extrair método
-
-```text
-Este método está muito longo:
-[COLE CÓDIGO]
-
-Sugira extrações de métodos que:
-- Melhorem legibilidade
-- Sigam SRP (Single Responsibility)
-- Mantenham comportamento idêntico
-```
-
-### Simplificar condicionais
-
-```text
-Estas condicionais estão complexas:
-[COLE CÓDIGO]
-
-Refatore usando:
-- Early returns
-- Guard clauses
-- Polimorfismo (se apropriado)
-```
-
-### Modernizar sintaxe
-
-```text
-Este código usa padrões antigos de [LINGUAGEM]:
-[COLE CÓDIGO]
-
-Modernize para usar:
-- Sintaxe atual da linguagem
-- Padrões idiomáticos
-- Recursos modernos (async/await, destructuring, etc.)
-```
-
----
-
-## 4. Validação
-
-- [ ] Todos os testes passando
-- [ ] Cobertura mantida ou melhorada
-- [ ] Performance não degradou
-- [ ] Comportamento idêntico ao original
-
----
-
-## 5. Documentação
-
-```text
-Acabei de refatorar o seguinte código:
-
-Antes:
-[COLE CÓDIGO ANTIGO]
-
-Depois:
-[COLE CÓDIGO NOVO]
-
-Gere um resumo das mudanças para o PR, explicando:
-- Por que a refatoração foi feita
-- Principais alterações
-- Impacto no comportamento (nenhum, se correto)
-```
-
----
-
-## Estratégias de Refatoração
-
-| Técnica | Quando Usar | Risco |
-|---|---|---|
-| **Renomear** | Nomes confusos | Baixo |
-| **Extrair método** | Métodos longos | Baixo |
-| **Extrair classe** | Classe com muitas responsabilidades | Médio |
-| **Mover método** | Método na classe errada | Médio |
-| **Substituir condicional por polimorfismo** | Switch/if complexos | Alto |
-| **Introduzir padrão de design** | Código duplicado, acoplamento | Alto |
-
----
-
-## Boas Práticas
-
-1. **Sempre tenha testes antes de refatorar**
-2. **Mudanças pequenas e frequentes** - commits atômicos
-3. **Uma refatoração por vez** - não misture com features
-4. **Valide após cada passo** - rode testes frequentemente
-5. **Use IA como assistente** - revise sempre as sugestões