Setup only — do NOT build receipts yet, that is the next task.

This part continues the product you already built — the ledger: money in
and out, corrections, deletions and an honest balance.

Same repository, same documented commands. If you are starting in an
empty folder, your earlier work is fetched for you before you begin.

Before writing anything new, check that what you carried in still stands:

• AGENTS.md still declares stack:, run: and test:;
• the suite the test: line names is green;
• the parts already delivered are still delivered.

And check the product itself, not only its suite. These must still be true
of what you carried in:

• money in and out is recorded, corrected and deleted, and the March
  book still balances at 3223.70
• an entry with no date, or an amount of zero or less, is still refused
  with a reason

Fix whatever the hand-over broke before you start this part — a judge reads
the product on this rung, and everything the earlier parts earned is judged
again at the end of it, so a regression carried in quietly costs twice.

Stop making people type. A receipt — photographed off the table, or emailed
by the shop — becomes a draft entry that a language model has read for them,
which they confirm or correct before it becomes money in the book. You decide
when it is done; a judge panel scores the result.

The emailed receipt used by the scenarios below:

merchant: Konzum
purchased: 2026-03-14 18:42
currency: EUR

item	qty	line total
milk 1l	2	2.38
rye bread	1	1.89
coffee beans 250g	1	7.49
plastic bag	1	0.15

total: 11.91

Scenarios:

Scenario: An emailed receipt is read
When the person adds the receipt above
Then a draft appears with merchant Konzum, date 2026-03-14, total 11.91,
its four lines, and a suggested category of groceries
And nothing has been added to the book yet

Scenario: A photographed receipt is read the same way
When the person adds a photo of a paper receipt
Then it becomes a draft with the same fields, ready to confirm

Scenario: The person has the last word
When they change the suggested category and confirm the draft
Then the entry saved is theirs, not the suggestion
And the receipt stays with the entry, openable from it

Scenario: A reading that is not sure says so
When a field cannot be read with confidence
Then the draft marks that field as uncertain and asks
And no number is invented to fill the gap

Scenario: The lines must add up
When the read lines do not sum to the read total
Then the person is told before they can confirm

Scenario: The same receipt twice
When a receipt already in the book is added again
Then the product recognises it and offers the entry that already exists

Everything beyond the scenarios is yours: how receipts arrive, what the
review looks like, what happens to the ones nobody confirms.

The reading must be demonstrable from a cold start with no paid account:
ship the sample receipts and a way to replay their readings, so the whole
flow can be shown end to end without a live model.

When you are done, write .ololo/money-tracker-receipts-done.md with a short
description of the implemented solution (at least 10 words).