5AY7ZW

The build goes meaningfully beyond the currency scenarios with a cohesive account-and-transfer model: separate account currencies, opening balances, transfer records retaining both legs and the applied rate, and explicit valuation dates for home-currency account worth. It also adds unusually thoughtful user-facing safeguards: refused totals with per-currency subtotals instead of guessed numbers, visible missing-rate links, receipt duplicate detection, editable receipt line reconciliation with acknowledgement, preserved form values after validation errors, empty states, account/category/currency filtering, and receipt provenance links from ledger entries. These are relevant, working-looking product touches rather than decorative scope.

The desktop screenshot shows a clear money-tracker hierarchy: headline balance, income/outflow cards, filters, entries, recording form, and category summaries. The committed implementation also visibly supports currency reporting, accounts, and rates through dedicated navigation and labeled UI elements. Evidence: the desktop and receipt-desktop screenshots, plus the structured views in src/web/views.ts.

The screenshots show strong text contrast, readable sizing, explicit labels, and clear visual distinction between income, expenses, and refusals. Markup evidence includes semantic headings, labeled controls, aria-labels, aria-invalid/aria-describedby error wiring, visible text for currency codes, and visually hidden supplemental receipt text. Evidence: src/web/views.ts and src/web/styles.css.

The narrow screenshot shows the main balance, filters, and entry content reflowing into a single readable column without visible clipping or overlap. The CSS explicitly switches summary, columns, rows, search, and receipt fields at narrow breakpoints, and removes sticky side behavior. The captured receipt mobile surface also remains legible and vertically stacked. Evidence: committed mobile screenshots and responsive media queries.

The product keeps rates in a single source – the SQLite rates table – accessed via src/storage/rates.ts and used through the Rates class in src/domain/rates.ts, meeting the source‑of‑truth and separation requirements. No rates are hard‑coded in the code, so there is no shadow data. However, the migration src/storage/migrations/005_opening_accounts.sql ships a large set of rates for many dates (e.g., 2026‑03‑03,‑05,‑07,‑09,‑11) that are not present in the brief's rate table (which only lists 2026‑03‑02 and 2026‑03‑14 for USD, GBP, CHF). This adds data not authorized by the task brief, violating the honesty of sourcing requirement. The extra rates constitute a serious defect, lowering the overall data score.

The codebase cleanly separates concerns: domain logic (src/domain/) handles currency, entries, rates, accounts and book calculations without touching I/O or persistence; storage (src/storage/) isolates all SQLite interactions and maps rows to domain types; presentation (src/web/*, src/http/server.ts) deals with UI and HTTP handling only. Components have single responsibilities and expose clear interfaces (e.g., convertEntries, Rates class, entryStore). Dependencies flow inward—domain has no imports from storage or web, storage imports only domain types, and the web layer imports both. No circular dependencies are present. The number of files matches the task complexity (currency handling, rate conversion, account transfers, UI, persistence) without unnecessary layering, indicating proportionality. Evidence: src/domain/book.ts uses only domain modules; src/storage/entries.ts maps DB rows to Entry (domain type); src/web/views.ts renders domain data; src/http/server.ts wires HTTP routes to domain and storage.

The test suite contains extensive assertions covering both happy‑path and error‑path behavior. Domain unit tests (currency.test.ts, entry.test.ts, book.test.ts) verify concrete conversion results, rounding rules, missing‑rate handling, scale validation, and validation error aggregation. Integration/scenario tests (currency-scenarios.test.ts) drive the running application through its HTTP API and UI, confirming correct reporting of entries, home‑currency changes, missing rates, mixed‑currency totals, transfers, and form handling. Edge cases such as amounts with too many decimals, large amounts that could overflow, invalid dates, and rate‑missing scenarios are exercised. The mix of unit, integration, and end‑to‑end tests matches the task’s size. No tests are skipped, commented‑out, or merely restating implementation; they all assert observable behavior. The only minor gap is an explicit test for converting between two non‑base foreign currencies without an intermediate step, but this is indirectly covered by the "converting between two foreign currencies goes through the base once" test. Overall the suite would catch regressions in the core multi‑currency logic.

The code uses clear, self‑describing names (e.g., money, CurrencyMismatchError, parseAmount, totals), has no dead code, and avoids copy‑pasting—functions are defined once and reused. Duplicate logic is minimal (only related helpers in money.ts which are intentional).

Functions are reasonably sized, with nesting kept shallow. Errors are explicitly handled (e.g., CurrencyMismatchError, missing‑rate handling in book.ts). Magic values are abstracted (rates, currency codes). The design isolates conversion, aggregation, and formatting concerns, making future changes safe for newcomers.

AGENTS.md provides a clear working agreement for an autonomous agent: it describes the stack, how to run (npm start) and verify (npm test) the project, and explicitly states constraints such as offline operation and no network dependencies. These instructions match the implementation (e.g., the domain rules about currency handling are documented and enforced in the code). Reusable automation is present via npm scripts (start, test, samples) which encode the routine tasks the agent would need, though they are not wired to automatic hooks. No pre‑commit or validation hooks are defined, so the guardrail aspect is missing. The repository is fairly large for a single currency‑handling feature, but the documentation is proportionate to the overall product scope, resulting in a solid but not perfect score.