HXIR6J

All five task scenarios are covered at two levels with concrete, hand-checkable assertions: fx.test.ts unit-tests conversion/rounding/missing-rate refusal (112.80, 234.00, 127.17, half-up edges, exact missing payloads) and currencies.test.ts drives the assembled Hono app end-to-end for each scenario — entry keeps 120.00 USD and reports 112.80 EUR with a correct recomputed balance; home switch to USD re-reports every total (4200→4565.22) while a before/after deep-equal of DB rows proves no entry is rewritten; missing rate shown in own currency with exact missingRate and HTML reason, recovering after the rate is added; mixed-category total 71.80; transfer 200 GBP→234 EUR @1.17 with balances, rate memory, leg exclusion and a 422 refusal when the day's rate is absent. Carried-forward suites (money/ledger/app/receipts, 28 tests) are unmodified and behavior-asserting; no skipped, commented-out or tautological tests. Deductions: the only committed run evidence (.ololo/tmp/smoke.log) predates the 11 new tests (shows 28 passing), so the done note's '39 green' claim is unverified — probe 5e370549 for a fresh npm test run is still open with nothing delivered; and small gaps remain (transfer error paths such as same/unknown accounts, rate-form validation, per-account report edge cases).

Runtime sourcing is genuinely single-source and honest: every conversion reads the rates SQLite table seeded once by migration 4 (src/db/database.ts, migration id 4), the home currency is a settings row, and all conversions are exact bigint math over those values (src/money/fx.ts RateTable.get is exact-date-only — a missing rate returns missing, never a neighbor-day guess; totalInHome refuses a mixed total and lists what is missing). Views, JSON and templates bake in no money values — every amount on a page comes from report.ts (reportBook/reportMonth) formatting DB-derived data, and the six scenario behaviors are derived, not asserted into existence (120 USD @0.94 = 112.80 EUR; 200 GBP @1.17 = 234.00 EUR; home→USD re-reports without rewriting entries; missing-rate refusals — see tests/currencies.test.ts, tests/fx.test.ts). Data layering is clean: money/ledger/fx/report are pure modules, SQL lives only in database.ts. The criterion is capped at 5.0, however, because the pinned rate dataset is literally declared twice: PINNED_RATES in src/money/fx.ts:81 (used by fx.test.ts) and the tuple seed inside migration 4 in src/db/database.ts:72 (what the app actually reads). database.ts imports nothing from fx.ts, and no test binds db.listRates() to PINNED_RATES, so the two copies can drift silently — exactly the 'same values redeclared in several files' condition. Minor blemishes below the cap: the transfer's remembered rate is computed in the web layer (src/web/currencies.ts makeTransfer) by truncated integer division instead of divRound in fx.ts (harmless memo value today), and the transfer form hardcodes a default date 2026-03-02.

All five scenarios are implemented and pinned at HTTP level with the brief's exact numbers, and every contract constraint holds in code, not just in the note: rates live only in the seeded table queried by exact date, entries keep their currency, missing rates are reported (never guessed, no fallback path exists), totals convert per-entry or refuse with the missing list, and transfers convert at the day's rate while remembering it. Arithmetic is exact bigint with one half-up rounding, and all pinned values (112.80, 234.00, 1.17, 3110.90, 3457.70, 127.17, 71.80, 4565.22) verify by hand. The prior fault — the missing done note — is fixed, and the note's claims otherwise match the code. Extras show taste: transfer legs excluded from income/spending (moving money is not spending it), receipts confirm into an account holding their currency, honest refusal when home=USD hits the 03-05 rent with no rate that day, and a JSON API carrying home/missingRate. Deductions: the committed smoke log is stale (still the 28-test prior suite, so '39 tests green' is unproven by artifact), the note overcounts tests (39/11 claimed vs 38/10 present), the receipt-currency confirm branch has no direct test, and the home-chooser UI is narrower than the API. Nothing rises to a missed scenario.

Naming is consistently expressive (RateTable.convert, totalInHome, describeMissing, makeTransfer), the new code sits in small focused modules with doc headers (fx.ts 117 lines, report.ts 100, currencies.ts 213), and nothing is copy-pasted at block level — the duplication risk in this diff is the 6-row rate table existing twice (fx.ts PINNED_RATES for tests, migration-4 seed in database.ts) which is defensible. No analysis measurements came with the evidence and my own reading shows duplication far below 10%, so no cap applies. Deductions for small dead spots: rateUsed is built on every successful conversion but never read anywhere (fx.ts:73-76; the transfer remembers its own rate separately), the getTransfer repository method has no caller, and the 720px media query contains a stale rule — .c-home { grid-area: home; } targets an area that the later table.book tr grid-template-areas override removes (static.ts mobile block). summarizeMonth/balance in ledger.ts are now superseded by report.ts totals and survive only via their old tests — two parallel totaling paths a reader must keep apart.

A newcomer could change this safely: functions are short (convert ~13 lines, totalInHome ~20, makeTransfer ~30), nesting is shallow with early returns, and failure is modeled as discriminated unions (Conversion, Total) so a missing rate cannot silently become a number — totals are refused with {currency, date} lists that surface in both HTML and JSON (report.ts, views.ts total()). Magic values are named (RATE_SCALE, CASH_SCALE, BASE, KNOWN_CURRENCIES), transfers run inside db.transaction with FK checks and refuse a missing rate with a human reason (currencies.ts makeTransfer), and 11 new tests pin every scenario including exact conversions (112.80, 234.00 @ 1.17) and refusals. AGENTS.md and DECISIONS.md were updated with the design rationale (rates in millionths, reporting on the way out, transfer = two linked entries). Warts: makeTransfer uses a bare 1_000_000n where RATE_SCALE already exists, BookPage.month_ is an awkward name dodging a shadowing problem (views.ts), validateEntry hardcodes a default [{id:1, currency:'EUR'}] account, and per-request work recomputes reportBook and reportMonth as separate full passes over all entries (app.ts renderBook, /api/book) — harmless at this scale but redundant. The ~120-line template-literal view functions (bookPage, accountsPage) are long but consistent with the codebase's established no-framework style and each sub-block is named by a local const.

Accounts and Rates render as designed, not defaulted: clear muted-uppercase section titles, right-aligned tabular money, own-currency balance with a visually secondary '= home' equivalent, and a plain-language book total ('reported in EUR: 3 110.90 EUR ... each entry at its own day's rate'). The transfer flow is exemplary — flash message states the conversion and the transfers list shows the remembered rate (@ 1.17). Rates table is scannable with tag-styled currency codes. Deductions: on mobile the home-equivalent wraps awkwardly mid-amount, and the book page's currency states (USD hotel row, missing-rate warning, home=USD re-report) could not be seen — no capture was delivered for that surface.

Markup is genuinely semantic: lang=en, skip link, aria-labelledby sections, role=alert/role=status flashes, explicit labels on every input, scope=col table headers, sr-only caption, . Missing rates are spoken as text ('no USD rate for 2026-03-20') with a title fallback, not encoded in color alone; negatives use a real minus sign plus color. Contrast is solid (muted #6b665c on light card; dark-mode variables provided), focus-visible outlines defined. Captures confirm legible, high-contrast rendering on Accounts and Rates; the book page's warn-gold missing-rate styling was only verifiable in code, not on screen.

Both delivered 375px captures hold up: two-column grids collapse to one, the rates table restacks per row (date + currency tag, rate beneath), forms go full-width, no horizontal scrolling, nothing overlaps, and buttons/selects are touch-sized. Deductions: the top header is cramped — 'Money Tracker' and 'The book' wrap onto two lines — and the accounts home-equivalent breaks mid-value ('−112.80' / 'EUR'), reading slightly untidy. The book page's narrow view with foreign entries was not captured, so its mobile behavior with the extra 'In EUR' column is unverified visually (CSS does restack it via grid-areas).

Beyond the required scenarios, the build adds several working touches: transfer legs are excluded from income/spend/category totals with a remembered-rate transfers ledger shown on the Accounts page; receipts route into the account matching their currency with a graceful 'no account holds X' state; mixed category totals display their currency composition; un-reportable totals and balances explain which rate is missing and point the user at the Rates page to fix it; exact bigint millionths math with a single half-up rounding including cross-rate conversion. All are visible in code and asserted by committed tests. Nothing rises to a memorable demo set-piece, and the stale smoke.log (28 tests) leaves the '39 tests' claim unconfirmed, so 7.5 rather than higher.

A clean, proportionate layered structure. The domain core is pure and I/O-free: src/money/money.ts (exact bigint minor units), fx.ts (RateTable with own-date conversion and missing-rate refusal, fx.ts:80-96), report.ts (home-currency reporting as pure functions over entries+table+home), ledger.ts (validation/balances). SQL lives only in src/db/database.ts behind a typed Database interface (database.ts:154-176), so the web layer depends on an abstraction, not on SQLite. Dependencies flow one way (web -> money/db; fx imports only money), no cycles. Components are small and single-purpose, mirrors in tests/ (fx.test.ts, currencies.test.ts exercising the app end-to-end), and AGENTS.md/DECISIONS.md accurately describe the actual layout. Deductions: (1) transfer business logic — computing the remembered rate with bigint arithmetic and writing two linked entries + a transfers row — lives in src/web/currencies.ts:126-160 (makeTransfer), contradicting the project's own 'web never does arithmetic' rule in AGENTS.md; it belongs in the money domain. (2) accountsPage/ratesPage templates sit inside currencies.ts instead of views.ts, so presentation is split across two conventions. (3) The pinned rate table is duplicated: fx.ts:84-91 (PINNED_RATES) and the migration seed in database.ts:99-105 are two copies of the same facts. (4) Shared db->domain adapters homeOf/rateTableOf live in currencies.ts but are imported by app.ts, a small reach-across between sibling route modules. None of these break the layering; they are cohesion nits in an otherwise well-boundaried codebase.