Skip to content

Infrastructure & Tooling

Jump to bottom
Chazona Baum edited this page Jun 24, 2026 · 2 revisions

Relevant source files

Lodestar is built on a modern desktop stack that combines the performance and safety of Rust with the rapid UI iteration of Svelte 5. The infrastructure is designed to handle a local-first workflow where the filesystem is the primary database, necessitating robust file watching, secret management, and a comprehensive testing suite.

Tauri Configuration & Build System

Lodestar utilizes Tauri v2 as its core framework src-tauri/tauri.conf.json#1-5 The build system is split between a Rust backend managed by Cargo and a SvelteKit frontend managed by Vite.

  • Frontend Integration: The frontend is built as a Single Page Application (SPA) using @sveltejs/adapter-staticsvelte.config.js#5-14 During development, Tauri connects to a Vite dev server at http://localhost:1420src-tauri/tauri.conf.json#8
  • Permissions: System capabilities like file dialogs and external openers are explicitly defined in the capabilities configuration src-tauri/capabilities/default.json#8-12
  • Build Pipeline: The beforeDevCommand triggers npm run dev to start the Vite server, while beforeBuildCommand ensures a production frontend build is placed in ../build before the Rust binary is compiled src-tauri/tauri.conf.json#6-11

Build & Dev Flow

flowchart TD
    subgraph Production
        E["tauri build"]
        F["npm run build"]
        G["Static Assets (../build)"]
        H["cargo build --release"]
        I["App Bundle (.app/.exe)"]
        A["tauri dev"]
        B["npm run dev (Vite)"]
        D["WebView"]
    end
    subgraph Development
        C["cargo build (Rust)"]
    end
    E --> F
    F --> G
    G --> H
    H --> I
    A --> B
    A --> C
    B --> D
    C --> D
Loading

Sources: src-tauri/tauri.conf.json#1-37svelte.config.js#1-18vite.config.js#1-31

Testing Strategy

The codebase maintains high reliability through a dual-layered testing approach. Rust unit tests handle the logic of the pipeline, fit scoring, and note parsing, while Vitest handles frontend state and UI component logic.

  • Rust Testing: Uses inline #[cfg(test)] modules. To test the job-fetch pipeline without external side effects, the system utilizes FakeScraper and FakeLlm implementations.
  • TypeScript Testing: Vitest is used to verify Svelte 5 runes, job status transitions, and complex UI components like the fit breakdown and pipeline progress indicators.

For details, see Testing Strategy.

Vault File Watcher & Live Reload

Because Lodestar operates directly on a Markdown vault, the UI must stay in sync with external edits (e.g., a user modifying a file in Obsidian). The watcher.rs module implements this using the notify crate.

  • Change Classification: The system maps filesystem events to internal entity updates (e.g., a change in companies/ triggers a record:changed event for that specific slug).
  • Self-Write Suppression: To prevent infinite loops when the app itself writes to the vault, the note::was_self_write logic tracks internal operations and ignores the resulting filesystem events.
  • Frontend Bridge: The startVaultSync function in TypeScript listens for these events and updates the corresponding Svelte global stores (e.g., companiesStore).

For details, see Vault File Watcher & Live Reload.

Secret Management

Lodestar requires sensitive API keys for ScrapingBee and OpenRouter. These are never stored in the vault or the application configuration files.

  • OS Keychain: The secrets.rs module uses the keyring crate to interface with the native OS credential store (e.g., Apple Keychain on macOS).
  • In-Memory Caching: To avoid repeated decryption prompts and improve performance, keys are cached in an in-memory OnceLock.
  • Whitelisting: Only specific keys defined in SECRET_KEYS are managed by this system to prevent arbitrary keychain access.

For details, see Secret Management.

Infrastructure Component Map

Sources: src-tauri/src/main.rs#1-20src-tauri/tauri.conf.json#1-37

Clone this wiki locally