wanderbooks/docs/receipt-store.md

Receipt & document store + persistence spec

Three pieces: the journal (the source of truth), the blob store (the bytes), and SQLite (the queryable projection). All immutable-first, matching the ledger's philosophy: the books never forget, and neither does the filing cabinet.

The journal: the source of truth

SQLite is the query engine, not the source of truth. The source of truth is an append-only journal of domain events: one JSON object per line (JSONL), hash-chained. This is the deliberate answer to "insanely durable, easily backupable, journable":

• Durable. Every state change is an immutable fact appended to journal.jsonl, fsync'd per append. Each line carries the SHA-256 of the previous line's canonical bytes (prev), forming a tamper-evident chain: bit rot, torn writes, and casual editing are detected on read/verify, not discovered at tax time. Honest scope: this detects corruption and casual tampering. It does not stop a determined attacker with full write access from rewriting the chain — nothing local does.
• Backupable. The backup is cp -r $WANDERBOOKS_DATA /backup: the journal file plus the blob directory. Plain files, no WAL-file timing windows, no special backup API. A copy taken mid-write, like a crash or power loss mid-append, can end in a cut-off line (bytes after the last newline). It was never acknowledged, so opening the books saves those bytes to journal.jsonl.torn.<time>, truncates to the last newline, and journals a journal.tail_repaired line; books.digest reports it. Damage before the last newline is corruption and refuses to open: that is for a human, never repaired automatically. The server does better (plan 3.7): it commits the journal, the blobs, the vault, its key and the access log to each book's own git repository (the blobs staged ahead, the commit under the store's lock) and pushes it to the owner's private repository and backup folder, versioned and deduplicated, with full history (docs/mcp-interface.md, "Tools — backups").
• Journable. It literally is a journal: {seq, ts, type, payload, prev}. Greppable, diffable, replayable. The audit trail isn't a feature bolted on — it's the storage format.

Write path

There is exactly one write path: append to the journal, fsync, then apply to SQLite. No dual writes, no background applier thread (the volume doesn't justify it): the MCP server appends, fsyncs, applies the new lines to the projection synchronously, and returns. A crash between append and apply is safe — on startup the applier replays every journal line with seq > last_applied_seq.

Line format

{"seq": 42, "ts": "2026-10-10T18:20:00Z", "type": "entry.posted",
 "payload": { "...": "..." }, "prev": "abc123..."}

• seq: 1-based, gapless, assigned by the writer.
• ts: UTC, RFC 3339. Recorded, never trusted for ordering (seq orders).
• type: account.added, entry.posted, entry.reversed, invoice.created, bill.created, receipt.attached, receipt.linked, receipt.unlinked, document.filed, attachment.withdrawn, invoice.sent (a recorded send: a document's record, never a ledger line or a figure; P4b S5) (plus the A/R, A/P, asset, period, payroll, and class events listed on JournalLine). invoice.written_off, bill.created, receipt.attached, receipt.linked, receipt.unlinked, document.filed, attachment.withdrawn (plus the A/R, A/P, asset, period, payroll, and class events listed on JournalLine).
• payload: the full domain facts (account fields, entry with lines, blob sha, ...). Everything the applier needs; nothing it must look up elsewhere. An invoice.created or bill.created written after the documents_v2 upgrade (plan P4b S4.3) carries only the new fields it names, so a document naming none is byte for byte the payload every earlier version wrote: the invoice's number, terms, bill_to and seller snapshots (as they were at issue), customer_ref and memo; the bill's vendor_ref, received_on, terms, memo and the duplicate_reason that allowed a duplicate of a standing vendor invoice; and each line's account, quantity and unit_price. The issued copy of an invoice is not a field on the event (its attachment id is allocated after the entry exists): it is a receipt.attached on the invoice's own entry (INV-0007.pdf, application/pdf, "Issued invoice"), its SHA-256 the blob_sha, linked to the invoice with attachment.linked and found through that link (plan 8.3.11). An invoice.written_off (plan 8.3.6, P4b S7) carries {invoice_id, entry_id, date, amount, reason}; replay tags the entry's receivables line WriteOff, and the projection keeps no written-off figure either: it is the tagged lines' sum (rules.md B-38, B-41). Its evidence of worthlessness rides beside it, as a receipt.attached on the write-off's entry and an attachment.linked to the invoice, filed in the same call.
• prev: hex SHA-256 of the previous line's canonical JSON (keys sorted, no whitespace). The genesis line uses "prev": "000...0" (64 zeros).

Drafts are journaled (durable)

Draft entries are durable: entry.created and entry.line_added journal lines record the draft as the agent builds it, so drafts (and receipts attached to them) survive server restarts. Drafts never touch the SQLite projection until posted — reports only see posted entries. A draft that never posts leaves its created/line_added lines in the journal, which is correct: the journal records what happened, including abandoned work.

Verification

wanderbooks verify (a ledger-store API, later a CLI subcommand): re-read the journal, recompute the hash chain, replay every line into a fresh in-memory Ledger, and compare its reports against the SQLite projection's. Any mismatch is a loud failure. Run it on startup (cheap at this scale); a backup is then proven where it lands, by a drill (docs/mcp-interface.md, "Tools — backups").

Blob store

• Content-addressed. The key is SHA-256 of the exact bytes. Path: $DATA/blobs/<first2>/<next2>/<full-hex>. Same bytes, same path, forever.
• Immutable. Blobs are never modified or deleted by the application. A retention/deletion policy is an explicit future human decision, not an accident of implementation.
• Deduplicated. Attaching the same receipt twice stores one blob and two attachment rows. attach_receipt / file_document return deduplicated: true when the blob already existed.
• Limits. 25 MiB per file, as an upload (books.begin_upload): the only way a file comes in (D-46: nothing is given inline). The name and MIME type are the client's, checked when the file is filed: a name of 1 to 255 bytes, no / or \, not . or .., no control or invisible characters; a type/subtype of visible ASCII, at most 127 bytes (docs/mcp-interface.md, "Tools — receipts & documents"). The type is stored as given; server-side sniffing is future work (only a W-9 is judged by its first bytes).
• Metadata lives in SQLite (blobs table), not in the filesystem: sha256 PK, size_bytes, mime_type, original_name, created_at.

Attachments & documents

• attachments: id PK, blob_sha FK, entry_id FK NULL, category, description, created_at.
  • entry_id is nullable: a receipt can be filed before its journal entry exists, then linked with books.link_receipt.
  • category mirrors today's Drive layout: formation, legal, tax, accounting (today's 01 Formation / 02 Legal / 03 Tax / 04 Accounting), plus receipts.
• Documents filed via books.file_document and receipts via books.attach_receipt share the blob store; they differ only in metadata.
• Receipts change by events, never by edits. receipt.unlinked (attachment_id, entry_id, reason) detaches a receipt from its entry; attachment.withdrawn (attachment_id, reason) retires an unlinked receipt or a document (withdrawn_at, withdrawn_reason columns, schema v5). Linking requires an unlinked, non-withdrawn attachment, so evidence only leaves an entry through a recorded unlink. Blobs are untouched: a withdrawn file is still hash-verified and readable, and the journal shows when it was filed, linked, unlinked, and withdrawn, and why.
• The store is policy-free: it records attachments faithfully. Whether a posting requires a receipt is decided by the MCP layer's receipt policy (docs/mcp-interface.md), which reads the attachments table.

ledger-store: the SQLite projection

SQLite is the read-optimized projection of the journal. Queries, reports, the MCP server's reads, and the future GUI all hit SQLite — and SQLite is disposable by design: rebuild drops it and replays the journal. Suspected corruption is fixed by rebuild, never by forensics.

• Location. $WANDERBOOKS_DATA/wanderbooks.v{N}.db, falling back to ~/.local/share/wanderbooks/wanderbooks.v{N}.db, N the schema: each schema keeps a file of its own, and a version never migrates, writes or deletes another schema's (ledger_store::db_file_for; the legacy wanderbooks.db is used only while it holds this version's schema; rules.md B-27). The journal lives next to it at $WANDERBOOKS_DATA/journal.jsonl; blobs under $WANDERBOOKS_DATA/blobs/. WAL mode on, synchronous=FULL, integrity_check on startup.
• Schema. meta(key, value) — schema_version, base_currency, last_applied_seq; accounts, entries, lines, blobs, attachments as above; events(seq, type, payload, created_at) — the applier's output, a queryable mirror of the journal stream and the feed the future GUI tails. (Poll WHERE seq > ?; later SSE over the HTTP transport. This is the correct answer to "watch its files to update live" — watch the event stream, not the files.)
• Document fields. Since schema v16 (plan P4b S4.3) the documents' new fields are columns: invoices(number, terms, bill_to, seller, customer_ref, memo) and bills(vendor_ref, received_on, terms, memo, duplicate_reason), with terms and snapshots as canonical JSON TEXT and a document written before them NULL there. A line's account, quantity and unit_price ride its document's lines_json, as its project does. The party's email and default terms are journaled and replayed into the ledger; the projection keeps no party table to hold them.
• Amounts as TEXT, never REAL. Unchanged and still load-bearing: a REAL column would silently reintroduce binary floats into the money path.
• Append-only, three layers. (1) The engine's API never mutates posted state. (2) The journal is append-only by file discipline plus the hash chain. (3) The applier only ever INSERTs into the projection. The SQLite triggers from the earlier draft are deliberately dropped: they protected the projection, which is disposable — the journal is the trust anchor, and piling mechanisms on the disposable layer adds complexity without adding safety. Simplicity is a durability feature too.
• Migrations. Numbered SQL files, applied in order, bumping meta.schema_version. Every migration is tested by rebuilding a projection from the journal and comparing reports before/after. A newer schema version than the binary understands is a hard error, not a guess.

Migration from Google Drive (done)

The company's records were filed into the books at the P1 cutover (2026-10-17, D-20: formation papers, notices, plans and history, through books.file_document with their categories) and the books cut over on 2026-10-20. The Drive manifest and comparison tools once planned for P6 were struck (plan/served.md 8.4): the Drive folder is frozen history. P6 (on its branch) adds the categories notices, correspondence, plans, history and text extraction for every filed document.