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

@maestro-ai/mcp-server 1.0.0 → 1.0.1

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 (440) hide show

package/dist/content/content/prompts/arquitetura/modelo-dominio.md DELETED Viewed

@@ -1,207 +0,0 @@
-# Prompt: Modelo de Domínio
-> **Quando usar**: Início do projeto, após refinar requisitos
-> **Especialista**: [Engenharia de Requisitos](../../02-especialistas/Especialista%20em%20Engenharia%20de%20Requisitos%20com%20IA.md) ou [Arquitetura de Software](../../02-especialistas/Especialista%20em%20Arquitetura%20de%20Software.md)
-> **Nível**: Simples a Médio
----
-## Fluxo de Contexto
-Antes de usar este prompt, tenha em mãos:
-- `docs/CONTEXTO.md` - Entendimento atual do projeto
-- `docs/02-requisitos/requisitos.md` - Requisitos funcionais
-Após gerar, salve o resultado em:
-- `docs/04-modelo/modelo-dominio.md`
----
-## Prompt Completo
-```text
-Atue como analista de domínio especializado em modelagem de dados.
-## Contexto do Projeto
-[COLE O CONTEÚDO DE docs/CONTEXTO.md]
-## Requisitos
-[COLE REQUISITOS DE docs/02-requisitos/requisitos.md]
----
-## Sua Missão
-Proponha um modelo de domínio inicial completo:
-### 1. Entidades Principais
-Para cada entidade:
-- Nome da entidade
-- Descrição (1 frase)
-- Atributos com tipos (use tipos genéricos: string, int, decimal, datetime, boolean, UUID)
-- Marque campos obrigatórios vs opcionais
-- Indique campos únicos (unique)
-### 2. Value Objects
-Identifique conceitos que são melhor representados como Value Objects:
-- Nome
-- Atributos
-- Regras de validação
-### 3. Relacionamentos
-- Cardinalidade (1:1, 1:N, N:N)
-- Direção da navegação
-- Cascade (o que acontece ao deletar)
-### 4. Diagrama ER
-Gere um diagrama Mermaid do modelo.
-### 5. Dúvidas Abertas
-Liste perguntas que ainda precisam ser respondidas pelo cliente.
-### 6. Considerações Técnicas
-- Índices que serão necessários
-- Campos que podem crescer muito (text, blob)
-- Dados sensíveis que precisam de criptografia
-```
----
-## Exemplo de Uso
-```text
-Atue como analista de domínio especializado em modelagem de dados.
-## Contexto do Projeto
-Sistema de agendamento online para salões de beleza.
-## Requisitos
-- RF-001: Cliente pode se cadastrar com nome, telefone e email
-- RF-002: Salão pode cadastrar serviços com nome, duração e preço
-- RF-003: Cliente pode agendar um serviço para uma data/hora
-- RF-004: Sistema deve enviar confirmação por WhatsApp
-- RF-005: Cliente pode cancelar até 2h antes
-- RF-006: Salão pode ver relatório de agendamentos
-```
----
-## Resposta Esperada
-### 1. Entidades
-**Cliente**
-| Atributo | Tipo | Obrigatório | Único | Notas |
-|----------|------|-------------|-------|-------|
-| id | UUID | ✓ | ✓ | PK |
-| nome | string(100) | ✓ | | |
-| telefone | string(20) | ✓ | ✓ | WhatsApp |
-| email | string(255) | | ✓ | |
-| criadoEm | datetime | ✓ | | default: now |
-**Servico**
-| Atributo | Tipo | Obrigatório | Único | Notas |
-|----------|------|-------------|-------|-------|
-| id | UUID | ✓ | ✓ | PK |
-| nome | string(100) | ✓ | | |
-| duracao | int | ✓ | | minutos |
-| preco | decimal(10,2) | ✓ | | |
-| ativo | boolean | ✓ | | default: true |
-**Agendamento**
-| Atributo | Tipo | Obrigatório | Único | Notas |
-|----------|------|-------------|-------|-------|
-| id | UUID | ✓ | ✓ | PK |
-| clienteId | UUID | ✓ | | FK → Cliente |
-| servicoId | UUID | ✓ | | FK → Servico |
-| dataHora | datetime | ✓ | | |
-| status | enum | ✓ | | pendente, confirmado, cancelado, concluido |
-| criadoEm | datetime | ✓ | | default: now |
-### 2. Value Objects
-**Telefone**
-- numero: string
-- ddi: string (default: +55)
-- Validação: formato válido de WhatsApp
-**StatusAgendamento**
-- Enum: PENDENTE, CONFIRMADO, CANCELADO, CONCLUIDO
-- Transições válidas definidas
-### 3. Relacionamentos
-```
-Cliente 1 ──── N Agendamento
-Servico 1 ──── N Agendamento
-```
-- Cliente → Agendamento: Cascade soft delete
-- Servico → Agendamento: Não permite deletar serviço com agendamentos futuros
-### 4. Diagrama ER
-```mermaid
-erDiagram
-    Cliente ||--o{ Agendamento : "faz"
-    Servico ||--o{ Agendamento : "é agendado"
-    Cliente {
-        UUID id PK
-        string nome
-        string telefone UK
-        string email UK
-        datetime criadoEm
-    }
-    Servico {
-        UUID id PK
-        string nome
-        int duracao
-        decimal preco
-        boolean ativo
-    }
-    Agendamento {
-        UUID id PK
-        UUID clienteId FK
-        UUID servicoId FK
-        datetime dataHora
-        enum status
-        datetime criadoEm
-    }
-```
-### 5. Dúvidas
-- [ ] Um agendamento pode ter múltiplos serviços?
-- [ ] Há profissionais diferentes por serviço?
-- [ ] Cliente pode ter mais de um telefone?
-- [ ] Qual a política de reagendamento?
-### 6. Considerações Técnicas
-**Índices necessários:**
-- `agendamento.dataHora` - Consultas por período
-- `agendamento.status` - Filtros por status
-- `agendamento(servicoId, dataHora)` - Verificar conflitos
-**Dados sensíveis:**
-- `cliente.telefone` - Considerar mascarar em logs
-- `cliente.email` - Verificar LGPD
----
-## Checklist Pós-Geração
-- [ ] Todas as entidades têm PK definida
-- [ ] Relacionamentos têm cardinalidade clara
-- [ ] Campos obrigatórios vs opcionais definidos
-- [ ] Diagrama ER gerado em Mermaid
-- [ ] Dúvidas listadas para validar com cliente
-- [ ] Índices sugeridos para queries principais
-- [ ] Salvar em `docs/04-modelo/modelo-dominio.md`

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)