Tauri Backend API & Rust Core

Relevant source files

The following files were used as context for generating this wiki page:

• src-tauri/src/skills.rs
• src-tauri/src/gitlab.rs
• src-tauri/src/jira.rs
• crates/rebase-core/src/skills.rs
• crates/rebase-core/src/inbox/jira.rs
• crates/rebase-core/tests/shared_contracts.rs
• CONTRIBUTING.md

The Tauri backend and Rust core provide the foundational services for the Rebase application. This includes cross-platform filesystem access, integration with external providers like GitLab and Jira, and the management of agent "skills." While the React/Tauri app serves as the production frontend, the Rust side handles heavy lifting such as PTY management, session storage, and native windowing.

The architecture is split between src-tauri/src/, which contains Tauri-specific command implementations, and crates/rebase-core, which houses the provider-independent logic and native port implementations. This separation allows the core logic to be shared between the Tauri application and the experimental GPUI-based native app.

Sources: CONTRIBUTING.md:16-21, crates/rebase-core/tests/shared_contracts.rs:1-10

Core Service Architecture

The Rust backend implements several key modules responsible for different aspects of the agentic workflow.

Integration Flow

The following diagram illustrates how the Rust backend mediates between the frontend UI and external services.

This diagram shows the data flow from the User Interface through the Tauri API layer into specialized Rust modules that interact with the local filesystem and remote REST APIs.

Sources: src-tauri/src/skills.rs, src-tauri/src/gitlab.rs, src-tauri/src/jira.rs

Skill Discovery and Management

The system identifies "skills" by scanning specific directories for SKILL.md files. These files contain frontmatter that defines the skill's name and purpose. The discovery process prioritizes project-specific skills over user-level or harness-specific skills.

Skill Hierarchy and Priority

When multiple skills share the same name, the system resolves them based on the following priority:

1. Project-specific Agents: .agents/skills within the current working directory.
2. User-level Agents: ~/.agents/skills in the home directory.
3. Harness-specific: Folders like .claude/skills, .cursor/skills, etc.

Sources: src-tauri/src/skills.rs:104-130, crates/rebase-core/src/skills.rs:108-135

Skill Discovery Data Model

Field	Type	Description
name	String	Unique identifier (lowercase, hyphens, digits).
description	String	Extracted from Markdown frontmatter.
path	String	Absolute path to the SKILL.md file.
scope	String	Either "project" or "user".
source	String	Originating harness (e.g., "agents", "claude", "jira").

Sources: src-tauri/src/skills.rs:16-24

Third-Party Provider Integrations

The backend implements custom clients for GitLab and Jira to support features like issue triaging and PR reviews.

GitLab Integration

The GitLab module handles repository detection via Git remotes and provides access to merge requests, issues, and todos. It supports both GitLab.com and self-hosted instances.

• Repository Discovery: gitlab_repo identifies the GitLab project by parsing git config --get-regexp ^remote\..*\.url.
• Diff Parsing: gitlab_mr_diff fetches merge request changes and truncates large patches to avoid memory issues (limit: 2MB).
• Authentication: Uses a PRIVATE-TOKEN header for API requests.

Sources: src-tauri/src/gitlab.rs:120-150, src-tauri/src/gitlab.rs:15-18

Jira Integration

The Jira module interacts with Atlassian Cloud via the REST API (v3). It translates Jira's Atlassian Document Format (ADF) into Markdown for the frontend.

The sequence shows the transformation of structured ADF content into Markdown to ensure consistent rendering in the application's inbox.

Sources: src-tauri/src/jira.rs:580-600, src-tauri/src/jira.rs:160-175

Shared Contracts and Native Core

To maintain compatibility between the Tauri application and the native GPUI port, the project enforces "shared contracts." These ensure that both versions access the same database and configuration paths.

Persistence and Storage Constants

The backend uses a shared SQLite database and predictable directory structures for cross-app compatibility.

Component	Path / Value
App Identifier	com.rebase.desktop
Database Name	rebase.db
Database Path	com.rebase.desktop/rebase.db
Pilot Files	pilots/ directory
Native App ID	com.rebase.native

Sources: crates/rebase-core/tests/shared_contracts.rs:60-75, crates/rebase-core/tests/shared_contracts.rs:120-125

Shared Database Schema

The system pins specific table names to prevent drift between the Tauri and Native implementations:

• pilot_transcripts
• pilot_turns
• pilot_blocks

Sources: crates/rebase-core/tests/shared_contracts.rs:85-95

Security and Filesystem Handling

The Rust core manages sensitive configuration data by writing "secret files" with restricted permissions. On Unix-like systems, files like gitlab-config.json and jira-config.json are created with mode 0o600 (read/write by owner only).

Sources: src-tauri/src/gitlab.rs:720-740, src-tauri/src/jira.rs:880-900

The backend also handles path normalization across platforms. On Windows, it manages UNC paths (stripping \\?\) and ensures case-insensitive path comparisons to avoid duplicating skills or configurations.

Sources: src-tauri/src/skills.rs:59-70, crates/rebase-core/src/skills.rs:53-65

Summary

The Tauri Backend and Rust Core provide a stable, cross-platform foundation for Rebase. By centralizing logic for skill discovery, provider integration, and data persistence in Rust, the project maintains high performance and allows for the experimental development of the Rebase Native port without sacrificing the stability of the production React/Tauri environment.