From 1b1a1791f1a055489690c059bd1feceba0399a83 Mon Sep 17 00:00:00 2001
From: Stephen Waits <1+swaits@noreply.git.swaits.com>
Date: Sun, 11 Oct 2026 01:37:10 +0000
Subject: [PATCH] First slice: ledger-store (journal+blobs+sqlite) and
 ledger-mcp (18 tools, receipt policy)

---
 crates/ledger-store/src/lib.rs | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 crates/ledger-store/src/lib.rs

diff --git a/crates/ledger-store/src/lib.rs b/crates/ledger-store/src/lib.rs
new file mode 100644
index 0000000..9a828eb
--- /dev/null
+++ b/crates/ledger-store/src/lib.rs
@@ -0,0 +1,30 @@
+//! `ledger-store`: durable persistence for the books.
+//!
+//! Three pieces, one job — keep the books safe:
+//!
+//! * [`journal`] — the source of truth. An append-only, hash-chained JSONL
+//!   journal. Every state change is an immutable fact, fsync'd on append.
+//! * [`blob`] — the bytes. Content-addressed (SHA-256), immutable,
+//!   deduplicated receipt and document storage.
+//! * [`Store`] — the SQLite projection plus the write path. SQLite is the
+//!   query engine and is disposable by design: [`Store::rebuild`] drops it
+//!   and replays the journal. [`Store::verify`] replays the journal into a
+//!   fresh engine and diffs its reports against both the live ledger and
+//!   the projection.
+//!
+//! The write path is singular: **validate → journal → mutate → apply**.
+//! Journal first means a failed write leaves nothing behind; a failed
+//! SQLite apply leaves the journal ahead, and the next open heals it via
+//! `last_applied_seq`. There is exactly one writer: `Store` is `!Sync` by
+//! construction (it owns a `rusqlite::Connection`).
+
+pub mod blob;
+pub mod error;
+pub mod journal;
+pub mod schema;
+pub mod store;
+
+pub use blob::BlobStore;
+pub use error::StoreError;
+pub use journal::{GENESIS_PREV, JournalLine, JournalWriter};
+pub use store::{Attachment, DB_FILE, EntryRow, EventRow, JOURNAL_FILE, Store};