@semacode/cli 1.5.17 → 1.5.19

package/docs/prompt-base-ia-sema.md

@@ -1,19 +1,25 @@
 # Prompt-Base Oficial para IA Trabalhar com Sema
 
+<!-- sema:i18n -->
+> EN: English first. The canonical operational body below may still be in Portuguese until full translation lands.
+> PT: Português depois, com acentos preservados.
+> ES: Español al final; não traduza comandos, rotas nem sómbolos `.sema` sem contrato.
+
+
 Este arquivo serve como prompt-base oficial para qualquer IA que precise ler, escrever, revisar ou transformar arquivos `.sema`.
 
-O objetivo nao e fazer a IA "improvisar bonito". O objetivo e fazer a IA operar a linguagem com previsibilidade. A Sema nao foi desenhada para ergonomia humana como prioridade; ela foi desenhada para IA.
+O objetivo não é fazer a IA "improvisar bonito". O objetivo e fazer a IA operar a linguagem com previsibilidade. A Sema não foi desenhada para ergonomia humana como prioridade; ela foi desenhada para IA. Humanos escrevem, revisam e aprovam; o consumidor primário e o agente.
 
 ## Prompt-base
 
 Use o texto abaixo como base:
 
 ```text
-Voce esta trabalhando com Sema, um Protocolo de Governanca de Intencao para IA e backend vivo.
+Voce esta trabalhando com Sema, um contrato semantico IA-first para agentes operarem software vivo.
 
-Tecnicamente, a Sema funciona como linguagem de intencao orientada a contrato. Operacionalmente, ela existe para governar semantica acima da stack e reduzir ambiguidade para IA, nao para substituir arquitetura, design ou curadoria humana.
+Tecnicamente, a Sema funciona como linguagem de intencao orientada a contrato. Operacionalmente, ela existe para governar semantica acima da stack e traduzir intencao operacional para IA, nao para substituir arquitetura, design ou aprovacao humana.
 
-Trate a Sema como linguagem de especificacao executavel e protocolo de governanca semantica. Nao invente sintaxe, palavras-chave ou blocos fora da gramatica e dos exemplos oficiais.
+Trate a Sema como contrato semantico executavel e protocolo de governanca IA-first. Nao invente sintaxe, palavras-chave ou blocos fora da gramatica e dos exemplos oficiais.
 
 Fontes de verdade, em ordem:
 1. se o projeto expuser `SEMA_CONTEXT.md`, comece por ele
@@ -31,6 +37,7 @@ Regras de operacao:
 - use o formatador oficial da Sema como fonte unica de estilo
 - use diagnosticos estruturados como contrato de correcao
 - use a IR como fonte de verdade semantica quando houver duvida
+- use `predicadoCanonico` como normalizacao opcional; preserve o `predicado` original
 - nao conclua uma alteracao sem validar e verificar o modulo
 - trate `importar` como bootstrap revisavel, nao como contrato final automatico
 - trate `drift` como medicao de verdade contra codigo vivo
@@ -58,7 +65,7 @@ Se algo nao estiver claro, siga a forma ja usada nos exemplos oficiais. Nao impr
 Se voce quiser um prompt menor para uso frequente:
 
 ```text
-Trabalhe com Sema como DSL semantica orientada a contrato. Nao invente sintaxe. Use os exemplos oficiais e a gramatica como referencia de escrita. Use `ir --json` como fonte de verdade semantica, `diagnosticos --json` como fonte de correcao e `sema formatar` como fonte unica de estilo. Antes de encerrar, rode validacao e verificacao.
+Trabalhe com Sema como contrato semantico IA-first orientado a agente. Nao invente sintaxe. Use os exemplos oficiais e a gramatica como referencia de escrita. Use `ir --json` como fonte de verdade semantica, `diagnosticos --json` como fonte de correcao e `sema formatar` como fonte unica de estilo. Antes de encerrar, rode validacao e verificacao.
 ```
 
 Se voce quiser um prompt ainda mais curto e pronto para colar, use:
@@ -67,9 +74,9 @@ Se voce quiser um prompt ainda mais curto e pronto para colar, use:
 sema prompt-curto caminho/arquivo.sema --curto --para mudanca
 ```
 
-## Variacao para revisao
+## Variacao para revisão
 
-Use esta versao quando a IA for revisar `.sema` em vez de criar:
+Use está versão quando a IA for revisar `.sema` em vez de criar:
 
 ```text
 Revise este modulo Sema como contrato semantico executavel. Procure incoerencias entre input, output, rules, effects, guarantees, state, flow, route e error. Considere a IR e os diagnosticos da CLI como fonte de verdade. Nao critique estilo fora do que o formatador oficial resolveria automaticamente.
@@ -77,15 +84,15 @@ Revise este modulo Sema como contrato semantico executavel. Procure incoerencias
 
 ## Variacao para geracao
 
-Use esta versao quando a IA for escrever modulo novo:
+Use está versão quando a IA for escrever módulo novo:
 
 ```text
 Gere um modulo Sema seguindo a gramatica oficial, os exemplos do projeto e o estilo do formatador canonico. Estruture o modulo como contrato semantico executavel, com blocos explicitos para entrada, saida, regras, efeitos, garantias, erros, estado, fluxo e testes quando fizer sentido. Nao use sintaxe fora do repertorio ja suportado pela linguagem.
 ```
 
-## Variacao para correcao guiada por diagnostico
+## Variacao para correcao guiada por diagnóstico
 
-Use esta versao quando a IA ja tiver erro concreto para corrigir:
+Use está versão quando a IA já tiver erro concreto para corrigir:
 
 ```text
 Corrija este modulo Sema a partir dos diagnosticos estruturados da CLI. Preserve a intencao do contrato e altere apenas o necessario para eliminar as falhas. Depois da correcao, aplique o formatador oficial e revalide.
@@ -101,4 +108,4 @@ Idealmente, acompanhe o prompt com:
 - o resultado de `sema diagnosticos --json`, se houver erro
 - um exemplo oficial parecido
 
-Sem isso, a IA pode ate acertar. Com isso, ela trabalha direito.
+Sem isso, a IA pode até acertar. Com isso, ela trabalha direito.

package/docs/rollback.md

@@ -1,47 +1,49 @@
 # Rollback
 
-Rollback de release publica da Sema deve preservar rastreabilidade. NPM nao deve ser tratado como pasta temporaria: apagar versao publicada e medida extrema e limitada.
+<!-- sema:i18n -->
+> EN: English first. The canonical operational body below may still be in Portuguese until full translation lands.
+> PT: Português depois, com acentos preservados.
+> ES: Español al final; não traduza comandos, rotas nem sómbolos `.sema` sem contrato.
+
+
+Rollback de release pública da Sema deve preservar rastreabilidade. NPM não deve ser tratado como pasta temporaria: apagar versão publicada e medida extrema e limitada.
 
 ## Quando aplicar
 
-- CLI ou MCP publicados quebram instalacao basica.
-- VSIX publicada nao inicia ou quebra o Language Server.
+- CLI publicada quebra instalação básica.
+- VSIX publicada não inicia ou quebra o Language Server.
 - Instaladores baixam asset errado.
-- Release notes ou checksums apontam para artefato invalido.
+- Release notes ou checksums apontam para artefato inválido.
 
 ## Primeira resposta
 
 1. Marque o problema no GitHub Release.
-2. Reponte `latest` no NPM para a ultima versao boa, quando necessario:
+2. Reponte `latest` no NPM para a última versão boa, quando necessário:
 
 ```bash
 npm dist-tag add @semacode/cli@<versao-boa> latest
-npm dist-tag add @semacode/mcp@<versao-boa> latest
 ```
 
-3. Se o problema for so VSIX ou asset de release, substitua o asset no GitHub Release ou publique uma release patch.
-4. Prefira publicar patch corretivo (`1.5.10`, por exemplo) quando o pacote ja saiu para usuarios.
+3. Se o problema for só VSIX ou asset de release, substitua o asset no GitHub Release ou publique uma release patch.
+4. Prefira publicar patch corretivo (`1.5.19`, por exemplo) quando o pacote já saiu para usuários.
 
-## Validacao de rollback
+## Validação de rollback
 
 ```bash
 npm view @semacode/cli dist-tags --json
-npm view @semacode/mcp dist-tags --json
 npm install -g @semacode/cli@latest
-npm install -g @semacode/mcp@latest
 sema --version
-sema-mcp --help
 ```
 
 ## Git
 
-Se o commit foi empurrado mas a release falhou antes de publicar NPM, corrija com novo commit. Evite reescrever `main` depois de push publico.
+Se o commit foi empurrado mas a release falhou antes de publicar NPM, corrija com novo commit. Evite reescrever `main` depois de push público.
 
-Se o tag foi criado errado e ainda nao existe release consumida:
+Se o tag foi criado errado e ainda não existe release consumida:
 
 ```bash
 git tag -d v<versao>
 git push origin :refs/tags/v<versao>
 ```
 
-Use isso somente antes de usuarios consumirem o tag.
+Use isso somente antes de usuários consumirem o tag.

package/docs/sintaxe.md

@@ -1,6 +1,12 @@
 # Sintaxe Canonica
 
-A Sema usa blocos declarativos previsiveis para reduzir ambiguidade no parser, na IR, no drift e no contexto de IA.
+<!-- sema:i18n -->
+> EN: English first. The canonical operational body below may still be in Portuguese until full translation lands.
+> PT: Português depois, com acentos preservados.
+> ES: Español al final; não traduza comandos, rotas nem sómbolos `.sema` sem contrato.
+
+
+A Sema usa blocos declarativos previsiveis para reduzir ambiguidade no parser, na IR, no drift e no contexto de IA. A escrita humana pode ser legivel, mas o alvo principal da sintaxe e gerar contrato consumivel por agente.
 
 ## Regras basicas
 
@@ -19,27 +25,6 @@ A Sema usa blocos declarativos previsiveis para reduzir ambiguidade no parser, n
 - `entity`
 - `enum`
 - `state`
-- `book`
-- `work`
-- `part`
-- `chapter`
-- `section`
-- `scene`
-- `character`
-- `arc`
-- `audience`
-- `thesis`
-- `argument`
-- `claim`
-- `source`
-- `concept`
-- `example`
-- `voice`
-- `style_rule`
-- `lexicon`
-- `motif`
-- `canon`
-- `agent`
 - `task`
 - `flow`
 - `route`
@@ -79,6 +64,24 @@ A Sema usa blocos declarativos previsiveis para reduzir ambiguidade no parser, n
 - `when`
 - `expect`
 
+## Tipos primitivos
+
+Tipos primitivos reconhecidos diretamente:
+
+- `Texto`
+- `Numero`
+- `Inteiro`
+- `Decimal`
+- `Booleano`
+- `Data`
+- `Timestamp`
+- `Objeto`
+- `Id`
+- `Email`
+- `Json`
+
+`Timestamp` e `Objeto` funcionam como aliases primitivos suportados e preservam o texto original na IR.
+
 ## Tipos compostos
 
 ```sema
@@ -98,154 +101,24 @@ Formas suportadas:
 - `T1|T2`
 - `T?`
 
-## Profiles Author e Agents
-
-O profile Author modela obra autoral, nao apenas romance. Ele pode descrever ficcao, nao-ficcao, livro tecnico, ensaio, manual, biografia, pesquisa narrada, curso em formato de livro ou manifesto. A ideia e governar intencao, publico, promessa, voz, estrutura, argumentos, fontes, continuidade e regras de estilo.
-
-Blocos Author suportados:
+## Predicados normalizados
 
-- `book` ou `work`: obra inteira
-- `part`, `chapter`, `section`: estrutura editorial
-- `scene`, `character`, `arc`: narrativa quando a obra tiver ficcao ou relato
-- `audience`, `thesis`, `argument`, `claim`, `source`, `concept`, `example`: nao-ficcao, ensino, pesquisa e argumentacao
-- `voice`, `style_rule`, `lexicon`, `motif`, `canon`: voz, vocabulario, repeticoes, proibicoes e continuidade
+Predicados escritos em contrato preservam o texto original em `predicado`. Quando a CLI reconhece uma forma comum, a expressao estruturada pode expor também `predicadoCanonico`.
 
-`style_rule` aceita subblocos livres como `proibido`, `evitar`, `ecos`, `preferir`, `require` e `tolerancia`. Isso cobre frases cliches, muletas, ecos repetidos e limites de repeticao sem prender a linguagem a um genero literario.
-
-Todo modulo com blocos Author tambem recebe no IR a regra sintetica `regras_gerais_author`. Ela aplica automaticamente o piso editorial geral: mostrar por evidencia, causa e consequencia, cena com dupla funcao, exposicao com atrito, dialogo com subtexto, final sem slogan, morte com peso estrutural, especificidade sensorial, voz distinta e anti-cliche adaptativa. Regras locais da obra podem ser mais fortes, mas nao devem apagar esse piso.
-
-Quando a obra declara um tema sensivel ou factual, como `autismo`, `saude`, `diagnostico`, `neurodiversidade`, `educacao inclusiva`, `juridico` ou `financeiro`, o contrato deixa de ser apenas orientativo. A validacao exige `book/work`, `audience`, `claim`, `source`, `style_rule`, `agent` e um `flow` chamando esse agent. Claims sensiveis precisam declarar `source/fonte/evidencia` e `confidence/confianca`.
+Exemplo:
 
 ```sema
-module livro.tecnico.ia {
-  work protocolo_ia {
-    titulo: "Sistemas para IA"
-    proposito: "ensinar governanca de agentes"
-    tipo: nao_ficcao
-  }
-
-  audience devs {
-    nivel: intermediario
-    promessa: "sair com um protocolo aplicavel"
-  }
-
-  claim contratos_reduzem_adivinhacao {
-    source: pesquisa_interna
-    confidence: media
-  }
-
-  voice didatica {
-    tom: claro
-    ritmo: progressivo
-  }
-
-  style_rule anti_texto_raso {
-    proibido {
-      frase: "de alguma forma"
-      cliche: "o tempo parecia parar"
-    }
-    ecos {
-      palavra: "eco"
-    }
-    tolerancia {
-      max_repeticao_palavra_por_trecho: 2
-    }
-  }
-
-  agent revisor_estilo {
-    role: editor_author
-    goal: cortar_cliche_e_eco
-    tools {
-      ler_contrato
-      analisar_trecho
-    }
-    memory {
-      canon
-      style_rule
-    }
-    policy {
-      nao_reescrever_sem_aprovacao
-      citar_trechos_afetados
-    }
-  }
-
-  flow revisar_secao {
-    trecho: Texto
-    etapa estilo usa revisor_estilo com trecho = trecho
-  }
+rules {
+  email deve_ser email_valido
+  nome deve_ser preenchido
 }
 ```
 
-`agent` e bloco de primeira classe. Um agent precisa declarar ao menos `role`/`goal`, `tools` e `policy`; `memory` gera aviso quando ausente, porque agente sem memoria declarada tende a improvisar contexto.
-
-Exemplo de obra sensivel:
-
-```sema
-module livro.autismo {
-  work guia_autismo {
-    titulo: "Autismo sem reducionismo"
-    proposito: "orientar familias sem substituir avaliacao clinica"
-    tema: autismo
-    sensivel: verdadeiro
-  }
-
-  audience familias_e_educadores {
-    publico: pais_educadores_pessoas_autistas
-    limites: "nao substitui avaliacao clinica"
-  }
-
-  claim autismo_e_espectro {
-    texto: "autismo e um espectro com manifestacoes variadas"
-    source: dsm5_tr
-    confidence: alta
-  }
-
-  source dsm5_tr {
-    tipo: referencia_clinica
-    confianca: alta
-  }
+Na IR, `email_valido` continua existindo como escrito e pode receber uma normalizacao como `valid_email`; `preenchido` pode receber `filled`. Esse campo e opcional e serve a agente/automacao, não muda a sintaxe pública.
 
-  style_rule linguagem_respeitosa {
-    proibido {
-      generalizacao: "todo autista"
-      infantilizacao: "anjinho especial"
-      promessa: "cura garantida"
-    }
-    evitar {
-      frase: "superar o autismo"
-    }
-  }
+## Persistência vendor-first
 
-  agent checador_sensibilidade {
-    role: revisor_sensibilidade
-    goal: checar_fontes_linguagem_e_generalizacoes
-    tools {
-      ler_contrato
-      verificar_claim
-      revisar_trecho
-    }
-    memory {
-      source
-      style_rule
-      audience
-    }
-    policy {
-      nao_diagnosticar
-      nao_prometer_tratamento
-      citar_trechos_afetados
-    }
-  }
-
-  flow revisar_capitulo {
-    trecho: Texto
-    etapa sensibilidade usa checador_sensibilidade com trecho = trecho
-  }
-}
-```
-
-## Persistencia vendor-first
-
-O bloco `database` modela banco e recursos persistidos sem apagar as diferencas entre engines.
+O bloco `database` modela banco e recursos persistidos sem apagar as diferenças entre engines.
 
 Estrutura base:
 
@@ -333,78 +206,13 @@ database principal_redis {
 
 ## Compatibilidade declarada
 
-O IR de persistencia calcula compatibilidade por recurso com quatro estados:
+O IR de persistência calcula compatibilidade por recurso com quatro estados:
 
 - `nativo`
 - `adaptado`
 - `parcial`
 - `invalido`
 
-Isso existe para deixar explicito quando um contrato esta pedindo de um banco algo que ele nao entrega do mesmo jeito.
-
-O mesmo principio vale para runtime de orquestracao. Superficies como `webhook`, `cron`, `worker`, `evento` e `fila` podem ser medidas contra familias como `n8n`, mas o contrato continua canonicamente modelado em Sema, sem rebaixar a linguagem para a sintaxe do adapter alvo.
-
-## Interop e implementacao externa
-
-`use` e `impl` aceitam origens de codigo vivo quando o contrato precisa rastrear runtime real. As origens semanticas suportadas sao:
-
-- `ts`
-- `py`
-- `dart`
-- `lua`
-- `php`
-- `cs`
-- `java`
-- `go`
-- `rust`
-- `cpp`
-
-Exemplo com Lua:
-
-```sema
-module app.runtime {
-  use lua src.runtime
-
-  task processar_snapshot {
-    input {
-      payload: Json required
-    }
-    output {
-      resultado: Json
-    }
-    impl {
-      lua: src.runtime.RuntimeBridge.processSnapshot
-    }
-    guarantees {
-      resultado existe
-    }
-  }
-}
-```
-
-Para Lua, o `drift` resolve funcoes declaradas como `function nome(...)`, `local function nome(...)`, `function Tabela.metodo(...)`, `function Tabela:metodo(...)` e atribuicoes `Tabela.metodo = function(...)`. A forma com `:` e normalizada para ponto no contrato.
-
-Exemplo com PHP:
-
-```sema
-module app.php {
-  use php App.Http.Controllers.UserController
-
-  task criar_usuario {
-    input {
-      payload: Json required
-    }
-    output {
-      resultado: Json
-    }
-    impl {
-      php: App.Http.Controllers.UserController.store
-    }
-    guarantees {
-      resultado existe
-    }
-  }
-}
-```
+Isso existe para deixar explícito quando um contrato está pedindo de um banco algo que ele não entrega do mesmo jeito.
 
-Para PHP, o `drift` resolve namespaces, classes, traits, interfaces, enums, metodos, funcoes, closures atribuidas, rotas Laravel/Slim (`Route::get`, `Route::post`, `$app->get`) e atributos HTTP no estilo Symfony/PHP 8 (`#[Route]`, `#[Get]`, `#[Post]`). `Route::resource` e `Route::apiResource` sao expandidos para acoes REST canonicas.
+O mesmo principio vale para runtime de orquestração. Superfícies como `webhook`, `cron`, `worker`, `evento` e `fila` podem ser medidas contra famílias como `n8n`, mas o contrato continua canonicamente modelado em Sema, sem rebaixar a linguagem para a sintaxe do adapter alvo.

package/exemplos/agendamento.sema

@@ -1,106 +1,105 @@
-module exemplos.agendamento {
-  docs {
-    resumo: "Agendamento de tarefas recorrentes e unicas com controle de execucao."
-  }
-
-  entity Agendamento {
-    fields {
-      id: Id
-      nome: Texto
-      tipo: Texto
-      expressao_cron: Texto
-      payload: Objeto
-      ativo: Booleano
-      ultima_execucao: Timestamp
-      proxima_execucao: Timestamp
-    }
-  }
-
-  entity ExecucaoAgendamento {
-    fields {
-      id: Id
-      agendamento_id: Id
-      status: Texto
-      iniciado_em: Timestamp
-      concluido_em: Timestamp
-      erro: Texto
-    }
-  }
-
-  task criar_agendamento {
-    input {
-      nome: Texto required
-      tipo: Texto required
-      expressao_cron: Texto required
-      payload: Objeto
-    }
-    output {
-      agendamento: Agendamento
-    }
-    rules {
-      nome deve_ser preenchido
-      expressao_cron deve_ser valida
-      tipo deve_ser registrado
-    }
-    effects {
-      persistencia Agendamento
-      evento agendamento_criado criticidade = baixa
-      auditoria criacao_agendamento
-    }
-    guarantees {
-      agendamento existe
-      agendamento.ativo == verdadeiro
-    }
-    error {
-      cron_invalido: "Expressao cron invalida."
-      tipo_nao_registrado: "Tipo de agendamento nao existe."
-      nome_duplicado: "Ja existe agendamento com este nome."
-    }
-    tests {
-      caso "cria agendamento diario" {
-        given { nome: "relatorio_diario"  tipo: "gerar_relatorio"  expressao_cron: "0 8 * * *" }
-        expect { sucesso: verdadeiro }
-      }
-    }
-  }
-
-  task executar_agendamento {
-    input {
-      agendamento_id: Id required
-    }
-    output {
-      execucao_id: Id
-    }
-    rules {
-      agendamento_id deve_ser valido
-      agendamento.ativo == verdadeiro
-    }
-    effects {
-      consulta Agendamento por agendamento_id
-      persistencia ExecucaoAgendamento
-      persistencia Agendamento
-      evento agendamento_executado criticidade = baixa
-      auditoria execucao_agendamento
-    }
-    state ciclo_execucao {
-      transitions {
-        PENDENTE -> EM_EXECUCAO
-        EM_EXECUCAO -> CONCLUIDO
-        EM_EXECUCAO -> FALHOU
-      }
-    }
-    guarantees {
-      execucao_id existe
-    }
-    error {
-      agendamento_inativo: "Agendamento esta desativado."
-      execucao_em_andamento: "Ja existe uma execucao em andamento para este agendamento."
-    }
-    tests {
-      caso "executa agendamento ativo" {
-        given { agendamento_id: "agd_1" }
-        expect { sucesso: verdadeiro }
-      }
-    }
-  }
-}
+module exemplos.agendamento {
+  docs {
+    resumo: "Agendamento de tarefas recorrentes e unicas com controle de execucao."
+  }
+
+  entity Agendamento {
+    fields {
+      id: Id
+      nome: Texto
+      tipo: Texto
+      expressao_cron: Texto
+      payload: Objeto
+      ativo: Booleano
+      ultima_execucao: Timestamp
+      proxima_execucao: Timestamp
+    }
+  }
+
+  entity ExecucaoAgendamento {
+    fields {
+      id: Id
+      agendamento_id: Id
+      status: Texto
+      iniciado_em: Timestamp
+      concluido_em: Timestamp
+      erro: Texto
+    }
+  }
+
+  task criar_agendamento {
+    input {
+      nome: Texto required
+      tipo: Texto required
+      expressao_cron: Texto required
+      payload: Objeto
+    }
+    output {
+      agendamento: Agendamento
+    }
+    rules {
+      nome deve_ser preenchido
+      expressao_cron deve_ser valida
+      tipo deve_ser registrado
+    }
+    effects {
+      persistencia Agendamento
+      evento agendamento_criado criticidade = baixa
+      auditoria criacao_agendamento
+    }
+    guarantees {
+      agendamento existe
+      agendamento.ativo == verdadeiro
+    }
+    error {
+      cron_invalido: "Expressao cron invalida."
+      tipo_nao_registrado: "Tipo de agendamento nao existe."
+      nome_duplicado: "Ja existe agendamento com este nome."
+    }
+    tests {
+      caso "cria agendamento diario" {
+        given { nome: "relatorio_diario"  tipo: "gerar_relatorio"  expressao_cron: "0 8 * * *" }
+        expect { sucesso: verdadeiro }
+      }
+    }
+  }
+
+  task executar_agendamento {
+    input {
+      agendamento_id: Id required
+    }
+    output {
+      execucao_id: Id
+    }
+    rules {
+      agendamento_id deve_ser valido
+    }
+    effects {
+      consulta Agendamento por agendamento_id
+      persistencia ExecucaoAgendamento
+      persistencia Agendamento
+      evento agendamento_executado criticidade = baixa
+      auditoria execucao_agendamento
+    }
+    state ciclo_execucao {
+      transitions {
+        PENDENTE -> EM_EXECUCAO
+        EM_EXECUCAO -> CONCLUIDO
+        EM_EXECUCAO -> FALHOU
+      }
+    }
+    guarantees {
+      execucao_id existe
+    }
+    error {
+      agendamento_inativo: "Agendamento esta desativado."
+      execucao_em_andamento: "Ja existe uma execucao em andamento para este agendamento."
+    }
+    tests {
+      caso "executa agendamento ativo" {
+        given { agendamento_id: "agd_1" }
+        expect { sucesso: verdadeiro }
+      }
+    }
+  }
+}