Documentação / Referência
Arquitetura
Como o Yuli é construído: um motor nativo em Rust, uma interface Electron com TypeScript e React, e o modelo de linguagem como a camada que raciocina.
O Yuli separa com clareza quem faz o trabalho pesado, quem desenha a tela e quem raciocina.
| Camada | Tecnologia | Responsabilidade |
|---|---|---|
| Motor nativo | Rust | Indexação e análise semântica, Git, processos, depuração, banco de dados, segurança, qualidade e orquestração do agente. |
| Interface | Electron, TypeScript e React | Apenas desenha: editor, painéis, diagramas e pré-visualizações. |
| Modelo de linguagem | O provedor ou agente que você escolher | Raciocina: planeja, decide e opera os serviços do IDE por meio de ferramentas controladas. |
O aplicativo roda em Windows, macOS e Linux, em 64 bits de ponta a ponta.
Como se comunicam
Interface (Electron + React)
│ IPC por stdin/stdout
▼
Motor (agent-engine, Rust) ──▶ Git, build, depurador, banco de dados, índice
│
├──▶ Provedor de IA (Modo Platform)
│
└──◀ yuli-mcp ◀── stdio ── Claude Code, Kiro, Codex, Antigravity
(TCP 127.0.0.1 + token)
- A interface inicia o motor como um processo e se comunica com ele por stdin/stdout.
- A interface nunca toca o disco, o Git nem a rede do agente por conta própria: tudo passa pelos controladores do motor.
- Os agentes externos se conectam com
yuli-mcp, que fala com o motor por um socket de loopback com token. Veja O Yuli como servidor MCP.
Os componentes do motor
| Componente | O que faz |
|---|---|
agent-engine |
O binário principal: serviços, controladores e orquestração do agente. |
yuli-mcp |
O servidor MCP para agentes externos, os hooks e o gate. |
code-intelligence |
O motor de inteligência de código: núcleo do grafo, Java, autocompletar, planejador e frameworks (Struts, JBoss). |
java-debug |
O cliente JDWP do depurador Java. |
O motor é organizado em camadas: domain (tipos e regras puras), service (lógica) e controller (IPC). A interface só fala com os controladores.
Inteligência de código
| Peça | Tecnologia |
|---|---|
| Análise sintática | Tree-sitter (Java e TypeScript) |
| Grafo de símbolos | petgraph, com nós (classes, métodos, campos, beans do Spring) e arestas (chama, estende, implementa, injeta) |
| Persistência | SQLite em .ai/codebase/, por projeto |
| Invalidação | Um grafo de dependências entre arquivos: editar um arquivo reanalisa apenas o que depende dele |
| Resolução de tipos | O compilador Java |
| Planejamento | Filas de prioridade para que o que você está vendo seja resolvido primeiro |
Para responder a perguntas sobre o projeto, o agente recebe um subgrafo delimitado em vez de arquivos inteiros. Assim, nem a janela de contexto nem o custo em tokens se esgotam.
Onde fica cada coisa
| Local | Conteúdo |
|---|---|
.ai/ no seu projeto |
Contrato, missões, memória, regras e índice. Veja A pasta .ai. |
%APPDATA%\.yulicode (Windows) |
Configurações, prompts, skills e hooks próprios, histórico do chat. |
%LOCALAPPDATA%\.yulicode (Windows) |
Runtimes, índices, caches e logs. Pode ser apagado. |
| Chaveiro do sistema | API keys, senhas e tokens. |
No macOS e no Linux, a mesma divisão é usada nas pastas padrão de cada sistema.
Regras determinísticas
Os limites de segurança e qualidade vivem no motor, não no prompt:
- O sandbox do projeto e os caminhos protegidos.
- A avaliação de risco de cada ação.
- A ocultação de segredos antes que saiam da máquina.
- A política de acesso a cada banco de dados.
- O gate de qualidade, o mesmo para pessoas, agentes, hooks do Git e CI.
Um modelo não consegue contornar uma regra convencendo a si mesmo.
Extensões
Os plugins são carregados sem recompilar, executados de forma isolada (uma falha não afeta o IDE) e declaram as suas permissões em um manifesto. Eles podem adicionar comandos e painéis, inspeções, itens de menu e da barra de status, configurações próprias, dados para o agente e as suas próprias traduções.