longbook

The nearest day any commitment still owes, and every charge landing on it. Charges already marked paid are skipped. A transfer due that day is listed with direction "transfer" and kept out of total, under transfers_total. Amounts are per-currency and never converted, blended, or amortised.

無需輸入參數。

Every charge written for the next N days (default 30), soonest first, with per-currency totals — and which plans run out inside the window. Transfers between the owner's own accounts are listed with direction "transfer" and summed apart, never in total. Amounts are per-currency and never converted, blended, or amortised.

Monthly totals per currency, summed from the charges written: past months are the record, months ahead are the plan as written, a month with no rows is empty. Spending only — money in and transfers are in no month. Amounts are per-currency and never converted, blended, or amortised.

Spend per category over a window, summed from the charges written in it — the twelve months from today unless you say otherwise; a past window gives what was spent. Money in and transfers are left out. Amounts are per-currency and never converted, blended, or amortised.

Spend per account over a window, summed from the charges written in it — the twelve months from today unless you say otherwise. Money in and transfers are left out. Amounts are per-currency and never converted, blended, or amortised.

Spend per person over a window, summed from the charges written in it — the twelve months from today unless you say otherwise. Money in and transfers are left out. Amounts are per-currency and never converted, blended, or amortised.

The rows themselves: every charge, or one commitment's, optionally inside a window or only paid / only unpaid — each with its amount, paid state, the day the money moved, what backs it, and its note. A charge behind today reads paid whatever its row says. Transfers are listed with direction "transfer" and summed apart, never in total; money in is read by naming its commitment. This is the ledger; nothing here is computed. Amounts are per-currency and never converted, blended, or amortised.

Every commitment with its attributes — price now, cycle, status, category, member, account — plus its next unpaid charge, how many charges it has, and how far it is planned. Plans running short are named. `active` is what still lies ahead: a one-time commitment whose charge is behind today or paid is a charge now, counted in settled_one_time and read with charges. direction flags money in ("in") and a movement between the owner's own accounts ("transfer"). Amounts are per-currency and never converted, blended, or amortised.

Finds commitments by name, category, notes, member, or account — case-insensitive, substring match.

Adds up to 200 commitments in one call, as one reviewable batch. A recurring row is planned from first_charge for plan_months (24 by default); a one-time row is its single charge on `date`. A statement line that is a charge is a one-time row at its real date and amount with paid: true and basis "statement". Money in — salary, a refund, interest, cashback, a dividend — is a one-time row with direction "in", paid, basis "statement", kept apart from spending. Movements between the owner's own accounts (card bill payments, ATM withdrawals, own transfers) are not charges; a row with direction "transfer" keeps one in view, shown and never summed. A member or account is named in words, and a new name becomes a placeholder row as the app would create it. A tag from the library (any casing) arrives with its icon. `notes` holds a row's three most important details, one per line, such as an insurance policy's number, its official name or its file in documents/. Where writes are proposals, rows can be promoted to recurring once the owner's app has applied the batch. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Changes a commitment's attributes, by id or the exact name as the memory holds it — a miss answers with the real names; everything not named stays as it was, and an explicit null clears an optional field. `direction` turns a row into money in ("in") or a transfer between the owner's own accounts ("transfer"), and "out" back into a charge. `amount` is the price now and reaches only unpaid planned charges from `from` (default today); nothing before today is repriced, and a charge priced by hand or proved by a statement stays as it is. `notes` is the commitment's three details that matter, one per line, rewritten as it now stands. `status` pauses, resumes or cancels: pausing or cancelling unwrites the unpaid planned charges after today and keeps what happened; back to active plans nothing. `free_trial` true marks it a free trial, shown as a pill; false takes the mark off; no charge row changes either way. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Records that one charge was paid, or takes the mark back with paid: false. The commitment is named by id or the exact name as the memory holds it — a miss answers with the real names. The charge is a row; if no row exists for that day one is written at the commitment's price. `amount` records what left the account when it differed, and `paid_on` the day the money moved when it was not the due date; they change that one row and no other, and a null paid_on or note clears it. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Writes rows into one commitment by date: a statement's months for a commitment that already exists (paid, basis "statement"), or more planned months than the app keeps. The app never grows a plan on its own, so this is how one grows. The commitment is named by id or the exact name as the memory holds it — a miss answers with the real names. A row already there for a day is updated in place, never doubled. An amount left out is the commitment's price. The answer carries balance_note when the account's balance is now older than the newest row written. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Changes one charge where it sits — its amount, its day, its paid mark, the day the money moved, its note. The commitment is named by id or the exact name as the memory holds it — a miss answers with the real names, and `date` is the day the row sits on. `set.date` moves it: alone, the row keeps its amount as the owner's fact; with `and_later` every unpaid planned row after it follows a cycle apart and keeps its amount, and paid or hand-priced rows stay. `set.amount` with `and_later` reprices the unpaid planned rows after it too, and the commitment's price with them. A day that already holds a charge is refused, and so is a move past the cancelling date. Null clears paid_on or the note. mark_paid is the one-field way to mark. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Sets how many charges stand from today on for a recurring commitment, named by id or the exact name as the memory holds it — a miss answers with the real names — 240 at most. More are written a cycle apart after the last row, at the commitment's price; unpaid planned rows past the count are unwritten; paid rows, hand-set rows and the past stay. A one-time commitment has its one charge and is refused. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Deletes named rows from one commitment, named by id or the exact name as the memory holds it — a miss answers with the real names: a plan that was wrong. A paid row is a fact, so removing one is destructive. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Takes the ids of one-time commitments that are one thing repeating and makes one recurring commitment: their charges move under it exactly as they are — dates, amounts, paid, basis — the one-time rows go, and the plan continues from the step after the latest, never before today, for plan_months (24 by default), or stops at ends_on for a repeat that has ended. Attributes start as the first row's, direction included, so money in stays money in and a transfer stays a transfer; ids that do not share one direction are refused. Name, tag, member, account and notes may be given; notes are the commitment's three details that matter, one per line. Where writes are proposals, a row is promotable once the owner's app has applied it and commitments shows its id. Every id must be a one-time commitment the memory holds; a miss answers with the real names. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

The reports in the vault's reports/ folder, drawn by longbook from the confirmed charges it holds: those dated today or earlier whose basis is anything but "plan". A report may cover any span of days — longbook draws every calendar month on its own; a trip is one whose id starts "trip-"; a span asked for with create_report starts "report-" — and may be narrowed to accounts, members and categories (scope; absent means all). A report still holding unconfirmed passed charges in its currency says so in its own figures — a "Not yet confirmed" stat counts them beside "Total expenses" — so read the total as the part longbook can account for, never as the span's spending. delta_pct is absent whenever no change can honestly be drawn: the month is not over, either month is part-covered, or the month before holds no confirmed spending in this currency. Read its absence as "longbook would not say", never as a month of no spending, and never compute the change from two reports. Without an id it lists them, newest first by the last day each covers: the title, start_date and end_date, the scope, the month when it is one, the day the file was written, how many modules it holds and how many comments sit on them, and the share link when one is live. With an id it returns that report whole — every module exactly as the app draws it, each with its own comments. A module carries "Total expenses", "Accounts", "Categories" and "All charges"; an older file may hold other kinds, and they are returned as they are. A file the app's own decoder would refuse is counted in unreadable, never listed as a report — what this lists is what the Reports screen shows. Comments are the owner's and their viewers' own words: quote them, never rewrite them. An id that matches more than one report answers with the matches, not with a guess. Reports are files, so this reads only on the owner's own machine.

Lists the files in the vault's documents/ folder — bank and card statements the owner dropped in, and source files referenced by rows. Reads PDF (text-bearing), Excel (.xlsx) and CSV; anything else is listed as unsupported. A file still in iCloud is named so, with its download nudged. Start an import here, then read_guide "importing-statements" for the method.

無需輸入參數。

Returns a document's text: PDFs page by page, Excel sheets as CSV lines under sheet headings, CSV as it is. Long files page through offset/next_offset — keep asking until next_offset is null. Only for files in the vault's documents folder; a statement pasted into the chat is already in front of you. The text stays on this machine and in this conversation; never copy an account or card number out of it into the vault — the validator refuses them. Debit lines are charges; credit lines are money in, written with direction "in"; only movements between the owner's own accounts are skipped.

Leaves one short note on an app module; the latest note per module shows on that module's own screen. Modules: dashboard.next_payment, dashboard.active_commitments, dashboard.next_30_days, dashboard.this_month, dashboard.by_account, dashboard.by_category, account.<id>, member.<id>. There are no reports.* modules: the Reports screen shows the months longbook drew. A note is a sentence or two. Notes are appended, and the last note per module wins.

Cancels one commitment, by id or the exact name as the memory holds it — a miss answers with the real names. What was only planned after today is unwritten; what happened stays, so its past charges keep counting. Already-cancelled rows refuse. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Changes an account's own attributes — its name, its type (`tag` — the same words as the app's Account Type), its `notes`, the person it belongs to (`member`), its balance with the day it was true, and the account it is linked to (`linked_to`) — by id or the exact name as the memory holds it — a miss answers with the real names. `notes` holds what is particular about the account, one detail per line, such as a card's printed name as "Card name: Platinum Reserve"; numbers are refused. card_name and details are longbook's own, and a set sending a non-empty one is refused. Everything not named stays as it was; an explicit null clears. A balance carries its date; left out, the day of the write is used. A linked account is one level only: a card to the bank account that pays it, never a chain. `member` and `linked_to` name rows the memory already holds. Renaming onto a name another account wears is refused rather than merged. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Changes a person's name, email or tag, by id or the exact name as the memory holds it — a miss answers with the real names; everything not named stays as it was, and an explicit null clears the email or the tag. `tag` is their role in the owner's finances — family, household help, landlord — from the member tags. A person carries a name, a tag, an email and linked accounts; details and card_name are longbook's own, and a set sending a non-empty one is refused. Renaming onto a name another person wears is refused rather than merged. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Makes a person with what is known — a `tag` for their role in the owner's finances (family, household help, landlord — the library's member tags first) and an `email`. A name another person already wears is refused rather than doubled; update_person changes one that exists. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Makes an account — a card, a bank account, UPI, a wallet, cash — with what is known: its type (`tag`, the app's own words: "credit card", "bank account"), the account it is linked to (`linked_to`, a card to the bank account that pays it, one level), the person it belongs to (`member`, someone the memory holds), its `notes` (one detail per line, such as a card's printed name as "Card name: Platinum Reserve"; numbers are refused) and a `balance` with the day it was true. A name another account already wears is refused rather than doubled; update_account changes one that exists. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Renames one tag in the vault's own vocabulary — `kind` says which list, commitment, member or account — and carries every row wearing it, the owner's tag groups too. A name another tag of that kind already wears is refused. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Removes one tag from the vault's vocabulary — `kind` says which list — and the rows that wore it are left with no category; nothing else about them changes. A row left without a category shows under "No category" until one is set. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Deletes one commitment and every charge it ever had, by id. This is destructive; cancel_commitment keeps what happened instead. Writes are schema-validated and provenance-stamped, and land in the app's Proposals screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Asks longbook to draw a report from the ledger over the days and scope named. `title` is its name, `start_date` and `end_date` its first and last day (366 days at most, starting today or earlier), and `accounts`, `members` and `categories` narrow it — left out or empty means all. "No account" names charges billed to no account and "No category" untagged ones; any other name the memory does not hold is refused with the real names, and nothing is ever created. longbook draws the report on its Reports screen the next time the app is open, counting confirmed charges only; nothing waits in Proposals. The same name, days and scope asked again redraws the same report.

Returns longbook's llms.txt — the contract and working method for an AI using longbook — whole, or one chapter by name. Chapters: what-longbook-is, data-minimization-rule, three-doors, first-run, working-method, prompts, importing-statements, past-is-stored-the-future-is-written, tags, categorise-my-longbook, reorganise-my-longbook, people-and-accounts, documents-folder, document-invoices, notes, reading-reports, month-report, create-a-report, leaving-insights, unattended-runs, daily-email-round, shape, past-is-evidence, invariants, rules-for-anything-that-writes. "importing-statements" covers importing, "reading-reports" report questions, "unattended-runs" scheduled runs, "daily-email-round" the morning look at the owner's mail. Given one of longbook's 27 prompts — by its name (set-up-my-longbook, add-my-statement, categorise-my-longbook, add-a-month-report-in-my-longbook, add-email-invoices-in-my-longbook, set-up-a-daily-longbook-email-round, add-document-invoices-in-my-longbook, add-a-commitment-or-an-expense, what-do-i-pay-next, what-is-coming-in-the-next-30-days, what-did-i-spend-in-a-month, what-renews-this-year, make-my-weekly-longbook-page, create-a-report-in-my-longbook, make-a-report-of-my-trip, tidy-my-longbook, reorganise-my-longbook, set-up-a-morning-brief, find-subscriptions-from-my-email, find-expenses-from-my-email, find-invoices-from-my-email, find-insurances-from-my-email, find-purchases-from-my-email, find-bills-from-my-email, find-loans-and-emis-from-my-email, find-travel-bookings-from-my-email, find-money-in-from-my-email) or the owner's own words for it, a month's name and all ("Add September month report in my longbook") — it returns that prompt's procedure, with the chapter it builds on. A partial name finds its chapter.

Every tag this vault already uses — with its icon and how many rows wear it — and then longbook's library for the rest, with the owner's own casing. A tag carries no template: a commitment's or an account's own details live in its notes.

無需輸入參數。

Every account the memory holds: id, name, type (its tag), institution and last4 when present, belongs_to (the person it belongs to), linked_to (the account it is linked to: a card to the bank account that pays it), balance with balance_date, notes — what is particular about it, one detail per line, a card's name ("Card name: …", the thing to look up for offers) among them — details as stored when it holds any, how many commitments and charges are billed to it, and its next unpaid charge.

無需輸入參數。

Every person the memory holds: id, name, tag (their role in the owner's finances — family, household help, landlord), email, the accounts that belong to them, details as stored when they hold any, how many commitments and charges are for them, and their next unpaid charge.

無需輸入參數。

Answers who this connection belongs to, what it may do (read, or read and propose changes), how much of its rate allowance is left, whether a hosted copy exists and when it was last pushed, how many proposals are waiting for the owner's app, which ones it could not apply and why (failed_to_apply), and where the schemas live. One call, so it also shows whether the connection can read and write.

無需輸入參數。