1 Synesis: Ideias

Ideias: Propostas de especificação de Extensões da Linguagem

1.1 Introdução às Extensões

Esta especificação detalha os novos recursos planejados para a versão 1.2 da linguagem Synesis. O foco desta atualização é evoluir a linguagem de um sistema de anotação linear para um motor de inferência qualitativa e gestão de conhecimento (Zettelkasten), além de introduzir suporte nativo para loci canônicos (textos sagrados).

1.2 Anotação Canônica (Bíblica/Exegética)

Sistema de endereçamento especializado para textos sagrados que utilizam o padrão Locus (Livro, Capítulo, Versículo). Para manter a integridade da gramática, o endereçamento canônico é implementado no Synesis através de um tipo de campo específico (TYPE PERICOPE), mantendo intacta a estrutura padrão de blocos analíticos.

1.2.1 Tipo de Campo PERICOPE

Não há substituição de blocos. O bloco SOURCE continua sendo utilizado para referenciar a obra bibliográfica (a Tradução ou o Manuscrito específico via BibTeX). A unidade analítica (ITEM) recebe um campo tipado como PERICOPE para identificar a passagem exata.

Sintaxe no arquivo .syn:

SOURCE @ara1993
    translation_type: Formal equivalence
END SOURCE

# O bloco ITEM referencia a tradução e especifica o locus no campo
ITEM @ara1993
    passage: ROM 8:28-30, 32a
    quote: "Sabemos que todas as coisas cooperam para o bem..."
    code: Providência
END ITEM

1.2.2 Regras de Endereçamento (Parsing)

O parser aplica regras estritas para a identificação dos livros, mas oferece flexibilidade ergonômica na pontuação dos versículos:

  1. Código USX (Estrito): Exigência de exatamente 3 letras maiúsculas para o livro (ex: MAT, GEN, ROM). Nomes por extenso não são permitidos pelo compilador para evitar ambiguidades.
  2. Separador de Capítulo (Flexível): O compilador aceita nativamente tanto dois-pontos (:) quanto ponto (.) para separar capítulo e versículo (ex: ROM 8:1 ou ROM 8.1). A árvore sintática (AST) normaliza essa variação automaticamente.
  3. Versículos e Subdivisões: Uso de hífen - para intervalos e vírgula , para listas. O parser suporta letras minúsculas anexadas aos números para subdivisões exegéticas (ex: 6a, 6b).

1.2.3 Exemplo de Template para Exegese

No arquivo .synt, o campo deve ser declarado com o tipo PERICOPE e escopo ITEM.

TEMPLATE biblical_exegesis

ITEM FIELDS
    REQUIRED passage, quote
    OPTIONAL code
END ITEM FIELDS

FIELD passage TYPE PERICOPE
    SCOPE ITEM
    DESCRIPTION Endereçamento Locus canônico (Livro Cap:Versos)
END FIELD

FIELD quote TYPE QUOTATION
    SCOPE ITEM
    DESCRIPTION Excerto textual extraído da fonte bibliográfica
END FIELD

1.2.3.1 Apêndice A: Notas de Implementação (Lark Grammar)

Snippet da gramática demonstrando o processamento do valor do campo PERICOPE nas regras da linguagem:

// A regra rigorosa que processa o valor do campo Locus
pericope_value: usx_code WS INT separator verse_list

// Códigos USX (3 letras maiúsculas estritas)
usx_code: UCASE_LETTER~3

// O separador mágico (aceita os dois formatos acadêmicos comuns)
separator: ":" | "."

// Lista de versículos com suporte a vírgulas e espaços opcionais
verse_list: verse_node ("," WS? verse_node)*

// Um nó pode ser um versículo isolado ou um intervalo
verse_node: verse_single | verse_single "-" verse_single

// O versículo: Um número seguido de uma letra minúscula opcional (ex: 6a)
verse_single: INT /[a-z]?/

Aqui está a proposta de apêndice formatada para o seu Guia de Referência, utilizando ilustrações conceituais para consolidar o entendimento das duas arquiteturas.

1.3 Conversores de anotações Bíblicas Logos Software para Synesis

Há um conversor de anotações do formato proprietário Logos para textos Markdown:

A partir daí, a conversão de anotações em Markdown para Synesis é muito simples.

1.4 Apêndice B: Estratégias para Exegese Comparativa

A linguagem Synesis oferece flexibilidade estrutural para pesquisadores que necessitam comparar diferentes manuscritos ou traduções de uma mesma passagem. Como a invariante estrutural da linguagem estabelece que um bloco ITEM pertence a exatamente um SOURCE, existem duas abordagens arquiteturais recomendadas, dependendo de como os dados serão analisados nas etapas seguintes da pesquisa.

1.4.1 Abordagem 1: O “Join” Relacional (Múltiplos ITEMs)

Neste modelo, prioriza-se o rigor bibliográfico absoluto. Cada texto base (ex: Grego original e Tradução em Português) é tratado como uma obra separada no bloco SOURCE. A correlação entre os diferentes blocos de anotação ocorre organicamente porque o campo locus atua como uma chave universal de relacionamento (Foreign Key).

Sintaxe na Anotação (.syn):

SOURCE @na28
    language: "grc"
END SOURCE

ITEM @na28
    passage: ROM 8:1
    quote: "Οὐδὲν ἄρα νῦν κατάκριμα..."
END ITEM

SOURCE @ara1993
    language: "pt-BR"
END SOURCE

ITEM @ara1993
    passage: ROM 8:1
    quote: "Agora, pois, já nenhuma condenação há..."
END ITEM

Vantagem Analítica: Esta abordagem gera tabelas planas altamente normalizadas. É a arquitetura ideal para fluxos de trabalho de Data Science, pois permite agrupar as traduções dinamicamente via scripts em Python (Pandas) ou realizar consultas complexas de travessia em bancos de grafos como o Neo4j, conectando os nós através da propriedade locus.

1.4.2 Abordagem 2: A Comparação Direta via BUNDLE (Item Único)

Se o foco epistemológico é a justaposição visual e hermenêutica direta, e o texto-base da pesquisa é uma Bíblia Interlinear ou Paralela, utiliza-se o modificador BUNDLE. O BUNDLE garante a correspondência posicional obrigatória entre a versão da tradução e o excerto analisado, formando uma unidade analítica indivisível.

Sintaxe no Template (.synt):

ITEM FIELDS
    REQUIRED passage
    REQUIRED BUNDLE version, quote  # Campos atrelados posicionalmente
END ITEM FIELDS

FIELD passage TYPE PERICOPE
    SCOPE ITEM
    DESCRIPTION Endereçamento canônico
END FIELD

FIELD version TYPE ENUMERATED
    SCOPE ITEM
    DESCRIPTION Sigla da tradução bibliográfica
    VALUES
        NA28: Nestle-Aland (Grego)
        ARA: Almeida Rev. Atualizada
        NVI: Nova Versão Internacional
    END VALUES
END FIELD

FIELD quote TYPE QUOTATION
    SCOPE ITEM
    DESCRIPTION Excerto correspondente à versão
END FIELD

Sintaxe na Anotação (.syn):

ITEM @biblia_interlinear2025
    passage: ROM 8:1
    note: Análise cruzada das escolhas de tradução.

    # -- Par 1 do Bundle --
    version: NA28
    quote: "Οὐδὲν ἄρα νῦν κατάκριμα..."
    
    # -- Par 2 do Bundle --
    version: ARA
    quote: "Agora, pois, já nenhuma condenação há..."
END ITEM

Vantagem Analítica: Mantém a comparação coesa e de fácil leitura humana dentro do mesmo bloco de anotação. Além disso, o compilador protegerá a integridade dos dados, emitindo um erro de compilação caso o pesquisador anote uma versão sem o respectivo excerto textual, ou vice-versa. O uso do tipo ENUMERATED também assegura que apenas as versões declaradas no VALUES sejam aceitas pelo compilador.

1.5 Apêndice C

Aqui está o mapa exato de quão cirúrgica e mínima será essa intervenção:

1.5.1 1. No Compilador (Core Synesis)

1.5.1.1 O que muda (Mínimo)

Template Parser: Adicionar a palavra PERICOPE na lista de palavras reservadas de tipos de dados válidos, ao lado de TEXT, QUOTATION, MEMO, CHAIN, etc..

  • Lark Grammar: Criar a regra pericope_value para capturar a string USX INT:INT.
  • Transformer (Python): Escrever a funçãozinha de 10 linhas que desmembra a string em dicionário (book, chapter, verses).

1.5.1.2 O que NÃO muda

Árvore Estrutural: A lógica de que blocos ITEM pertencem a blocos SOURCE permanece intacta.

Validador de BibTeX: O sistema continuará exigindo e validando referências @bibref exatamente como já faz hoje.

Motor de Validação do BUNDLE: A complexa verificação de arrays, correspondência posicional e obrigatoriedade não precisará de uma única linha nova de código.

Exportadores: Os geradores de JSON e tabelas planas em CSV vão simplesmente iterar sobre a nova chave PERICOPE do dicionário, como fariam com qualquer campo dinâmico definido no template .synt.

1.5.1.3 No LSP (Extensão Synesis-Explorer para VSCode)

A atualização na extensão também será pontual e isolada.

O que muda:

  • Highlighter (.tmLanguage.json): Adicionar um regex simples para capturar o padrão canônico (ex: \b[A-Z]{3}\s\d+[:.]\d+[\d\-,a-z\s]*\b) e aplicar uma cor de destaque bacana (ex: entity.name.class).
  • Snippets: Criar um atalho rápido para autocompletar o bloco ITEM já com o campo locus.
  • Code Actions (Opcional/Futuro): O script para transformar “Romanos 8, 1 a 3” em ROM 8:1-3 fica totalmente isolado na camada de interface do usuário, como uma sugestão de Quick Fix (Lâmpada amarela do VSCode), sem nunca tocar no motor do compilador.

1.6 Anotação Jurídica e Normativa (Extensão de Domínio)

O ecossistema Synesis é agnóstico em relação ao domínio de pesquisa. A arquitetura baseada em tipos de campo configuráveis permite a modelagem nativa da alta complexidade de textos jurídicos (legislação e jurisprudência) sem necessidade de alteração na gramática central ou na estrutura de blocos SOURCE e ITEM da linguagem .

1.6.1 1. Endereçamento Topográfico (Legislação)

Textos normativos exigem um sistema de endereçamento estruturado e não-linear, fatiado em normativas menores. Semelhante à anotação canônica, isso é implementado via um tipo de campo específico no template.

  • Tipo de Campo Sugerido: TYPE LEGAL_LOCUS
  • Comportamento do Parser: Captura e estrutura a topografia da lei (Lei, Artigo, Parágrafo, Inciso, Alínea). Exemplo de sintaxe alvo: CF/88 Art. 5, inc. X.

1.6.2 2. Ontologia Jurisprudencial

Decisões judiciais (acórdãos e sentenças) possuem categorias ontológicas estritas. A classificação do texto anotado é garantida pelo compilador através da tipagem ENUMERATED , restringindo a anotação a partes formais da sentença.

  • Categorias Comuns: Ratio Decidendi (tese principal), Obiter Dictum (comentário marginal) e Ementa (resumo oficial).

1.6.3 3. Redes de Precedentes (CHAIN)

O mapeamento topológico de como decisões judiciais se relacionam ao longo do tempo (ex: tribunais superiores derrubando sentenças de instâncias inferiores) é resolvido nativamente utilizando as cadeias semânticas qualificadas (CHAIN) do Synesis .

1.6.4 Exemplo de Implementação (Template e Anotação)

Definição no arquivo de template (.synt):

TEMPLATE legal_analysis

ITEM FIELDS
    REQUIRED locus, quote
    OPTIONAL legal_concept, chain
END ITEM FIELDS

FIELD locus TYPE LEGAL_LOCUS
    SCOPE ITEM
    DESCRIPTION Endereço topográfico normativo ou jurisprudencial
END FIELD

FIELD legal_concept TYPE ENUMERATED
    SCOPE ITEM
    DESCRIPTION Classificação estrutural da decisão judicial
    VALUES
        RATIO: Ratio Decidendi (Tese principal)
        OBITER: Obiter Dictum (Argumento marginal)
        EMENTA: Resumo oficial
    END VALUES
END FIELD

FIELD chain TYPE CHAIN
    SCOPE ITEM
    ARITY >= 2
    RELATIONS
        OVERRULES: Tribunal superior derruba a tese anterior
        CITES_PRECEDENT: Decisão baseia-se em caso passado
        DISTINGUISHES: Distinção do caso atual em relação à regra geral
    END RELATIONS
END FIELD

Aplicação no arquivo de anotação (.syn):

SOURCE @stj_peticao_1234
    access_date: 2026-02-17
END SOURCE

ITEM @stj_peticao_1234
    locus: CF/88 Art. 5, inc. X
    legal_concept: RATIO
    quote: "são invioláveis a intimidade, a vida privada, a honra e a imagem..."
    
    # Mapeamento do grafo de precedentes entre obras bibliográficas (Acórdãos)
    chain: @stj_peticao_1234 -> OVERRULES -> @tj_decisao_999
END ITEM

Vantagem Arquitetural: Ao exportar este projeto para formatos relacionais (CSV) ou bases de grafos (JSON processado via Neo4j) , o pesquisador obtém automaticamente o rizoma completo da jurisprudência e da topologia legal. Essa rastreabilidade absoluta é alcançada apenas recombinando os modificadores e escopos nativos da versão 1.1 da linguagem .

1.7 Gestão de Conhecimento (Zettelkasten)

Introduz a capacidade de criar “Notas Permanentes” que sintetizam conhecimento. Para manter a estabilidade do parser e as invariantes da linguagem, o Zettelkasten é implementado não como um novo bloco, mas através de campos especializados dentro da unidade analítica padrão (ITEM).

1.7.1 O Zettelkasten como SOURCE

Como a linguagem exige que cada ITEM pertença a exatamente um SOURCE referenciado no arquivo .bib, recomenda-se a criação de uma entrada BibTeX representando o próprio repositório de notas do autor (ex: @zettel_vault).

Sintaxe na Anotação (.syn):

# A "Fonte" é o próprio cérebro/repositório do pesquisador
SOURCE @zettel_vault
    access_date: 2026-02-17
END SOURCE

# O ITEM atua como a Nota Permanente (Zettel)
ITEM @zettel_vault
    zettel_id: 2026011401
    title: "O Princípio da Atomicidade"
    body: "Uma DSL deve forçar a quebra de conceitos..."
    
    # Conexões explícitas (Rizoma)
    links: 2026011205, 2025123001
    
    # Metadados e Rastreabilidade
    topic: DSL_Design
    origin: @turing1936
END ITEM

1.7.2 Campos Exclusivos (ZETTEL FIELDS)

No arquivo de template .synt, novos tipos de dados (TYPE) são introduzidos para suportar a topologia de grafos típica de um Zettelkasten, permitindo validação cruzada durante a Etapa de Vinculação (Etapa 8).

  • ZETTEL_ID: Identificador único da nota (geralmente um timestamp numérico). O compilador garante que não existam IDs duplicados no projeto.
  • ZETTEL_LINK: Cria arestas direcionais entre nós ZETTEL. O compilador verifica se os IDs referenciados existem.
  • BIB_REF: Permite referenciar uma fonte externa diretamente no campo, criando uma aresta de citação da nota permanente para um autor externo.

Exemplo de Template (.synt):

TEMPLATE zettel_knowledge_base

ITEM FIELDS
    REQUIRED zettel_id, title, body
    OPTIONAL links, topic, origin
END ITEM FIELDS

FIELD zettel_id TYPE ZETTEL_ID
    SCOPE ITEM
    DESCRIPTION Identificador cronológico único do Zettel
END FIELD

FIELD links TYPE ZETTEL_LINK
    SCOPE ITEM
    DESCRIPTION Lista de conexões para outros Zettels (IDs separados por vírgula)
END FIELD

FIELD origin TYPE BIB_REF
    SCOPE ITEM
    DESCRIPTION Referência bibliográfica que inspirou a nota permanente
END FIELD

1.7.2.1 Apêndice A: Notas de Implementação (Lark Grammar)

Snippet da gramática demonstrando como o Lark processa os novos tipos de valores como propriedades de campo (field_value), sem alterar a estrutura de blocos:

// A regra de campo genérica absorve os novos tipos
field_value: text_value 
           | chain_value 
           | zettel_id_value
           | zettel_link_value
           | bib_ref_value

// Regras rigorosas para os valores Zettel
// ID deve ser uma string estritamente numérica (ex: YYYYMMDDHH)
zettel_id_value: INT 

// Lista de IDs separados por vírgula (similar à regra de versículos)
zettel_link_value: INT ("," WS? INT)*

// O parser valida o formato de citação com '@'
bib_ref_value: "@" LCASE_LETTER+ DIGIT+

1.7.3 O Impacto na Exportação (Neo4j)

A beleza de usar zettel_link e bib_ref como tipos de campo no ITEM é que a sua infraestrutura de grafos vai herdar isso perfeitamente.

Quando o compilador exportar o JSON, você terá arrays limpos de links contendo os timestamps e o origin contendo a chave BibTeX. Um script simples em Python usando a biblioteca do Neo4j poderá ler esse JSON gerado pela Synesis e plotar o seu rizoma inteiro de notas permanentes com duas ou três linhas de Cypher Query!

1.8 Configuração de Artefatos de Saída (RENDER)

O comando RENDER permite declarar explicitamente, dentro do arquivo de projeto, quais formatos de arquivo devem ser gerados e onde devem ser salvos. Isso garante a reprodutibilidade da compilação sem depender de parâmetros de linha de comando.

1.8.1 Sintaxe

RENDER AS [JSON | CSV | EXCEL] INTO "path/to/filename"

1.8.1.1 Semântica

  • RENDER: Verbo de comando que inicia a definição de um alvo de compilação. Indica a criação de uma representação estruturada (artefato) a partir dos dados interpretados.

  • AS: Cláusula que especifica o formato de serialização.

  • JSON: Gera a árvore de sintaxe abstrata completa com metadados de rastreabilidade.

  • CSV: Gera tabelas relacionais planas (separadas por tipo de bloco).

  • EXCEL: Gera um arquivo .xlsx com abas correspondentes às tabelas CSV.

  • INTO: Cláusula que define o caminho de destino.

  • Deve ser uma string entre aspas duplas.

  • Recomenda-se o uso de caminhos relativos à raiz do projeto para garantir portabilidade entre diferentes máquinas.

  • Se o diretório de destino não existir, o compilador tentará criá-lo.

1.8.1.2 Exemplo no Contexto (.synp)

PROJECT "Estudo Fenomenológico 2026"

TEMPLATE "templates/research_v1.synt"
INCLUDE BIBLIOGRAPHY "data/references.bib"
INCLUDE ANNOTATIONS "data/interviews/*.syn"
INCLUDE ONTOLOGY "ontology/main.syno"

# Configuração Declarativa de Saída
# Gera múltiplos formatos simultaneamente em diretórios organizados

RENDER AS JSON  INTO "dist/full_data.json"
RENDER AS EXCEL INTO "reports/human_readable/matrix.xlsx"
RENDER AS CSV   INTO "reports/raw_data/export.csv"

END

1.8.1.3 Regras de Validação

  1. Multiplicidade: É permitido declarar múltiplos comandos RENDER no mesmo projeto. O compilador processará todos sequencialmente.
  2. Permissão de Escrita: O compilador deve ter permissão de escrita no diretório alvo. Se o arquivo de destino estiver bloqueado (ex: aberto no Excel), a compilação falhará com erro de E/S.
  3. Caminhos Absolutos: O uso de caminhos absolutos (ex: C:/Users/...) emitirá um Warning, pois quebra a portabilidade do projeto.

1.9 Análise Semântica Avançada

O compilador passa a atuar como assistente metodológico, não apenas validador sintático.

1.9.1 Detecção de Redundância Ontológica (Fuzzy Matching)

O compilador analisará a ontologia em busca de conceitos com grafia similar (Lexical Similarity), prevenindo a fragmentação do grafo de conhecimento.

  • Algoritmo: Distância de Levenshtein / Jaro-Winkler.
  • Comportamento: Warning (Aviso) durante a compilação.
  • Exemplo de Detecção: InteracaoSocial vs Interacao_Social.

1.9.2 Validação de Ciclos Hierárquicos

Impede a criação de loops lógicos nas definições taxonômicas. * Regra: Um conceito não pode ser ancestral de si mesmo. * Erro Fatal: A compilação é abortada se um ciclo for detectado (ex: A > B > C > A).

1.9.3 Eliminação de Código Morto (Ghost Concepts)

Identifica conceitos definidos na ontologia que nunca foram aplicados em nenhum ITEM ou ZETTEL. * Comportamento: Warning (Relatório de limpeza de Codebook).

1.10 Novos Comandos Estruturais

1.10.1 TAXONOMY (Hierarquia Rígida)

Substitui o uso solto de TOPIC para definições estritas de relacionamento “é-um” (is-a). Permite herança de propriedades.

Sintaxe:

TAXONOMY
    Emoções
        > Negativas
            > Raiva
            > Medo
        > Positivas
            > Alegria
END TAXONOMY

1.10.2 CONSTRAINT (Regras de Negócio)

Define invariantes lógicas para garantir a consistência metodológica das anotações.

Sintaxe:

CONSTRAINT
    # Exclusão mútua: Um item não pode ter ambos os códigos simultaneamente
    FORBID Code "Sentimento: Positivo" WITH Code "Risco: Crítico"

    # Dependência lógica: O código B exige a presença do código A
    REQUIRE Code "Solução" IF Code "Problema" PRESENT
END CONSTRAINT

1.10.3 CROSSREF (Rede de Citações)

Formaliza as relações retóricas entre fontes bibliográficas (Source-to-Source), independente de anotações internas.

Sintaxe:

CROSSREF
    @smith2019 -> REFUTES -> @doe2018
    @jones2020 -> EXTENDS -> @smith2019
END CROSSREF

1.11 Visualização Imediata

O output JSON é útil para processamento, mas humanos precisam ver o grafo.

Ideia: Criar um comando synesis serve que sobe um servidor local simples mostrando o grafo de conexões (usando D3.js ou Cytoscape) gerado a partir do JSON exportado.

1.12 Integração com Data Science

O suporte a exportação CSV/Excel é bom, mas uma integração direta com Pandas seria matadora.

Exemplo: Uma biblioteca Python import synesis que permite carregar o projeto diretamente em um DataFrame sem passar pelo terminal, facilitando o uso em Jupyter Notebooks.

1.13 Possível Workflow

Correto. A premissa é exata: o Core do Compilador (Parser + Análise Semântica) atua como a única fonte da verdade. Tanto a exportação de arquivos, quanto a biblioteca Python (synesis.load), quanto o servidor LSP consomem a mesma Árvore Sintática Abstrata (AST) e a mesma Tabela de Símbolos.

Aqui está o workflow objetivo para essa implementação, focando na arquitetura “Compiler as a Library” (Compilador como Biblioteca):

1.13.1 Passo 1: Desacoplamento de I/O (Entrada/Saída)

O primeiro passo é garantir que o compilador não “saiba” que está escrevendo arquivos.

  • Ação: Separar as funções de exportação. Hoje, provável que exista uma função export_csv(ast, filepath).
  • Refatoração: Dividir em duas:
  1. transform_to_tabular_data(ast): Recebe a AST e retorna listas de dicionários/objetos em memória (sem tocar no disco).
  2. write_csv(data, filepath): Recebe os dados e apenas grava o arquivo.

1.13.2 Passo 2: Exposição da API Pública do Core

O módulo principal do Synesis deve expor o acesso programático à compilação.

  • Ação: Tornar a função de orquestração acessível externamente.
  • Definição: Criar/Ajustar um método (ex: Synesis.compile_source()) que aceita uma string ou caminho de arquivo e retorna o objeto Project (o resultado da validação semântica contendo todas as estruturas ligadas).

1.13.3 Passo 3: Criação do Adaptador Python (Data Science)

Este é o consumidor que você sugeriu (synesis.load).

  • Dependência: Definir Pandas como dependência opcional.
  • Fluxo:
  1. Chama a API do Passo 2 para obter o objeto Project em memória.
  2. Chama a função de transformação do Passo 1 (transform_to_tabular_data).
  3. Instancia DataFrames do Pandas usando esses dados.
  4. Aplica tipagem (converte strings para datetime objects, categorias, etc.) baseada nos tipos da AST.

1.13.4 Passo 4: Adaptação para o LSP (Editor Intelligence)

O LSP consome a mesma AST, mas precisa de dados diferentes (localização em vez de valor).

  • Ação: Garantir que os nós da AST (Item, Source, Field) preservem metadados de origem (linha, coluna, arquivo).
  • Fluxo:
  1. O LSP envia o texto do arquivo atual (mesmo incompleto).
  2. O Core tenta fazer o parse (com tolerância a erros).
  3. O Core retorna a Tabela de Símbolos (lista de ontologias e definições disponíveis).
  4. O LSP usa essa tabela para fornecer Autocomplete e Go to Definition.

1.13.5 Passo 5: CLI como “Cliente Magro”

O comando synesis compile no terminal passa a ser apenas mais um cliente, igual ao Python ou ao LSP.

  • Ação: O CLI apenas coleta argumentos, chama a API do Passo 2 e usa as funções de escrita de arquivo (write_csv, write_json) definidas no Passo 1.

1.13.6 Resumo do Fluxo de Dados

  1. Entrada: Arquivos .syn / .synt
  2. Motor Central (Synesis Core): Gera AST + Validação Semântica.
  3. Distribuição:
  • via CLI -> Escreve no Disco (JSON/CSV).
  • via Python SDK -> Entrega Objetos/DataFrames em Memória.
  • via LSP -> Entrega Metadados de Posição e Erros para o Editor.