SPELL / Documentação
← Site principal

Bloco Regras

Por que regras são insubstituíveis

Regras de negócio são o ativo mais crítico de qualquer sistema — e o mais difícil de recuperar quando perdido. Ao contrário da estrutura de dados, que a IA pode inferir com razoável acerto ("uma tabela de usuários provavelmente tem email e senha"), as regras de negócio são específicas do seu domínio e não podem ser inventadas.

A IA não inventa regras não declaradas. Se a sua especificação não diz que um médico não pode ter duas consultas no mesmo horário, a IA vai implementar o agendamento sem essa validação. O sistema vai para produção com um bug que não é um bug técnico — é uma ausência de especificação.

O bloco Regras é a forma de tornar explícito o que seria implícito. Cada regra declarada é uma garantia de que o comportamento esperado vai estar no sistema.

Sintaxe básica

Cada regra é declarada com a keyword rule seguida do nome em PascalCase:

Regras {
  rule HorarioDisponivel {
    contexto: Agendamento de consulta médica
    condicao: Médico já tem consulta confirmada no mesmo horário
    acao: Recusar o agendamento com mensagem "Horário indisponível"
    motivo: Política da clínica para evitar conflitos de agenda
  }
}

Campos de uma regra

CampoObrigatórioDescrição
contextoRecomendadoEm que situação esta regra se aplica
condicaoRecomendadoQuando a regra deve ser acionada
acaoRecomendadoO que acontece quando a condição é verdadeira
excecaoNãoCasos em que a regra não se aplica
motivoNãoJustificativa de negócio para a regra existir
tipoNãoClassificação semântica da regra (ver abaixo)

Campo tipo — classificação semântica

O campo tipo classifica a natureza da regra. Isso ajuda a IA a decidir onde e como implementar a verificação:

TipoSignificadoExemplo típico
validacaoVerifica dados antes de persistirFormato de e-mail, senha forte
autorizacaoVerifica se o usuário pode executar a açãoApenas admin pode excluir usuários
rate-limitLimita frequência de açõesMáximo 3 tentativas de login por minuto
negocioRegra do domínio de negócioMédico não pode ter dois horários simultâneos
auditoriaGera registro de auditoria da açãoToda exclusão deve ser registrada com usuário e hora
Regra com tipo declarado
rule LimiteCadastro {
  tipo: rate-limit
  contexto: Cadastro de usuário
  condicao: IP realizou mais de 3 cadastros na última hora
  acao: Recusar com HTTP 429 — "Muitas tentativas. Aguarde."
}

Múltiplas ações com instruções livres

Quando uma regra precisa de mais de uma ação, ou quando o comportamento é complexo demais para caber num campo único, use instruções livres com hífen (-):

rule ContaBloqueadaAposErros {
  tipo: autorizacao
  contexto: Tentativa de login
  condicao: 5 falhas de senha nos últimos 10 minutos
  - Bloquear a conta por 30 minutos
  - Enviar e-mail de alerta de segurança ao usuário
  - Registrar evento de segurança no log de auditoria
  excecao: Contas de admin têm limite de 10 falhas antes do bloqueio
  /// O tempo de bloqueio pode ser configurado via variável de ambiente — não hardcodar 30 minutos
}

Referenciando regras em endpoints

O campo regras dentro de um endpoint vincula as regras que devem ser verificadas naquela operação. A IA sabe que precisa aplicar as validações antes de processar a requisição:

Regras {
  rule SenhaForte {
    tipo: validacao
    contexto: Cadastro de usuário
    condicao: Senha informada tem menos de 8 caracteres
    acao: Recusar o cadastro com mensagem de requisito mínimo
  }

  rule EmailUnico {
    tipo: validacao
    contexto: Cadastro de usuário
    condicao: Email já cadastrado no sistema
    acao: Recusar com mensagem genérica — não revelar que o email existe
    /// Não dizer "email já cadastrado" — evitar enumeração de usuários
  }
}

Endpoints {
  endpoint CadastrarUsuario {
    rota: POST /usuarios
    autenticacao: nao-requerida
    regras: SenhaForte, EmailUnico
    // ...
  }
}

Notas de contexto nas regras

As notas do arquiteto (///) são especialmente valiosas dentro de regras, pois adicionam contexto de negócio que não cabe nos campos estruturados:

Regras {
  /// O sistema opera em mercado regulado (setor financeiro).
  /// Qualquer dado pessoal deve seguir LGPD conforme declarado em Seguranca { }.

  rule AcessoDadosPessoais {
    tipo: autorizacao
    contexto: Consulta de dados pessoais de clientes
    condicao: Usuário não tem perfil de compliance ou admin
    acao: Retornar dados mascarados (CPF com dígitos centrais ocultos)
    /// Mascaramento deve ser consistente em toda a aplicação — não apenas na tela
  }
}