@maestro-ai/cli 1.0.0

package/content/prompts/arquitetura/multi-tenancy.md

@@ -0,0 +1,235 @@
+# 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/content/prompts/database/migrations-zero-downtime.md

@@ -0,0 +1,192 @@
+# 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/content/prompts/database/otimizacao-queries.md

@@ -0,0 +1,296 @@
+# 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`