* fix(mcp): query_journal defaults to status 'all' so totals equal ledger balances
Posted-only was the default, but storno bookkeeping keeps both the
reversed original and its posted storno on the account: one-leg sums are
never balances. A customer's agent summed posted-only lines over a
storno-heavy quarter, found phantom VAT residuals on 2614/2641/2645/2647
and asked support to revert correct books.
- default status 'all' (posted + reversed), the same inclusion rule as
trial balance, GL and SIE export
- explicit 'posted'/'reversed' get status_filter_warning when the
opposite leg exists in range (entry-level head count, advisory)
- unknown status values now throw instead of matching nothing
- sibling description trims fund the additions within the tools/list
payload budget
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(mcp): make status_filter_warning claim strictly true, hint status:'posted' for tag preview
Review feedback (PR Agent + skeptics): the entry-level opposite-status
count cannot prove the line-filtered totals are wrong, so the warning
now says one-leg totals CAN differ from balances; verb agrees with a
count of one. tag_journal_lines preview hint tells agents to pass
status:'posted' now that query_journal defaults to 'all'. Description
trims keep the tools/list payload inside the budget guard.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(mcp): state the status_filter_warning count scope in the message
CodeRabbit: the opposite-status count applies entry-level filters only,
so say so in the warning instead of letting an account-scoped caller
read the count as account-scoped. Line-level scoping declined as
documented in DECISIONS.md (it would re-run the full line fetch).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
