Files
wanderbooks/plan/roadmap.md
T
swaitsandClaude Opus 5.5 7741e96eb3
check / check (push) Canceled after 0s
refactor!: one way to serve books: the stdio server is gone (D-44)
The owner (2026-10-23): "We should probably just delete the stdio path
altogether. THere's no point in that. And it sitting there unused will
just lead to bitrot. Nuke it?"

Books are served only by the books server (`wanderbooks server`),
reached by agents through the bridge (`wanderbooks mcp --book ID`),
which stays.

Removed: `wanderbooks dev-stdio`, the `ledger-mcp` binary, and
`ledger_mcp::run` (stdio and `--http` over a bare data dir), with all
that only that mode had:
- files the books make coming back inline: `HandedFile.content_base64`
  is gone, and `download` and `expires_at` are always there;
- books with no access log or backups: `books.access_log`,
  `books.backup` and `books.back_up_now` are always offered, by scope;
- the settings file read and reloaded (`legacy_files`), the vault key
  named by a file or `--vault-key-file`, and the books dir's
  key-inside-the-books and git checks (with `paths.rs`);
- `wire.rs` (the bridge frames an agent's lines itself);
- `books.settings`' file fields and `books.start`'s `settings_source`.

`BooksServer` is built one way, from `Served` (a book as the books
server serves it), in production and in the unit tests. An unknown tool
is now a protocol error (mcp-tools.md). Inline file input is unchanged.

Then the owner's three decisions (2026-10-23, the question tool):
(a) `books.import_settings` is removed entirely (118 tools): old books
come in whole by `wanderbooks books adopt`, which reads their settings
file once; ledger-config keeps its settings-file parsing only as far as
adoption uses it (`load` and the path-reading `effective_receipt_policy`
are gone), and `books.chart_template` gives its settings as
`books.set_setting` changes. (b) The viewer's loose-books-folder mode is
removed (`--data-dir`, `--books-toml`, `--vault-key-file`, the settings
file and config.json followed): it opens only books of the data root,
reading settings from the journal and the vault from the book's own
`vault/` and `keys/`. (c) `wanderbooks dev-stdio` has no stub: it is an
unknown command like any other word. Also: an upload's expiry past the
calendar is an error, never an empty string.

Tests: every suite that drove the stdio server moved to
crates/ledger-cli/tests/ and drives a real `wanderbooks server` on a
data root of its own (tests/common), handed files by their download;
mcp_stdio.rs is mcp_journeys.rs. Tests of what is gone are deleted and
listed in docs/testing.md. Docs: plan D-44 (D-18 superseded), STATUS,
testing, rules, mcp-interface, the handbook, README; justfile recipes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T3gXMVt7XJPi6ens1or9Dj
2026-10-23 19:45:18 -06:00

5.1 KiB

Roadmap

Phase 1 — Semantics core (done)

The engine: money, accounts, journal, ledger commands, trial balance, P&L, balance sheet, cash flow, fixed assets with depreciation, golden files, property tests, mutation testing, fuzzing, and the docs an agent needs to work here. Parity floor: 12 done.

Phase 2 — AI-first interface (done)

The primary interface is MCP, not a cloned GUI (the owner's call, 2026-10-10).

  • ledger-store: append-only hash-chained JSONL journal (source of truth), SQLite as disposable projection with auto-rebuild, content-addressed blob store, durable drafts.
  • ledger-mcp: 27 tools (then over stdio and Streamable HTTP; since D-44 served only by the books server), preview-before-post, server-side receipt policy (>$25) with anti-splitting, asset management, digest for human review, read-only resources.
  • ledger-import: QuickBooks CSV import (bank, chart), IIF and XLSX export.
  • Capability parity 12 of 12 vs the GSheet+GDrive system.
  • Parallel run with the sheet; cutover per the cutover rule (docs/parallel-run.md).

Served (next, 2026-10-16)

The books become a server that owns its data; every agent reaches them only through the MCP, from anywhere; no scaffold. Phases P0 (guard rails) through P10 (full re-audit of the first company's books through the MCP alone), with the owner's decisions of 2026-10-16: plan/served.md.

Phase 3 — Oracle harness

  • ledger-oracle: fixture books through our engine and other implementations (GnuCash headless first), automatic snapshot() diffing. Each diff is adjudicated from principles; no other program is the authority.
  • Parity catalog becomes machine-readable; CI enforces the non-regression floor.
  • Done when: a fixture book produces byte-identical snapshots from both engines with zero manual steps.

Phase 4 — Read-only GUI (first version done, 2026-10-12)

ledger-gui: see plan/gui.md for the design and what's built.

  • Consumes the ledger-store event log: live updates — the answer to "watch its files to update live."
  • egui or web; a dumb client holding no accounting logic.
  • This is the trust layer for humans (the owner, the other member, the CPA), not the primary interface. Read-only at first; editing stays with the agent.
  • Design references (the owner, 2026-10-11; screenshots shared in session, described here):
    • Reports with a date range and a column interval (QuickBooks Desktop's P&L: From/To plus Columns = Year/Quarter/Month/...): any statement split into one column per interval plus TOTAL, to see the books over time. The multi-column statement layout in ledger-import::report already renders this shape; the GUI (and the exports) need a per-interval builder over the period-scoped core statements.
    • Financial dashboard (Coupler.io's QuickBooks dashboard): P&L, balance sheet, and cash flow overview tables with Last month / Month to date / Year to date columns, each beside charts — income vs. COGS + expenses vs. earnings bars; stacked assets vs. liabilities + equity; cash at end of period; net cash change.
    • Business overview (QuickBooks Online home): cards for cash balance with a trend, expenses by category (donut), profit and loss (income vs. expenses), invoices (unpaid, overdue, paid), sales trend, and bank account balances.
    • Revenue dashboard (Coupler.io): KPI tiles (paid, overdue, open invoices this month), an invoice table (number, customer, dates, currency, home and foreign amounts, balance, totals), expenses by category by month, invoices by status per month.
    • QuickBooks Online dashboard: invoices (unpaid in the last year, overdue vs. not yet due; paid in the last 30 days, deposited vs. not), expenses by category (donut, last month), bank account balances (book vs. bank, items to review), profit and loss (net income, income vs. expenses bars), sales trend (line, by quarter).
    • KPI tiles with comparison (QuickBooks accounting dashboard): income, cost of goods sold, expenses, net profit, each with % change vs. the previous 30 days; an auto date-range picker; cash balance over time with a trend line; revenue by month, stacked.
    • Cash-flow dashboard: bank balance, debtors, burn rate, cash runway (days) tiles; income vs. expenses for the last six months; a net cash flow forecast with a confidence band; A/P and A/R aging by days past due (the engine already computes both agings); total burn over time.

Phase 5 — Workflow parity

  • A/R and A/P workflows, bank reconciliation, budgets, scheduled transactions.
  • Multi-currency with FX translation.
  • Period close.
  • The goal: a self-hosted bookkeeping system with a tested claim to proved accounting semantics (cross-checked against GnuCash and others) and capability parity with the old GSheet+GDrive workflow — no SaaS subscription required.

Explicitly not on the roadmap

Bank feeds, payment processing, payroll, tax filing. Those are integrations and regulated domains, not cloning targets. The engine gets clean seams for them; someone else's API provides them.