L3WUZ2

This goes meaningfully beyond a plain receipt-to-entry flow with several user-focused additions that fit the product: bundled replayable samples for offline cold-start demos, explicit uncertainty questions instead of invented values, arithmetic mismatch handling with editable lines and acknowledgement, duplicate recognition across identical files and cross-source merchant/date/total matching, persistent discard/restore, and receipt previews retained with confirmed entries. The implementation and delivered note provide strong evidence these are designed as working features, while the screenshots show the existing ledger presentation but do not visibly demonstrate the receipt inbox flow itself.

The receipt data is stored in the shipped JSON reading files (e.g., samples/readings/konzum-2026-03-14.eml.json) and accessed through a clear sampling layer (src/receipts/samples.ts) and Reader interface (src/receipts/readers.ts). All values used in the UI and entry confirmation come from this source; there are no hard‑coded or contradictory values in templates or logic. The reading layer cleanly isolates parsing and validation (readingFromModel, toReading, checkLines) from presentation code, providing good data‑layer separation. The only minor issue is that the same reading appears in two sample files (eml and png) which duplicates the source, but this is intentional to support both email and photo scenarios and does not affect correctness, so the score is only slightly reduced.

AGENTS.md gives clear instructions for an agent: it defines the stack, how to run (npm start) and test (npm test), and explains that the receipt flow works offline using the replay reader (lines 10‑14). It also provides a command to regenerate sample photos (npm run samples). These instructions match the code and constraints, making the agent’s job well‑specified. The repository supplies reusable automation: npm scripts (package.json) and a tool (tools/make-sample-photos.ts) that the agent can invoke, and the chooseReader function in src/receipts/readers.ts automatically selects the appropriate reader based on environment variables, showing concrete automation. However, there are no hook scripts or guardrails (e.g., no pre‑commit or CI checks) that would automatically enforce correctness, reducing the overall score. The amount of configuration is proportional to the task – it is neither excessive nor lacking essential details – supporting a solid but not perfect rating.

The code uses clear, expressive names and separates concerns into well‑named modules (readers, mime, receipt domain, web views). There is no dead code or large copy‑paste blocks; duplication is minimal and justified by distinct responsibilities. The only repeated patterns are small helper functions, which is normal for a project of this size.

Several functions (e.g., renderInbox and renderReceipt) are very long and embed large HTML templates, requiring scrolling to understand their full logic. The nesting depth inside template strings and conditional blocks makes them harder for a newcomer to modify safely. Error handling and validation are well‑structured, but the size of the view‑rendering functions reduces overall maintainability.

The codebase cleanly separates concerns: core business concepts (book, entry, money, receipt) live in src/domain/, persistence is isolated in src/storage/, receipt ingestion and reading logic resides in src/receipts/, and the HTTP/UI layer is in src/web/ and src/http/. Each module has a focused responsibility and clear interfaces (e.g., takeReceipt in src/receipts/intake.ts, chooseReader in src/receipts/readers.ts, byCategory in src/domain/book.ts). Dependencies flow inward—domain code does not depend on storage or web, and storage depends on domain but not on web, avoiding circular coupling. The layering is proportional to the task’s complexity: enough abstraction to keep parts testable and replaceable (e.g., swapping the receipt reader) without unnecessary indirection, yet not over‑engineered for a relatively small product. This results in a maintainable architecture that fulfills the criterion.

The test suite contains extensive assertions verifying concrete values (e.g., merchant name, dates, totals, line items) and HTTP behaviours. It covers all six required scenarios (email receipt, photo receipt, user overrides, uncertainty handling, line sum validation, duplicate detection) plus additional edge cases (replay reader defaults, unknown receipt handling). Both unit‑style tests (readers.test.ts, readers logic) and integration‑style tests (using runningApp, posting forms, checking persistence and UI rendering) are present, demonstrating a balanced level mix. No tests are skipped, commented out, or merely restating implementation. The coverage aligns well with the task's critical paths.