ZUDUGR

Every scenario ships and survives verification at three levels. Pinned arithmetic: 1071.70 buy cost, 1030.75/−40.95 valuation, 0.01000000/−17.55 sell, and the six-price table are all exact in bigint code (src/money/crypto.ts) and pinned by tests; the deterministic probe confirms 46 tests / 0 failures on the participant's machine. Eight decimals are integers of 1e-8 end to end — parse rejects a ninth decimal rather than rounding, the UI prints 0.01000001. The missing-price scenario renders 'last known, 2026-03-20' with the value never zero, and an asset with no price at all is pinned by the DOGE test and rendered 'unknown — not zero'. Cash+coins in one figure: the delivered screenshots reconcile to the cent by hand (3128.70 = 1685.95 + 1442.75, with trade legs correctly excluded from spending). The screenshots also show a coherent product: as-of revaluation, optional EUR cash leg, wallet field, price editing, refused trades with reasons, and a working mobile layout. Minor blemishes: the committed smoke.log predates this part (39 tests) so the done note's '46 green' rested on the probe to confirm — now confirmed; and the no-price-at-all UI state is proven by test and code but not by a capture.

A compact, honest, scenario-complete suite. Assertions: every test pins concrete values — 1071.70 cost (tests/crypto.test.ts:21), 1030.75/-40.95 (crypto.test.ts:28), 0.01000000 left and -17.55 realised with remaining cost 612.40 (crypto.test.ts:37), last-known-price with date 2026-03-20 and null-never-zero for an unpriced asset (crypto.test.ts:47), and DB-seeded prices/rates tied to the pinned constants (crypto.test.ts:59). No skipped, commented-out, or tautological tests anywhere in tests/*. Coverage: all six brief scenarios are exercised, plus error paths — nine-decimal quantity refused, zero refused (crypto.test.ts:12-18), buy on a day without a price refused 422, oversell refused (crypto.test.ts 'through the web'), nonsense entries refused with nothing stored (app.test.ts, ledger.test.ts), 404s (app.test.ts). Level mix: unit tests for the money/crypto logic, integration tying DB seeds to constants, and a genuine end-to-end test through createApp() with an in-memory SQLite DB asserting JSON APIs and rendered HTML (crypto.test.ts:69) — the assembled product is exercised, proportionate to the codebase's size. Honesty: tests specify behavior, not implementation; one comment honestly explains the satoshi rounding rather than hiding it. Deductions: (1) no committed evidence of a green run including the 7 new crypto tests — .ololo/tmp/smoke.log shows 39 tests (pre-crypto) and the done note's '46 tests run green' (money-tracker-crypto-done.md:3) is an unverified claim; my run-back probe errored on environment, not on the tests (probe:daa6db09-b251-48c2-8c5f-15c747cc00d2); (2) the price-add flow (POST /crypto/prices then buying on that new day) is untested end-to-end; (3) the non-EUR home-currency crypto net-worth path (src/web/crypto.ts netWorth) and multi-asset net worth have no test; (4) a few HTML regex assertions are page-level and weaker. These gaps keep it from 9+, but the suite would catch a regression in any pinned number or rounding rule.

Desktop /crypto reads as designed: the net-worth figure is the dominant hero with the cash+coins breakdown right beneath, holdings numbers are right-aligned tabular figures with negatives in red, asset codes are tags, and the 'Value on' revalue control is obvious. The last-known-price state annotates both the hero and each row ('last known, 2026-03-20'). Only dings: on mobile the holdings grid drops all column labels so cost/worth/unrealised/realised values are unlabeled, and trade dates wrap mid-token.

Strong semantics in markup: lang=en, skip link, nav aria-label, sections with aria-labelledby headings, th scope=col tables, every form control labelled, role=alert/role=status for errors and confirmations, and a real minus sign (−) plus color for negatives — information never encoded in color alone; stale prices are text ('last known, 2026-03-20') plus amber. Dark-mode palette is defined via prefers-color-scheme. Minor: the mobile CSS hides table headers with display:none, removing header context for screen readers too, and the amber warn tone is borderline for small text.

The 375px capture shows a working narrow layout: nav wraps, hero and forms stack full-width, the holdings table reflows into per-row blocks, prices render as stacked rows, and nothing overlaps, truncates, or scrolls horizontally; inputs and buttons are touch-sized. Costs it: holdings rows show six unlabeled EUR values in two columns (readable only by memory of the desktop order), and trades dates break as '2026-03-' / '20'.

The session's code is essentially duplication-free and reads with a consistent domain voice: PriceTable.lastKnown, positionsFrom, valuePosition, recordTrade, netWorth, stale/realisedMinor/unrealisedMinor (src/money/crypto.ts, src/web/crypto.ts) all say what they are. Magic values are named constants (ASSET_SCALE=8, ASSET_UNIT=100_000_000n in src/money/crypto.ts:11-12; RATE_SCALE in fx.ts). The brief's six prices exist in exactly one place (PINNED_PRICES, src/db/database.ts) seeding migration 5, and a test ties the DB seed back to the constant — no copy-paste of data. There is no pasted block anywhere in the diff; repeated patterns (bigint sort comparators, 'no X rate for Y' messages) are single-line idioms, and a small refactor even removed duplication (crossRateMicro moved from the web layer into fx.ts; rate seeding now iterates PINNED_RATES instead of an inline literal array). Minor blemishes keep it below 9: a few public members have no callers (Database.getTrade, src/db/database.ts:236/419; PriceTable.assets(), src/money/crypto.ts:81), the default wallet literal "Main wallet" appears as a string in three places (schema DEFAULT, recordTrade, form placeholder), and toTrade/toAccount row mappers use any with dense one-line ternary chains (src/db/database.ts:~265-275) — consistent with the pre-existing style, but not exemplary.

A newcomer could safely change this. The domain core is exemplary: every function in src/money/crypto.ts is 5-25 lines, flat, pure, and documented with the exact rounding rule (one half-up divRound at the boundary, quantities as raw 1e-8 integers that are never rounded in or out); positionsFrom and valuePosition each fit on one screen and the worked numbers of the brief are pinned by tests (1071.70, 1030.75, -40.95, -17.55, 0.00000001 survival — tests/crypto.test.ts:24-65). Boundaries fail loudly and humanly: recordTrade refuses sell-more-than-held, buys/sells without an exact-day price, non-EUR cash legs, and bad asset/side/date input with specific reasons, returned as 422 (JSON) or a redirect flash (HTML); the trade plus its cash leg run inside one transaction; a day without a price falls back to lastKnown with the date shown and 'unknown — not zero' when none exists at all. Architecture docs were updated (AGENTS.md, DECISIONS.md) so the layering contract still holds (SQL only in database.ts, arithmetic only in money/). Costs that keep it under 9: recordTrade (src/web/crypto.ts:72) is ~55 lines mixing validation, pricing, persistence and message building — still linear with early returns, but it is the one function approaching scroll length; cryptoPage (110 lines) is a single template string with a few nested ternaries inside interpolations, though flat and consistent with the codebase's established view style; netWorth needs one type cast ((coins as { reason: string }).reason) and a comment to explain cash/coin currency conversion. No cleverness that costs comprehension.

Prices live in one place: the asset_prices table (src/db/database.ts migration 5) seeded from the single PINNED_PRICES constant carrying exactly the brief's six values; a test ties seeded rows to the constants, and this commit removed the old duplicated inline rates array by seeding from PINNED_RATES. All output values are derived from that source — I recomputed 1071.70, 1030.75, -40.95, -17.55 and 612.40 remaining cost from qty×price/1e8 and average-cost folding and they match. No shadow prices: the numbers occur only as test expectations; '61240.00' in the price form is a placeholder, not data. Data layer is cleanly separated: pure math and PriceTable in src/money/crypto.ts (bigint 1e-8 quantities, never rounded), SQL confined to src/db/database.ts, web layer only composes and validates. Missing-price behaviour is honest: valuation uses lastKnown with its date and shows 'unknown — not zero' rather than 0; no external or fabricated prices are introduced. Minor nit: the PINNED_PRICES constant lives in the DB module rather than a dedicated data file, and quantity input validation is orchestrated in the web layer — both cosmetic given the single-source discipline.

Beyond the brief's six scenarios, the build ships several genuine, test-proven touches. The standout is the cash-leg integration: a buy/sell optionally posts a linked entry (tradeId) into the ledger, shows as a 'coins' tag in the book, is excluded from income/spending totals (src/money/ledger.ts, src/money/report.ts), and net worth avoids double counting (src/web/crypto.ts recordTrade + netWorth; tests/crypto.test.ts asserts book balance drops to 2152.00 while expense stays 1276.30) — a real accounting insight a user would thank them for. Also beyond the letter: deposit/withdraw sides so coins can arrive without a purchase price, a 'value on' date picker plus ?asOf= on the JSON API with a net-worth-level stale-price warning ('coins at the last known prices, not today's'), prices editable on the page, wallet/note fields with a default wallet, flash confirmations that echo the resulting holding, and forgiving refusals with actionable copy ('add it under Prices before recording a buy that day', 'you cannot sell 5.00000000'). All of it is exercised end-to-end in tests/crypto.test.ts (satoshi survival, coinsStale, 422 refusals) and the smoke log shows 39 tests green. Not at the 8.5+ tier because there is no single memorable demo moment (e.g. a portfolio-over-time view or per-lot history), and the cash-leg choice, while elegant, is an accounting refinement rather than a showpiece — but multiple working, user-visible touches put this clearly above the plain baseline.

A cleanly layered small product that grew one feature without breaking its shape. (1) Separation of concerns: a pure domain core in src/money (money.ts exact bigint parsing/formatting, ledger.ts validation/totals, fx.ts rates and divRound, report.ts home-currency reporting, and the new crypto.ts with PriceTable/positionsFrom/valuePosition) does arithmetic with zero I/O; src/db/database.ts is the only SQL, behind one Database interface with prepared statements and numbered migrations (migration 5 adds asset_prices/crypto_trades and seeds PINNED_PRICES); the web layer in src/web routes, validates and renders but 'never does arithmetic of its own' as AGENTS.md states. The done-note's layer map matches the files exactly. (2) Component boundaries: units are small and single-purpose (crypto core 140 lines, web slice 252 lines), each with a documented interface; per-module test files plus an end-to-end web test (tests/crypto.test.ts) exercise them in isolation and through the app; AGENTS.md, DECISIONS.md and the per-part TODO tell a newcomer where things live. (3) Dependency direction: money ← db ← web, money ← web, one way throughout; crypto core imports only money/fx; no cycles. (4) Proportionality: no needless layering — plain template-string views, one facade, feature-sliced routes. Deductions: the two application services netWorth() and recordTrade() (validation + price lookup + cash-leg booking inside a transaction) live in the web slice src/web/crypto.ts rather than beside the domain they compose, leaving the 'cash and coins in one number' rule web-owned; the cryptoPage markup sits inside the routes file while every other page lives in views.ts, a cohesion inconsistency; the Database facade is one wide ~40-method interface spanning entries/receipts/accounts/rates/transfers/prices/trades; and money.ts's parseAmount regex chain (A ?? B ? C : null) is convoluted for a core module. None of these fuse logic with markup or scatter I/O into computation — rendering consumes precomputed structures (cryptoPage maps over Valuation[]).