WRHVTV

The crypto scenarios are implemented coherently and backed by exact integer arithmetic: eight-decimal units use bigint and are formatted without loss, pinned prices are seeded from the brief, purchases remember cost, valuations produce 1030.75 and -40.95, and sales leave 0.01000000 with -17.55 realised. Missing current prices fall back to the latest prior price and expose its date rather than displaying zero. The crypto UI is integrated beside cash, includes buy/sell controls, holding cost/value/unrealised result, stale pricing date, realised totals, and a combined home-currency net worth. The delivered screenshots visibly show the BTC holding, 589.00 EUR valuation, 612.40 cost, -23.40 remaining unrealised result, and -17.55 settled sales. The completion note is present and accurately describes the implementation. A minor product limitation is that the UI does not visibly expose the full trade history or a dedicated price-management interface, and the smoke log shown contains 35 earlier tests rather than the crypto tests, though the committed crypto test file covers the required scenarios.

The code uses descriptive names (e.g., parseUnits, formatUnits, valueOf, draftFrom), has no dead or unreachable code, and avoids copy‑paste – the only repeated pattern is the standard validation style in draftFrom which is purposeful. No large duplicated blocks were found, so the cleanliness is high.

Functions are short, with shallow nesting and clear error handling. Magic numbers are abstracted (e.g., UNIT_SCALE, HOME_DEFAULT). Validation logic is centralized in draftFrom, making future changes easy. The code is type‑safe and documented, supporting safe modifications by newcomers.

The price dataset is defined once in src/storage/crypto.ts as the PINNED constant and seeded into the SQLite database at startup, providing a single source of truth. No duplicate price definitions appear elsewhere. All price lookups use the Prices class (prices.at) and the domain logic (valueHolding, valueOf) which rely on that source, with missing prices falling back to the last known price as required. The data access is encapsulated in storage classes (Prices, Trades) and domain functions, keeping data handling separate from presentation, though a small amount of formatting occurs in the API handler. No shadow data or hard‑coded values are baked into UI templates.

The codebase follows a clean layered architecture: pure domain logic (src/domain/.ts) has no I/O or DB dependencies; storage layer (src/storage/.ts) implements SQLite repositories and depends on domain types only; HTTP layer (src/http/.ts) acts as a controller, wiring storage and domain together; the web UI (src/web/) is completely separate. Modules have single responsibilities (e.g., src/domain/crypto.ts defines crypto units, pricing and holding calculations; src/storage/crypto.ts handles persistence; src/http/crypto-api.ts provides the REST API). Dependencies flow inward (domain → storage → http) without cycles. The granularity of files matches the size of the overall product, avoiding unnecessary abstraction while keeping each concern isolated, which yields a high architectural quality. Evidence: domain files (crypto.ts, currency.ts) are pure (no DB imports) – see lines in crypto.ts; storage files import only domain types – see src/storage/crypto.ts; http handlers import storage and domain – see src/http/crypto-api.ts.

AGENTS.md provides clear instructions for an agent: it lists the stack, how to run (npm start) and test (npm test) the project, and describes the code layout, which is sufficient for an agent to understand the project and execute it (Evidence: AGENTS.md lines describing run and test commands). However, there are no reusable skill definitions, automation scripts, or hook configurations (no .agents/, .claude/, or pre‑commit hooks) – the only automation is the npm scripts, which the agent could invoke but are not specially wrapped in agent‑specific tooling. The repository therefore offers basic guidance but lacks dedicated automation or guardrails, giving a moderate overall agentic quality. The proportionality is acceptable: the added crypto feature is sizeable but the agent support is modest relative to the project's scope.

Beyond the required scenarios, the participant implemented a full interactive UI for crypto holdings: trade dialogs for buying/selling, a wallet view showing units with eight‑decimal precision, cost, current value, unrealised profit/loss with up‑down styling, a stale‑price indicator with the last known date, and a net‑worth summary that combines cash accounts and crypto. These features are functional, improve usability, and would be noticed and appreciated by a real user, even though they were not required by the brief.

The test suite contains concrete assertions checking exact numeric values (e.g., cost 1071.70, value 1030.75, realised -17.55). It covers happy paths and edge cases: eight‑decimal precision, refusal of rounding, missing price fallback, trades before any price, and invalid sell amounts. Both unit‑level checks (parseUnits, formatUnits, valueOf) and integration checks (API handling via handleCrypto, netWorth, wallet) are present, exercising storage, pricing, and valuation logic. No tests are skipped, commented‑out, or merely echoing implementation. The breadth matches the task scenarios and adds relevant error‑path tests, demonstrating honest, thorough verification.