r0/Docs/Architecture & Internals

// SYSTEMS GUIDE · FROM USER FLOW TO IMPLEMENTATION

Architecture &
Internals.

r0 is a native desktop IDE with a React and TypeScript workbench, a Tauri application host, domain-organized Rust commands, and a multi-crate Rust workspace. This guide follows a real project session from launch through editing, tools, review, and Git—and explains what each architectural layer contributes.

REACT + TYPESCRIPTTAURIRUST WORKSPACEWINDOWS + LINUX RELEASES

01 / HIGH-LEVEL USER FLOW

One project session, end to end

Start from what the person does. r0 keeps editing, AI assistance, project tools, verification, and source control near the same workspace; each step activates different frontend features and native services as needed.

01OPEN A PROJECT

Start in context

  1. 01
    Launch r0

    The desktop app starts its React workbench and native services.

  2. 02
    Open a workspace

    Settings and project context prepare files, search, and language tools.

BOOTSTRAP · WORKSPACE · PROJECT
02BUILD AND EXPLORE

Work across tools

  1. 03
    Edit and navigate

    Browse, open, search, and change project files.

  2. 04
    Use integrations

    Bring in AI, terminal, Git, database, and debugger tools as needed.

EDITOR · AI · TERMINAL · GIT
03VERIFY AND SHIP

Review each change

  1. 05
    Check the result

    Inspect edits and diffs, run project checks, and review status.

  2. 06
    Commit and continue

    Stage intended files, commit, and continue the development loop.

REVIEW · RUN ACTIONS · VERSION CONTROL

02 / HIGH-LEVEL SYSTEM MAP

The workbench sits inside a desktop application

The frontend owns presentation and feature workflows. Tauri hosts it and exposes native capabilities. Rust command adapters connect that desktop boundary to domain services and, where configured, external tools or providers.

ARCHITECTURE.MAPSYSTEM
01
PRESENTATION

React + TypeScript workbench

src/
↗
02
DESKTOP HOST

Tauri application

src-tauri/
↗
03
COMMAND ADAPTERS

Domain-organized Rust commands

src-tauri/src/commands/
↗
04
DOMAIN SERVICES

Rust workspace crates

crates/
↗
CONNECTED CAPABILITIES
Local projectOperating systemConfigured providersExternal tools
PRESENTATION

React + TypeScript workbench

src/

Renders the application shell and feature-owned interface, hooks, stores, and services. The code is organized around user-facing capabilities such as AI, Git, terminal, and workspace navigation.

Browse this source
DESKTOP HOST

Tauri application

src-tauri/

Owns the native app lifecycle, desktop plugins, window setup, shared managed state, and the bridge between frontend requests and Rust-side functionality.

Browse this source
COMMAND ADAPTERS

Domain-organized Rust commands

src-tauri/src/commands/

Groups desktop-facing operations by area—AI, project, editor, database, version control, UI, and development—so app-specific transport concerns are distinct from the domain crates.

Browse this source
DOMAIN SERVICES

Rust workspace crates

crates/

Holds focused native capabilities such as AI integrations, project/file operations, terminal sessions, Git, databases, language servers, extensions, search, remote support, and debugging.

Browse this source

03 / APPLICATION STARTUP

From process entry to ready workbench

Startup is split across the native process and frontend. The frontend tracks named bootstrap phases so settings, foundational services, and extensions do not all need to initialize in one blocking step.

01 · NATIVE ENTRY

Start the desktop process

src-tauri/src/main.rs prepares the Tauri application, its plugins, window behavior, and app configuration. The native process owns OS integration and shutdown.

02 · FRONTEND ENTRY

Mount the application shell

src/main.tsx creates the React root. src/App.tsx provides the outer shell and lazy-loads the workbench or specialized windows.

03 · SETTINGS + FOUNDATION

Prepare required state

The bootstrap service coordinates settings with foundational async work and records progress. The workbench can render while non-blocking setup continues.

04 · WORKBENCH READY

Register feature contributions

After the first workbench frame, startup finishes foundation tasks, registers contributions, and then starts extension-runtime work before reaching the corresponding readiness phases.

05 · NATIVE SERVICES

Keep reusable managers available

app_setup.rs places shared managers—such as terminal, agent bridge, language server, debugger, and search state—into Tauri-managed application state.

BOOTSTRAP SEQUENCETYPESCRIPTOpen source ↗

The bootstrap implementation waits for settings and foundational tasks, reports their outcomes, then advances the workbench phase.

const foundationalResults = await Promise.allSettled([
  settingsLoaded,
  ...foundationalBootstrapSteps.map((step) => step.run()),
]);
reportBootstrapResults(steps, foundationalResults);
useBootstrapPhaseStore.getState().actions.reachPhase("workbench-ready");

const extensionResults = await Promise.allSettled(
  extensionBootstrapSteps.map((step) => step.run()),
);
reportBootstrapResults(extensionBootstrapSteps, extensionResults);
useBootstrapPhaseStore.getState().actions.reachPhase("extensions-ready");

04 / COMMANDS, EVENTS, AND REQUEST LIFECYCLE

A UI action becomes a native operation

The Tauri boundary supports request/response commands and asynchronous events. Commands are grouped by domain in the app; domain crates hold reusable native capabilities. The exact path varies by feature.

01 / FEATURECapture intent

UI reads current workspace and user input.

02 / BRIDGESend request

Tauri transports a command and its arguments.

03 / ADAPTERCoordinate work

Rust handler checks context and accesses managed services.

04 / DOMAINPerform operation

Project, AI, Git, terminal, or another service does its work.

COMMAND / EVENT SEQUENCEFLOW
User action
  → React feature updates UI state
  → Tauri command request crosses the desktop boundary
  → Rust command validates and coordinates the operation
  → Domain service performs native or integration work
  ← command result returns, or events report ongoing changes
  ← React feature updates the view
SHORT REQUEST

Project operation

A user action such as opening or changing a project file is handled through project-oriented commands and services. A completed operation returns a result; an error must stay visible to the caller.

LONG-LIVED SESSION

Terminal or agent

A terminal or agent session outlives a single command. r0 tracks session state and routes output/events so the right workbench window can update while the process is active.

BACKGROUND CHANGE

Workspace file watcher

The native workspace-change sink delivers file-change batches to subscribed windows and feeds the search index. This keeps editor views and search aware of file changes without making each view poll independently.

MANAGED NATIVE SERVICESRUSTOpen source ↗

Tauri-managed state lets command handlers share long-lived managers. This excerpt follows the actual manager types used by app setup.

let terminal_manager = Arc::new(TerminalManager::new());
app.manage(terminal_manager.clone());
app.manage(FrontendTerminalSessions::default());

let acp_bridge = Arc::new(Mutex::new(AcpAgentBridge::new(
  Arc::new(TauriAcpEventSink::new(app.handle().clone())),
  acp_host_info(app.handle()),
  terminal_manager,
  commands::agent_launch_env(app.handle().clone()),
)));
app.manage(acp_bridge);

05 / IDE SUBSYSTEMS

How the product areas map to source

Frontend feature directories group the user-facing workflow; Rust crates group native implementation. src-tauri/src/commands connects the two where a feature needs desktop capabilities.

Product areaFrontendNative / RustWhat the area owns
Workbench and startupfeatures/bootstrap · features/layout · features/windowsrc-tauri app setupMounts the shell, initializes settings and feature contributions, manages windows, and prepares shared native services.
Editor and language toolsfeatures/editor · features/outline · features/referencescrates/lsp · crates/runtimeConnects editing and navigation workflows with language-server, runtime, and editor services.
Project files and searchfeatures/workspace · features/file-explorer · features/file-search · features/quick-opencrates/project · crates/fff-searchWorks with project roots, file operations, workspace changes, quick navigation, and search.
AI and agentsfeatures/aicrates/ai · crates/claude-ide · commands/aiConnects the agent interface and session workflows to supported agent/protocol integrations and native workspace operations.
Git and GitHubfeatures/git · features/githubcrates/version-control · crates/github · commands/version_controlSeparates local repository operations from GitHub-connected features and their workbench UI.
Terminal and executionfeatures/terminal · features/run-actionscrates/terminal · crates/exec-path · crates/runtime · crates/wslCoordinates terminal sessions and execution-related support across available host environments.
Database and debuggingfeatures/database · features/debuggercrates/database · crates/debuggerProvides dedicated database and debugging integration areas. Exact providers and setup depend on the installed build.
Extensions and appearancefeatures/extensions · extensions/themes · features/settingscrates/extensions · app settings and pluginsConnects extension/runtime and theme customization with user settings and desktop integration.
Additional integrationsfeatures/browser · features/docker · features/remote · features/collaborationcrates/browser · crates/docker · crates/remote · crates/wslOrganizes browser, container, remote, WSL, and collaboration-related capabilities into focused product areas.

Editor and language intelligence

The workbench’s editor, outline, references, and navigation features are distinct from native language-server management. A language feature can depend on the project being open and the language tooling being available and configured.

AI and workspace changes

Agent integrations are a workflow layer, not a substitute for review. The frontend handles sessions and user-facing change review; Rust AI services and commands coordinate supported providers and workspace operations.

Git is split by responsibility

Local source-control operations live in the version-control domain; GitHub integrations have their own feature and crate areas. Provider credentials and remote access are separate from merely opening a local repository.

Integrations are capability-dependent

Database engines, debuggers, browser tools, Docker, remote environments, extensions, and AI providers may require installation, configuration, or platform support. A directory in the repository does not imply every integration is active in every build.

06 / STATE, SESSIONS, AND LIFECYCLE

Keep ephemeral work attached to its owner

The app has more than one kind of state. Durable preferences, active workspace context, frontend view state, native service managers, and live terminal or agent sessions have different owners and lifetimes.

USER SETTINGS

Persist preferences

Settings initialize early because themes, keymaps, and other interface behavior depend on them. Bootstrap phases coordinate consumers so they do not write defaults over settings that have not loaded.

WORKSPACE CONTEXT

Scope project work

The active project/root informs file operations, search, language tools, terminal context, and version control. Multi-window workflows need explicit project and window ownership.

MANAGED SERVICES

Reuse native managers

Tauri-managed state holds services such as terminal and language-server managers that are reused by commands. The app setup composes them with event sinks and per-window/session coordination.

LIVE SESSIONS

Start, stream, clean up

Terminal and agent sessions have identifiers and connections. Window close, retry, or session replacement must clean up or supersede stale links so output is not attributed to the wrong session.

Create session→Associate window + workspace→Send input / receive events→Close or replace→Release connections

07 / CORE ARCHITECTURAL PRINCIPLES

What keeps the IDE maintainable

These principles follow from the product’s actual structure and help contributors change one workflow without breaking neighboring ones.

01

Organize the UI by capability

Feature areas such as AI, Git, terminal, database, and workspace own their components, services, stores, and tests. Keep UI behavior close to the workflow it serves.

02

Keep desktop adapters at the boundary

Tauri commands adapt app-level requests to native capabilities. Put reusable domain behavior in its service/crate when appropriate instead of coupling domain logic to a particular screen.

03

Use async events for ongoing work

Commands can start or control an operation; events can report progress, output, or workspace changes. Model subscriptions and teardown as part of the feature, not incidental UI code.

04

Make workspace and window ownership explicit

A desktop app can have multiple windows and concurrent projects. Route file-change and session events to their intended owner, and verify the active project before performing mutations.

05

Stage startup by dependency

Load essential settings and foundational services before dependents need them; let later contributions such as extension runtime follow the workbench-ready phase.

06

Keep optional integrations optional

AI providers, language servers, databases, remote environments, and extensions have their own setup and failure modes. Surface missing prerequisites instead of disguising an unavailable integration as success.

08 / VERTICAL WALKTHROUGH

Trace a user-visible change through the stack

For example, following a terminal action from its panel to native session management gives a practical way to orient yourself in this repository.

  1. Find the feature UIsrc/features/terminal/

    Look for the panel/component and hook responsible for the interaction.

  2. Find frontend session behaviorsrc/features/terminal/services/ · hooks/ · stores/

    Identify how the UI tracks the active terminal, sends input, and subscribes to output or lifecycle events.

  3. Find the desktop adaptersrc-tauri/src/terminal.rs · src-tauri/src/main.rs

    Inspect the Tauri commands and their registration/managed state. The app exposes operations including beginning a frontend session, creating a terminal, writing input, and resizing.

  4. Find reusable native behaviorcrates/terminal/

    Follow the terminal manager, shell, connection, and protocol modules for implementation details.

  5. Verify the full interactionfrontend tests · Rust tests · app build

    Cover session start, output, retry/cleanup, and window ownership where relevant—not only the first successful launch.

09 / SOURCE MAP

Where to read next

Use these entry points to follow the implementation. The repository is the source of truth as modules and integrations evolve.

REPOSITORY.MAPTREE
src/
  main.tsx                 React mount
  App.tsx                  Shell, error boundary, lazy entry points
  workbench-app.tsx        Main workbench composition
  features/                Feature-owned UI, state, and services

src-tauri/src/
  main.rs                  Native process and Tauri builder
  app_setup.rs             App setup and shared managed state
  commands/                Domain-organized desktop adapters
  terminal.rs              Terminal session bridge
  file_events.rs           Workspace change delivery
  acp_events.rs            Agent protocol event sink

crates/
  ai/ project/ terminal/ version-control/
  database/ lsp/ extensions/ fff-search/
  debugger/ browser/ docker/ remote/ wsl/ ...
Frontend application entrysrc/main.tsxApplication shellsrc/App.tsxWorkbench compositionsrc/workbench-app.tsxBootstrap orchestrationsrc/features/bootstrap/services/initialize-app-bootstrap.tsNative application entrysrc-tauri/src/main.rsNative service setupsrc-tauri/src/app_setup.rsDomain command modulessrc-tauri/src/commands/mod.rsRust workspace manifestCargo.toml

10 / CONTRIBUTOR CHECKLIST

Make a change at the right layer

01 Start from the user workflow and identify the owning frontend feature.

02 Trace each native call to its Tauri command and domain service.

03 Define the response, event, error, workspace, and window ownership behavior.

04 Add a focused regression test at the layer where the behavior lives.

05 Run relevant checks, review the diff, and verify the integrated workflow.

Browse the r0 repository ↗Explore command adapters ↗Explore Rust crates ↗Check published releases ↗

This guide describes implementation areas present in the public repository, not a guarantee that every provider, database, debugger, or platform integration is enabled in every release. Check the installed version’s release notes and project documentation for current support.