B22GYR

The ledger has a strong visual hierarchy: the balance and monthly in/out/left-over figures are prominent, entries are grouped by date, and the add-entry form and category summaries are clearly separated. Desktop screenshots show a polished two-column layout with useful filters, category bars, and visible edit/delete actions. The receipt surface is also coherent and presents extracted data alongside confirmation controls. Evidence: ledger desktop screenshot, ledger mobile screenshot, receipt desktop screenshot, receipt mobile screenshot; commit:93300b716abc7ff180c8cf70506f4b4eca62b0ae; file:src/web/views.ts:184.

The screenshots show readable text, strong contrast for primary values, and status colors supplemented by explicit signed labels and text such as “Money out,” “Money in,” and “rate missing.” Markup evidence includes semantic headings, labeled form controls, field-level aria-invalid/aria-describedby wiring, role=status/alert messaging, scoped table headers, and hidden descriptive text for receipt links. Some secondary gray text and small mobile labels are relatively light/small, preventing a higher score. Evidence: screenshots; commit:93300b716abc7ff180c8cf70506f4b4eca62b0ae; file:src/web/views.ts:70, file:src/web/views.ts:307, file:src/web/views.ts:421.

The narrow screenshots show the layout collapsing into a single readable column without apparent horizontal scrolling or overlapping content. The balance card, filters, entries, recording form, and category summaries remain usable, and the receipt view similarly stacks line items, extracted metadata, and the confirmation form. Controls are large enough for touch interaction, though the long page and compact row actions make scanning less effortless than desktop. Evidence: ledger mobile screenshot, receipt mobile screenshot; commit:93300b716abc7ff180c8cf70506f4b4eca62b0ae; file:src/web/styles.css:1.

The committed implementation appears to cover the requested ledger scenarios end to end: pinned March opening data is stored in minor units, entry validation rejects missing dates and non-positive amounts, editing preserves the entry identity, deletion removes it, category totals and balance arithmetic are implemented, and exact-cent addition is explicitly tested in code (commit:93300b716abc7ff180c8cf70506f4b4eca62b0ae; file:src/storage/migrations/002_opening_month.sql; file:src/domain/money.ts; file:src/domain/entry.ts; file:tests/scenarios.test.ts). The delivered screenshots show a polished, responsive ledger with the required six starting entries, 3223.70 balance, grouped entries, category summaries, and usable record/edit/delete controls (probe:9a8?; probe:da5?; probe:e9a?). However, the project's declared npm test command actually discovers zero tests (1..0, # tests 0), so the claimed 46-test verification is not reproduced by the shipped command and automated evidence does not validate the scenarios (probe:deterministic). The UI also includes substantial currencies/accounts/receipts/crypto scope, which adds complexity and visible mixed-currency refusal states beyond the foundational ledger task, though the screenshots demonstrate coherent handling rather than a broken core.

Names are descriptive (e.g., draftEntry, accountBalance, currencyParts). Constants and enums are clearly defined (CATEGORIES, MAX_NAME). No dead code or obvious copy‑paste; the only repeated pattern is the validation‑error accumulation in draftEntry (src/domain/entry.ts) and draftAccount (src/domain/account.ts), which is a purposeful common pattern, not wasteful duplication. Magic values such as month names are isolated in MONTH_NAMES and DAY_NAMES. Overall duplication is well under 10 % and the codebase is tidy.

The code is largely modular with clear separation (domain, storage, web). Error handling is thorough: each input‑parsing function collects all field errors before throwing (draftEntry, draftAccount). Functions are reasonably sized, though some rendering helpers (e.g., renderBook in src/web/views.ts) are long (>200 lines) and nested HTML string construction adds depth, which could hinder future edits. Magic values are named where appropriate, but a few large HTML templates are built via concatenation, increasing cognitive load. Nevertheless the core business logic (conversion, totals, balances) is well‑structured and easy to follow.

The repository provides a well‑written AGENTS.md that clearly tells an agent the stack, how to run (npm start) and verify (npm test) the project, and notes constraints on receipt reading. These instructions match the actual build commands defined in package.json, so they are accurate and useful (AGENTS.md lines 1‑9, package.json scripts). Automation is modest: npm scripts for start, test, and a samples command exist, and the .claude/settings.local.json restricts allowed Bash commands, providing a basic guardrail. However, there are no dedicated reusable skill definitions, pre‑commit hooks, or extensive automation scripts beyond the standard npm commands, so the automation aspect is limited. The overall agent setup is proportional—no unnecessary framework is introduced for the ledger task, but the broader codebase includes many extra features (crypto, receipts) that are beyond the minimal ledger, slightly diluting the focus. Considering the clear instructions, modest automation, minimal guardrails, and proportionality, the agentic quality scores around 6.5.

The ledger’s initial dataset is defined in a single migration file (src/storage/migrations/002_opening_month.sql) which inserts the pinned entries (e.g., the March salary, rent, etc.). There are no duplicate copies of these values elsewhere in the codebase, and no hard‑coded amounts appear in presentation templates or logic – all balance calculations are derived from the entries read via the entryStore module (src/storage/entries.ts). The data‑access layer is well isolated: entryStore provides a clear API (list, add, update, remove) that the rest of the application consumes, keeping parsing and shaping of raw rows in one place. The categories list is enforced both in the migration CHECK constraint and in the domain type, but this is a coordinated definition rather than a divergent copy. Overall the output is honest to the source data.

The test suite contains concrete assertions on both API responses and rendered HTML, covering all six user scenarios (money out, correction, deletion, balance, invalid input, exact rounding). It also includes extensive unit tests for domain logic (totals, categories, conversion handling) and integration tests that drive the running web app. Error paths, boundary cases, and currency conversion failures are exercised. The mix of unit, storage, and end‑to‑end style tests is appropriate, and the tests verify behavior rather than implementation details. Minor gaps (e.g., no explicit test for adding an income entry via the form) prevent a perfect score.

The codebase cleanly separates concerns into distinct layers: domain (src/domain/*) holds pure business logic and validation (e.g., src/domain/book.ts computes totals, src/domain/entry.ts validates drafts); storage (src/storage/*) isolates all persistence (e.g., src/storage/entries.ts maps SQL rows to Entry objects and provides CRUD methods); web (src/web/*) contains only rendering and view‑state logic (e.g., src/web/views.ts builds HTML without touching the database); and HTTP server (src/http/server.ts) orchestrates request parsing, routing, and delegates to the other layers. Component boundaries are small and purpose‑single (each file exposes a clear API and does not mix responsibilities). Dependencies flow inward: higher‑level layers (web, server) import lower‑level ones (domain, storage) but never the reverse, avoiding circular couplings. The overall structure is proportional to the task: a full personal‑finance web app requires routing, persistence, domain rules, and presentation, and the repository reflects that without unnecessary extra layers. Hence the architecture is strong, though a tiny loss of score reflects minor areas where a few files contain mixed concerns (e.g., some request‑parsing helpers live in the server file), but these do not significantly undermine the design.

The submission adds substantial, functional features that were never required by the brief: multi‑currency support, account handling, crypto wallets and trades, receipt OCR with draft‑confirm workflow, UI category bar charts and filters, and a home‑currency switch. These are fully implemented (e.g., src/domain/money.ts, src/domain/crypto.ts, src/web/views.ts) and demonstrated in the provided screenshots (.ololo/artifacts/.../desktop.png). They provide real user value beyond simple ledger entry tracking, showing thoughtful usability and creative product expansion.