Documentation / Reference
Architecture
How Yuli is built: a native Rust engine, an Electron interface with TypeScript and React, and the language model as the layer that reasons.
Yuli draws a clear line between who does the heavy lifting, who draws the screen, and who reasons.
| Layer | Technology | Responsibility |
|---|---|---|
| Native engine | Rust | Indexing and semantic analysis, Git, processes, debugging, databases, security, quality, and agent orchestration. |
| Interface | Electron, TypeScript, and React | Rendering only: editor, panels, diagrams, and previews. |
| Language model | The provider or agent you choose | Reasons: plans, decides, and operates the IDE's services through controlled tools. |
The application runs on Windows, macOS, and Linux, 64-bit end to end.
How they communicate
Interface (Electron + React)
│ IPC over stdin/stdout
▼
Engine (agent-engine, Rust) ──▶ Git, build, debugger, database, index
│
├──▶ AI provider (Platform mode)
│
└──◀ yuli-mcp ◀── stdio ── Claude Code, Kiro, Codex, Antigravity
(TCP 127.0.0.1 + token)
- The interface starts the engine as a process and talks to it over stdin/stdout.
- The interface never touches the disk, Git, or the agent's network on its own: everything goes through the engine's controllers.
- External agents connect through
yuli-mcp, which talks to the engine over a token-protected loopback socket. See Yuli as an MCP server.
Engine components
| Component | What it does |
|---|---|
agent-engine |
The main binary: services, controllers, and agent orchestration. |
yuli-mcp |
The MCP server for external agents, the hooks, and the gate. |
code-intelligence |
The code intelligence engine: graph core, Java, autocomplete, scheduler, and frameworks (Struts, JBoss). |
java-debug |
The Java debugger's JDWP client. |
The engine is organized in layers: domain (pure types and rules), service (logic), and controller (IPC). The interface only talks to the controllers.
Code intelligence
| Piece | Technology |
|---|---|
| Parsing | Tree-sitter (Java and TypeScript) |
| Symbol graph | petgraph, with nodes (classes, methods, fields, Spring beans) and edges (calls, extends, implements, injects) |
| Persistence | SQLite in .ai/codebase/, per project |
| Invalidation | A dependency graph between files: editing one re-analyzes only what depends on it |
| Type resolution | The Java compiler |
| Scheduling | Priority queues so that what you're looking at is resolved first |
To answer questions about the project, the agent receives a bounded subgraph instead of entire files. That keeps both the context window and the token cost under control.
Where everything lives
| Location | Contents |
|---|---|
.ai/ in your project |
Contract, missions, memory, rules, and index. See The .ai folder. |
%APPDATA%\.yulicode (Windows) |
Settings, your own prompts, skills, and hooks, and chat history. |
%LOCALAPPDATA%\.yulicode (Windows) |
Runtimes, indexes, caches, and logs. Safe to delete. |
| System keychain | API keys, passwords, and tokens. |
On macOS and Linux, the same split applies, using each system's standard folders.
Deterministic rules
The security and quality boundaries live in the engine, not in the prompt:
- The project sandbox and protected paths.
- The risk assessment of every action.
- Secret redaction before anything leaves your machine.
- The access policy for each database.
- The quality gate, the same for people, agents, Git hooks, and CI.
A model can't bypass a rule by talking itself into it.
Extensions
Plugins load without recompiling, run in isolation (a failure doesn't affect the IDE), and declare their permissions in a manifest. They can add commands and panels, inspections, menu and status bar entries, their own settings, data for the agent, and their own translations.