MS2A2T

Beyond the six scenarios, the build ships several working, user-visible touches nobody asked for. (1) Cross-format duplicate detection: findDuplicate (src/web/receipts.ts:18) matches not only by file sha256 but by merchant+date+total, so photographing a purchase already emailed into the book is caught and the existing entry offered with a 409 and a deliberate 'confirm anyway' force path — proven in tests/receipts.test.ts ('the photo of the same purchase is caught by merchant + date + total too'). (2) The sample set is designed as a demo of the product's honesty: four curated samples in samples/receipts/readings.json include a deliberately smudged photo whose recorded reading leaves the total null at confidence 0.15 with the reader note 'I did not guess them', and a cafe receipt whose printed total (9.70) contradicts its lines (8.70) — every edge scenario replayable cold. (3) The attached committed sample photos (konzum-photo.png, smudged-photo.png) are convincing props: Croatian till receipt with OIB/ZKI fiscal codes and a genuinely smudged duplicate. (4) A draft lifecycle the brief left open — save for later or discard — with the receipts page split into 'Waiting for you' vs 'In the book'. (5) Reader provenance and notes surfaced on the review page ('Read by replay from... Reader's note: ...'), amber uncertainty styling, 'not read — enter it' placeholder, aria-invalid/alert attributes, mobile capture="environment", forgiving edit semantics ('empty text means still unknown', never zero), and a JSON API mirroring the whole flow. The core works (19+9 tests green per smoke.log and receipts.test.ts, ledger balance unchanged at 3223.70), so nothing here is scope creep. Falls short of 9+ because the touches are each modest and the one memorable mechanism (duplicate catch across photo/email) is not shown in any delivered product screenshot — the attached images are sample receipts, not UI captures.

A strong, honest suite: all six brief scenarios have a dedicated test with concrete assertions (draft fields, 4-line Konzum reading, category override saved with the entry and a receipt link on the book page, uncertain total left null with confirm refused 422, line-sum mismatch named before confirm, duplicate offered with exact payload and 409 unless forced). Error paths beyond the scenarios are covered too: unreadable receipts leave every field to the person, the AnthropicReader is tested with a fake fetch plus fall-through, samples-load is asserted, and the ledger/money suites still pin balances, validation errors and 0.10+0.20 exactness. Level mix fits the task size: unit tests for money/ledger, integration through the whole Hono app on an in-memory DB. The probe run confirmed 28 tests pass, 0 fail, on the player's machine. Small deductions: no boundary test at the 0.7 confidence threshold, no malformed-model-JSON or invalid-date-in-reading case, and no browser-side check of the review page's rendered HTML on refusal.

Consistently good naming (draftFromReading, checkDraft, UNCERTAIN_BELOW names the 0.7 confidence threshold), no copy-paste duplication across the new receipts layer, and module doc comments that state intent ('a reading is never money'). Small blemishes: one dead variable (problems: string[] in draftFromReading, src/receipts/reading.ts, never read), a handful of any-typed JSON boundary helpers (toReceipt(r: any), parseReadingJson), and several 200+ character one-liner routes (app.get("/api/receipts"...) in src/web/receipts.ts) that hurt scannability. Measured duplication was not part of my evidence and the code shows no pasted blocks, so no cap applies.

Clear layering (money pure core, receipts domain, db, web), dependency injection via ReceiptsDeps, reader composition that catches per-reader failures and falls back to an honest UNREAD reading, and a transaction wrapper with rollback. Tests are behavior-level with readable names and cover the risky paths (uncertain fields, line-sum mismatch, duplicates 409, unreadable file, Anthropic parsing via fake fetch). Deductions: the 'Confirm anyway' button depends on a fragile inline trick, onclick="this.form.action.value='confirm'", which shadows the standard HTMLFormElement.action URL property and likely never sets the action field, leaving force-confirm broken in the HTML flow; ingest uses draftFromReading(reading!) whose non-null assumption only holds for the composed reader; reviewPage is one ~85-line template with very long interpolated lines; and a few unnamed magic values (the 20000-char slice in AnthropicReader, the inline 8MB limit).

Single identifiable dataset: the pinned Konzum receipt ships verbatim (samples/receipts/konzum-email.txt) with its recorded reading in samples/receipts/readings.json — merchant Konzum, 2026-03-14 18:42, four lines 2.38/1.89/7.49/0.15, total 11.91, groceries — matching the brief exactly, with no drift between the raw source and the recorded reading. The replay path is content-hash keyed (ReplayReader, src/receipts/reader.ts:73) so output is derived from the bundled samples, which the task explicitly pins as the cold-start requirement; the live AnthropicReader handles unseen files and its prompt forbids inventing values, and the no-reader fallback (UNREAD, reader.ts) returns all-null with zero confidence — no fabricated numbers anywhere. Data layering is clean: parsing/shaping isolated in src/receipts/reading.ts (draftFromReading, checkDraft at :57/:106), SQL only in src/db/database.ts (receipts migration), and the review page renders stored draftJson rather than baked-in values; tests assert expected values without duplicating the dataset. Deductions: duplicate detection and edit folding (findDuplicate, applyEdits) sit in the web module src/web/receipts.ts:19 instead of the receipts domain module, and the recorded readings for the three extra samples are hand-authored fixtures — permitted ('everything beyond the scenarios is yours') and honestly disclosed, but they are the actual source of demo output; a trivial '11.91' format example is echoed inside the model prompt (reader.ts:93).

Screenshots from probe 2db2407f-d44c-4bc9-8aa0-177e56508e36 show a deliberate, consistent visual system: card sections, muted uppercase eyebrows, tabular-nums right-aligned amounts, a clear primary 'Confirm — put it in the book' button, and sample buttons that state what each demonstrates ('Smudged photo — total unreadable'). The review screen leads with the blocking problem in an amber 'Before this can become money' box, shows the receipt beside the editable draft, and highlights uncertain fields with tinted backgrounds plus '?' placeholders, so the key state is legible at a glance. Minor dents: the h1 is styled as a small muted eyebrow so the page's own hierarchy is quiet, and on mobile the confirm button wraps to three lines.

Markup supports what the screenshots show: lang='en' and a skip link in the layout (src/web/views.ts:31-46), labels bound with for=, aria-label on every line input, aria-invalid on unreadable fields, role='alert'/'status' on problem boxes, a table with th scope and sr-only caption, alt text on the photographed receipt img, and aria-label on the 🧾 receipt link (src/web/receipts.ts:207-246, src/web/views.ts:127). Uncertainty is never colour alone — amber tint is paired with explicit 'Not sure about the total — please check' text — and everything is real text, including the receipt email preview. Dark-mode variables and 3px focus-visible outlines exist in CSS. Contrast of the muted ink (#6b665c) and amber notes (#9a6b00, used at .85rem) is adequate though the small amber note text is the weakest pair.

The 375px capture of the review page stacks to one column with no horizontal scrolling and no overlapping or clipped content: receipt preview, each field, and the lines table all fit, and the 720px media query also restructures the book table into a grid (src/web/static.ts:118-141). Interactive controls keep ~40px heights with visible padding, so they are touch-usable, though tighter than the 44px ideal. Cosmetic nits at this width: the confirm button wraps to three lines, and the item input visually truncates 'coffee beans 2…' (still scrollable/editable, not lost).

Layering is genuinely clean for a small server-rendered app: pure domain modules with no I/O (src/money/money.ts, src/money/ledger.ts, src/receipts/reading.ts:73 draftFromReading is a pure reading→draft transform), a single SQL-speaking data module (src/db/database.ts:1 'The only file that speaks SQL') behind an explicit Database interface, and a web layer that only composes them. Dependencies flow one way (web → receipts → money/ledger → nothing; server → web) with a real composition root: createApp injects db/samples/reader and mounts receiptsRoutes({db, reader, samples}) (src/web/app.ts:50-53, ReceiptsDeps). The standout is the ReceiptReader port (src/receipts/reader.ts:26) with ReplayReader-by-content-hash (reader.ts:100) and AnthropicReader injected via fetchImpl — the LLM sits behind an interface, which is exactly how the cold-start constraint should be shaped, and tests/receipts.test.ts:76-92 proves the seam by stubbing fetch. Component boundaries are clear and testable in isolation (in-memory db, injectable reader/samplesDir); folders and AGENTS.md tell a newcomer where things live. Deductions: src/web/receipts.ts (299 lines) fuses route handling, duplicate-detection policy (findDuplicate, receipts.ts:19), edit folding (applyEdits), and both HTML templates in one file — inconsistent with the book side, which separates routes (app.ts) from views (views.ts) — and the long confirm handler branches over JSON/HTML × save/confirm/problems/duplicate/validation; business policy (duplicate matching, edit folding) lives in the web layer instead of src/receipts/; and Entry.receiptId leaks receipts knowledge into the pure ledger type (src/money/ledger.ts:30). DECISIONS.md still says migrations live in 'src/db/migrations.ts' while they actually sit in database.ts, a small doc/layout mismatch. No needless layering; structure is proportionate to the task's size.