5E2JCS

The submission goes meaningfully beyond basic multi-currency entries: it ships dedicated Accounts and Rates pages, multi-currency account balances, transfer planning with a persisted conversion rate, per-currency subtotals, exact missing-rate refusal messaging, rate-gap links, receipt currency handling, and a home-currency picker that explicitly preserves original entries. These are practical end-user features that make the product feel like a usable financial tool rather than a scenario-only demo. The UI also includes thoughtful empty states, validation feedback, preserved form values, receipt duplicate handling, and progressive enhancement for the currency/category controls.

The codebase is cleanly split into layers: domain logic (src/domain/.ts) holds business rules such as Money, Entry validation, Rates conversion, Account transfers; storage layer (src/storage/.ts) isolates DB access; HTTP server (src/http/server.ts) orchestrates request handling; web view layer (src/web/*.ts) produces presentation. Each module is focused on a single responsibility (e.g., money.ts for currency handling, rates.ts for conversion, account.ts for transfer planning). Dependencies flow one way: domain modules are imported by storage and HTTP, but never the other way around, avoiding circular coupling. The structure matches the product’s scope—a full money‑tracker with accounts, receipts, and rates—so the layering is proportionate and not over‑engineered. Evidence: the presence of distinct files such as src/domain/money.ts, src/domain/rates.ts, src/domain/book.ts, src/storage/accounts.ts, src/http/server.ts, src/web/views.ts, and the lack of import cycles between them (e.g., server imports domain and storage but domain does not import server).

The product’s rates are stored in a single source of truth – the SQLite rates table – accessed through the Rates class (src/domain/rates.ts) and the rateStore wrapper (src/storage/rates.ts). No duplicate copies of the rate data exist elsewhere; all conversions reference this central store (convert, rateBetween). Missing rates are reported, never guessed, and the code never embeds hard‑coded rates in markup or logic. Data handling (parsing, validation, conversion) is isolated in src/domain/rates.ts and src/storage/rates.ts, while presentation layers only read the results, satisfying separation of concerns. Tests (tests/currency-scenarios.test.ts) verify that the output matches the shipped rates and that missing rates trigger proper messages, confirming honesty of sourcing.

AGENTS.md provides clear instructions on stack, run (npm start) and test (npm test) commands, and documents the multi‑currency rules that match the task constraints, giving good guidance. The repository includes reusable npm scripts (start, test, samples) that serve as automation, but there are no dedicated skill definitions or scripts invoked automatically beyond the generic npm commands. No pre‑commit or validation hooks are present, so guardrails are missing. The overall codebase is large for the specific currency task, reducing proportionality, but the instructions are concise and accurate, balancing the score to a moderate level.

The code uses descriptive names for all concepts (e.g., DEFAULT_CURRENCY, CurrencyMismatchError, rateBetween, convert, missingReason). There is no dead or unused code, and duplicated logic is limited to intentional small helpers rather than large copy‑pasted blocks. Constants centralize magic values (e.g., RATE_SCALE, ONE_RATE). Functions are small and focused, keeping the repository free of unnecessary repetition.

The architecture separates concerns (money handling, rate conversion, book aggregation) into clear modules, making changes localized. Function nesting is shallow (max two levels) and each function stays well below a scrollable length. Error handling is explicit (e.g., AmountError, CurrencyMismatchError, ValidationError). Magic numbers are encapsulated in named constants. The only minor drawback is repeated pattern for handling missing rates in totals and byCategory, but it is small and well‑named, so a newcomer can safely modify or extend the logic.

The test suite contains many concrete assertions that verify expected values and behavior. It covers all scenarios from the task description: entry retention and conversion, home currency switching, missing rates handling, totals conversion per entry date, transfer operations with rate memory, rate filling, form handling, and decimal precision enforcement. Both unit tests (tests/currency.test.ts) and higher‑level integration tests using the running application (tests/currency-scenarios.test.ts) are present, providing a balanced mix of levels. The tests also explicitly check that currencies are not silently added together and that missing rates are reported, fulfilling the core requirements. Minor gaps such as edge cases for unknown currencies or extreme rate values are not critical for the task size, so the suite earns a high score.