swaitsandClaude Opus 5.5
ebb5fcb46f
check / check (push) Canceled after 0s
The owner (2026-10-23, via the question tool): "Uploads only"; and before it: "What we would DEFINITELY want to avoid is passing a bunch of BLOBs through AI context windows. That's just a pure waste." No file passes through an agent's context, in either direction. In: the inline arguments are gone with the 256 KiB limit (INLINE_MAX, take_file's inline branch): content_base64 and its sha256 on books.attach_receipt and books.file_document, w9_content_base64 and w9_sha256 on books.set_w9, csv_text on the two CSV imports. A file comes only by books.begin_upload and `wanderbooks upload`, named by its upload_id; existing_attachment_id still names bytes stored already. The five filing tools deny unknown fields, and any inline argument to any tool is refused before it runs as an unknown argument pointing to books.begin_upload (access log: refused inline_file). Out: books.export (every format), books.asset_labels and books.get_receipt view bytes hand the file over (HandedFile: download command and expiry, D-29), as the CPA package and the W-9 do. Resource reads stay text. A token keeps up to 64 handed files (was 16). The access log's digest no longer exempts file bytes. Docs: handbook files-in-out and parties-and-tins, mcp-interface.md, rules.md, receipt-store.md, parties-and-attachments.md, plan/served.md (D-46; the inline decisions marked superseded), STATUS.md, testing.md (D-46: tests migrated to uploads and downloads, rewritten, removed, added). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T3gXMVt7XJPi6ens1or9Dj
58 lines
3.4 KiB
Markdown
58 lines
3.4 KiB
Markdown
# Capability parity — GSheet+GDrive → wanderbooks
|
|
|
|
The parity target for the AI-first phase is **not QuickBooks**. It is the
|
|
system actually in use today: the "the first company — Books" Google Sheet
|
|
(double-entry accounts with live P&L, Balance Sheet, and Cash Flow tabs, plus
|
|
the Transaction Journal) together with the Drive folder, operated through an
|
|
AI assistant. Every capability below must be reachable through MCP tools
|
|
before the sheet retires.
|
|
|
|
Statuses: `covered` (built and tested), `partial` (built, known gaps listed),
|
|
`specced` (designed, not yet built), `future` (on the roadmap).
|
|
|
|
| # | Today's capability | wanderbooks equivalent | Status |
|
|
|---|---|---|---|
|
|
| 1 | Record a double-entry transaction (Transaction Journal row) | `books.draft_entry` / `add_line` / `post_entry` (engine: `Ledger`) | covered |
|
|
| 2 | Chart of accounts | engine + `books.chart` (with live balances) | covered |
|
|
| 3 | Live P&L tab | engine + `books.profit_and_loss` | covered |
|
|
| 4 | Live Balance Sheet tab | engine + `books.balance_sheet` | covered |
|
|
| 5 | Live Cash Flow tab | engine `cash_flow` (direct, with the reconciliation schedule) + `books.cash_flow` | covered |
|
|
| 6 | Transaction Journal as append-only log | engine posting log + `books.search_entries` | covered |
|
|
| 7 | Receipt storage in Drive | blob store + `books.attach_receipt` / `link_receipt` / `unlink_receipt` / `withdraw_attachment` | covered |
|
|
| 8 | Document filing by category (01 Formation / 02 Legal / 03 Tax / 04 Accounting) | `books.file_document` | covered |
|
|
| 9 | Ad-hoc questions ("what did we spend on X?") | `search_entries` + reports; the AI itself is the query layer | covered |
|
|
| 10 | Human review of what the assistant recorded | `books.digest` | covered |
|
|
| 11 | CPA-ready export of the books | `books.export` (csv/json/xlsx/pdf/iif, each handed over as a download: D-46) | covered |
|
|
| 12 | Company email filing (every company email → Drive folder) | out of books scope; the existing mail-filing automation keeps running unchanged | — |
|
|
|
|
## Notes
|
|
|
|
- Row 9 is the quiet superpower of the AI-first design. The sheet answers
|
|
questions with formulas the human must write; the MCP design answers them
|
|
with an agent that already knows how to read a trial balance. The
|
|
capability is "ask anything about the books," and the tool surface above
|
|
is what makes it true.
|
|
- Row 10 (`books.digest`) has no sheet equivalent — the sheet can't tell you
|
|
what changed. This is parity *plus*: the new system is more reviewable
|
|
than the old one, which is the point of the exercise.
|
|
- Projects (rules.md B-37) have no sheet equivalent either: a class with
|
|
its facts, created and changed by the agent (`books.add_project`,
|
|
`books.update_project`), read by the viewer's Projects pages and by
|
|
`books.projects` / `books.project` (D-28: the agent writes, the viewer
|
|
reads).
|
|
- Row 12 is deliberately excluded. Email filing is a mail problem, not a
|
|
books problem; it stays where it is.
|
|
|
|
## Cutover rule
|
|
|
|
The sheet does not retire on a date. It retires when **all three** hold:
|
|
|
|
1. Every `specced` row above is `covered` (built, tested, golden-covered
|
|
where reports are involved).
|
|
2. A full month of parallel run — every real company transaction recorded in
|
|
both systems — diffs clean.
|
|
3. The owner says so.
|
|
|
|
The parallel run is the acceptance test. Until then the sheet is the system
|
|
of record and wanderbooks is the shadow ledger; after, it inverts.
|