Module core 

The transport-agnostic, Tauri-free CORE of the plugin.

Everything here is plain Rust with no dependency on the tauri crate, so it is unit-testable without a window or a mock runtime. The Tauri shell (see lib.rs) is a thin layer that owns one SyncularCore on a dedicated thread, forwards syncular_command / syncular_query invokes to it, and pumps drained events onto the syncular://event Tauri channel.

This mirrors the syncular-ffi Handle: one owned SyncClient, one owned HostTransport (native HTTP+WS via the native-transport feature), and a derived event queue. The plugin is the THIRD consumer of the shared syncular-command router (after the conformance shim and the FFI core), so the command surface stays conformance-locked.

Thread-safety, honestly

SyncClient is synchronous and NOT Sync — it owns a rusqlite connection. The plugin follows the shim/FFI pattern: exactly ONE thread owns the core, and all access arrives through a command MAILBOX (an mpsc channel). The Tauri commands (running on Tauri’s async runtime) never touch the client directly; they post a [Request] to the owning thread and await the reply. The background host loop (§8.4) runs ON that same owning thread, interleaved with mailbox requests, so there is never concurrent access to the connection.

Structs

Event

One client-observable event (§8 realtime signals + §6 conflicts + §1.6 schema floor + §7.3 lease). JSON-able; delivered onto the Tauri channel. The same event vocabulary the FFI poll_event surfaces.

SyncularCore

The Tauri-free core: one client, its owned transport, the derived-event diff state, and the pending event queue. Lives on ONE owning thread.