swaitsandClaude Fable 5.1
af553a3706
The planning session read plan/served.md, every design document and the five branches the owner paused on 2026-10-27 against main (44ee4083), with dry-run merges touching no branch. plan/2026-10-28_DRIFT_REPORT.md lists every divergence and judges every recorded departure (all kept; three owed back; one needs a decision: P6 made ledger-store depend on ledger-import). The plan: section 0 "What changed on 2026-10-28"; 8.0.1 and the unit Status lines name S4.4, S5, S6, S7 and P6 as built but unmerged; 8.0.2 records the destination (D-56: the installed app, P11a starts now) and the resume order with the known conflicts (the shared documents.rs test file, the types.rs appends, P6 retaking schema 18, the law numbers 34 to 37); 8.0.3 lists the names the EM approved during the wave; P11a gains step 0 (the macOS and Windows keyring stores, the Windows data root and pipes, a cross-platform CI build: today the agent path runs on Linux alone); Q-5 is due and Q-8 asks whether D-47 to D-54 stand; the Landlock sentences in section 2 and server.toml are struck. STATUS.md and HANDOFF.md say where things stand and how to resume; roadmap.md and gui.md are rewritten to today. The docs lose their stale facts: 122 tools, 2,700 tests, the parity floor at 21 with the P4b notes the slices never wrote, the ten crates and their dependency graph (jiff added to the core's allowed list), the cutover of 2026-10-20 recorded in capability-parity.md and parallel-run.md, the P4b S1 law and its two Kani harnesses added to verification.md (law 34), the proof counts (51 and 9), and README, the site and install.sh honest about macOS (the viewer runs; connecting an agent waits for P11a's keyring store, and the installer now says so instead of failing). just check on main at44ee4083: exit 0 (167 suites, 2,871 passed, 0 failed, 7 ignored, the server-only build clean). No code changed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HS8WZziDnyxunC23MUxrLp
67 lines
3.8 KiB
Markdown
67 lines
3.8 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: done 2026-10-20
|
|
|
|
The three conditions below were met and the owner said so: the books were
|
|
adopted into the server's data root as the first company's live books on
|
|
2026-10-20 (P2 slice 9), the Sheet is frozen as of 2026-10-11 with the
|
|
final `verify-sheet` run filed as a workpaper, and the old copies moved
|
|
into the data root's `legacy/` (Q-3, D-2). The rule is kept for the record
|
|
and for the next company.
|
|
|
|
## Cutover rule (as it was)
|
|
|
|
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.
|