3WTCA2

The delivered artifacts and repository show a strong, thoughtful multi-currency money tracker with accounts, transfers, receipt ingestion, exact money handling, rate-gap messaging, filters, and responsive layouts. However, these are the core product capabilities described by the brief and its earlier parts rather than a clearly additional, unrequested feature for crypto. I found no committed crypto holdings, valuation, sale, or crypto-specific UX implementation to reward beyond the brief.

The submitted product is the earlier cash, currency, account, and receipt tracker, but the required crypto feature is absent. The completion flag named by the task is missing, and the repository contains no crypto holding, buy/sell, valuation, realised/unrealised result, or eight-decimal holding implementation. The committed smoke log reports 147 tests, but none cover the crypto scenarios. The visible screenshots likewise show only Accounts, Rates, Receipts, and cash ledger views, with no wallet or crypto UI.

All price information is stored in the rates SQLite table (see src/storage/migrations/004_currencies.sql) and accessed through the Rates class (src/domain/rates.ts) and the rateStore wrapper (src/storage/rates.ts). This provides a single source of truth; there are no hard‑coded price literals elsewhere in the code or UI, satisfying the ‘source of truth’ and ‘no shadow data’ requirements. Rate parsing, conversion, and missing‑rate handling are encapsulated in the domain layer, keeping data handling separate from presentation logic, though a few callers invoke Rates directly which slightly lowers the separation score. The implementation uses the supplied price table for calculations (e.g., conversion in convert and rateBetween), respecting the pinned arithmetic, so the data is honestly sourced. No duplicated copies of the price data are found, and missing rates are reported rather than guessed, matching the task constraints.

The repository follows a clear layered architecture. Domain concerns (e.g. src/domain/.ts) are isolated from persistence (src/storage/.ts), HTTP handling (src/http/.ts), and presentation (src/web/.ts). Each file has a focused responsibility – e.g., money.ts defines currency handling, rates.ts handles conversion logic, account.ts deals with account validation. Dependencies flow inward: higher‑level layers import from lower‑level domain modules, but domain modules do not depend on storage or UI, avoiding circular coupling. The structure is proportional to the problem size: the project is a full‑featured money‑tracking product, so the multiple layers and separate modules are justified, and no unnecessary indirection is present. This reflects good separation of concerns, clear component boundaries, proper dependency direction, and appropriate proportionality.

The codebase uses clear, self‑describing names (e.g. parseRate, formatRate, convertEntries, currencyParts). Constants such as RATE_SCALE, ONE_RATE, and DEFAULT_CURRENCY centralise magic values. There is no dead code or evident copy‑paste of large blocks; each module has a focused responsibility. Small helper functions are defined once (e.g. formatAmount, sumMoney) and reused, avoiding duplication.

The architecture is modular with low nesting depth and short functions, making it easy for a newcomer to understand. Error handling is explicit (e.g. AmountError, ValidationError). Magic numbers are named constants, and types are well‑defined (Money, Minor, Conversion). Some files are relatively long (e.g. book.ts), but they remain logically grouped and documented, supporting safe changes. No hidden side‑effects or undocumented behavior appear.

AGENTS.md provides clear instructions for an agent: the stack, how to run (npm start) and verify (npm test), and constraints (integer amounts, no rounding, rates handling) that match the task requirements. This gives a strong instruction component. Reusable automation exists via npm scripts (start, test, samples), which the agent can invoke, but there are no dedicated skill definitions or higher‑level command wrappers. No pre‑commit or other automatic guardrails are present, so error‑catching is left to manual testing. The repository is sizable for a simple crypto‑tracking task, adding unnecessary boilerplate, which reduces proportionality. Overall, the instruction quality is high, automation moderate, hooks absent, and size somewhat disproportionate, leading to a balanced agentic score.

The repository contains a rich suite of tests for entries, accounts, rates, receipts, and overall ledger scenarios, all with concrete assertions. However, none of the test files address the crypto-specific scenarios described in the task (buying fractions, eight‑decimal precision, valuation on a later date, partial sale, aggregation with cash, handling missing price). A search of the test directory shows no mentions of BTC, ETH, USDC, or related holdings, indicating that the critical crypto functionality is untested. Consequently, regressions in the newly added crypto features would not be caught by the existing test suite.