* feat(transactions): expose the bank account (cash_account_id + ledger) on listings, filter by it
Customer report: neither the MCP transaction listings nor v1 REST said which
bank account a transaction belongs to, so per-account reconciliation could
not be driven from outside and a difference on one account was hunted on
another.
- gnubok_list_uncategorized_transactions: cash_account_id + cash_account_ledger
(BAS account of the bank account, one lookup per page) on every row, and
an optional cash_account_id filter applied to both count and page.
- transactions_without_documents RPC (new migration, same signature): rows
carry cash_account_id + cash_account_ledger via LEFT JOIN cash_accounts;
gnubok_list_transactions_without_documents declares them.
- v1 transactions list/detail: cash_account_id column; list accepts
?cash_account_id=<uuid> (400 on non-UUID).
- tools/list budget bumped 59.85K -> 59.9K with the usual log entry; no
property descriptions added.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(transactions): import insertCashAccount in the pg test, regenerate banking.md, validate cash_account_id
Skeptic/CI findings: the new pg-real test referenced insertCashAccount
without importing it; the accounted-api agent skill (banking.md) was stale
after cash_account_id joined the v1 projections (apiskill:check). Also
reject a ledger number passed as cash_account_id on the MCP tool with a
clear message instead of a raw uuid cast error, since the ledger now sits
next to the id in every row.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Mattsson
6e5694fd03